Accessing MCP Resources from a Client

Resources in MCP allow your server to expose information that can be included directly in prompts, rather than requiring separate tool calls to access data. This creates a much more efficient way to provide context to AI models. Instead of asking Claude to call a tool to fetch a document and then waiting for that round trip, your application can pull the document content as a resource and put it straight into the prompt. The model sees the data immediately as part of its context, with no extra latency, and can start reasoning about it right away. That makes the user experience feel much faster and smoother.

In a typical implementation, your client recognizes resource requests through user input patterns. For example, when a user types something like what is in the at sign followed by a document name, your code parses that input, recognizes the at-mention as a resource request, and sends a read resource request to the MCP server with the appropriate URI. The server returns a read resource result containing the actual content. Your client then injects that content into the prompt before sending it to Claude. The user just sees the natural at-mention syntax, while behind the scenes the resource protocol does all the work of fetching the data.

To enable resource access in your MCP client, you implement a read resource function. You will need a couple of imports: the standard library JSON module for parsing structured data, and the AnyUrl type from Pydantic for representing the resource URI. The core function makes a request to the MCP server through the session and processes the response based on its MIME type. The function takes a URI as an argument, awaits the session's read resource method, looks at the result, and returns the parsed contents to your application code. With that one method, the rest of your app can fetch any resource the server exposes.

When you request a resource, the server returns a result that contains a contents list. You access the first element since you typically only need one resource at a time. The response includes the actual content, which can be text or binary data, a MIME type that tells you how to parse the content, and other metadata about the resource. Your job in the client is to read that MIME type, decide how to parse the content accordingly, and return a useful Python value to your application. The list structure exists because the protocol allows for multiple content blocks, but most implementations only need the first one.

Your read resource function checks the MIME type to decide how to process the content. If the MIME type is application slash json, you parse the text as JSON and return the parsed Python object, so the rest of your code can work with a real dictionary or list. Otherwise, you return the raw text content as it is. This simple branching handles both structured data, like a list of documents, and plain text documents seamlessly. If you later need to handle binary data or another structured format, you just add another branch to the same function.

Once resource access is implemented, you test it through your command line application. When the user types the at sign, the system shows available resources in an autocomplete list. They select a resource using the arrow keys and the space key. The selected resource's content is included directly in the prompt that gets sent to the model, with no extra tool calls needed. This creates a much smoother user experience compared to having the model make separate tool calls. The resource content becomes part of the initial context, allowing the model to respond immediately about the data.