TL;DR: An MCP server can offer more than actions for Claude to call. It can expose resources that a client reads by URI, and it can request information from a person during an operation through elicitation. Claude Code provides common ways to list and read resources across servers, while elicitation can appear as a form or an external browser step. These features make the client–server relationship less one-directional than a simple tool call.
Most of this series has followed one path: Claude chooses a tool, the MCP server runs it, and a result comes back. That is the tools capability introduced in Part 1. This article turns to two other paths: the server makes information available for reading, or it asks the user for information it needs to continue.
Resources: identify and read, rather than invoke an action
Imagine an issue record, a documentation page, or a database schema. A server can expose this material as an MCP resource. The resource has a URI that identifies what should be read; the client asks the server for its contents using the protocol's resources/read operation. This is different from inventing a separate tool and input schema for every kind of document.
In Claude Code, a user can type @ to find resources from connected MCP servers alongside local files. A particular resource can be referenced in a prompt as @server:protocol://resource/path. When referenced, Claude Code fetches it and includes it as an attachment. It also provides general list-and-read tools for MCP resources when connected servers support them.
That is the useful contrast with Part 4. MCP tools are distinct operations whose descriptions and schemas matter individually. Resource discovery and reading are standardized operations; the interesting variation lies in the URIs and the content they return. Claude Code does not need to register a new specialized “read this server's document” tool every time another server is connected.
Resources are often read-oriented context, but “resource” should not be mistaken for a guarantee that every URI is an ordinary text file. MCP resource responses may carry text or binary data, with MIME types indicating what was returned. Claude Code's handling of large or binary output can keep it from dumping an encoded blob directly into the conversation: the implementation examined for this series stores some binary resource content separately and returns a path and description instead. The model can then use the appropriate file workflow if it actually needs to inspect that content.
There is also a boundary worth noting in current Claude Code documentation. Some MCP resources are MCP Apps UI resources, intended for a host application to render. They do not appear in the normal @ resource suggestions or list-tool results, even though reading one by its URI can work. “The server exposes a resource” does not necessarily mean “the resource appears as a document in autocomplete.”
Elicitation: the server asks the user mid-task
Sometimes the server cannot finish an operation with the inputs it has. It may need a missing field, a choice that only the user can make, or a browser-based authorization step. Elicitation is the MCP mechanism for asking the client to obtain that information from a person and return an answer to the server.
This reverses the usual direction of a tool call. Claude or the client initiated an operation, but the server now has a question. The client remains responsible for presenting that question and controlling what information is shared. Elicitation is not a license for a remote server to silently scrape user input.
The capability is negotiated as part of the MCP connection discussed in Part 2. A server can use a mode only when the client has declared that it supports it. In current Claude Code, the user-facing forms are:
- Form mode: Claude Code displays fields supplied by the server and returns the submitted answer.
- URL mode: Claude Code asks whether to open an external link, so the user can finish a step such as sign-in in the browser.
Claude Code's documentation says no special user configuration is required for these dialogs to appear. It also documents an Elicitation hook that can supply a programmatic response without showing a dialog. That shortcut is a client-side automation choice, not the general definition of elicitation in the MCP protocol. It should be configured with care: an automatic answer may be appropriate for a predictable, low-risk question, but not for a consent decision the user ought to see.
Why protocol version matters here
Elicitation is younger than the basic tools-and-resources model. The June 2025 specification explicitly introduced it as a feature whose design could evolve. Current Claude Code documentation describes form and URL modes, with the capabilities it declares varying by the protocol revision used on a connection.
The MCP specification has also been moving toward stateless operation and more explicit ways to resume work after user input. In that model, a server need not hold an entire request and connection open while a person thinks or switches to a browser; it can return a description of the missing input and enough state to continue later. That direction is useful for scalable server deployments, but it is important not to treat every revision's interaction details as interchangeable. Check the protocol version and client support when implementing or debugging elicitation.
The bigger picture
Tools, resources, and elicitation solve different problems:
| Capability | Direction | Main purpose |
|---|---|---|
| Tool | Client → server | Invoke an operation with structured arguments. |
| Resource | Client → server | Retrieve context identified by a URI. |
| Elicitation | Server → client → user | Obtain missing information while work is underway. |
The same MCP connection can make all three useful, but it does not force them into the same UI or permission path. An issue tracker may expose actions for editing issues, resources for reading existing issue data, and elicitation for a decision that cannot safely be inferred.
Next, the series changes perspective. Claude Code is not only an MCP client that connects to other servers; it can also run as an MCP server and offer capabilities to another client.
Top comments (0)