Defining MCP Resources for Data Access

Resources in MCP servers allow you to expose data to clients, similar to GET request handlers in a typical HTTP server. They are perfect for scenarios where you need to fetch information rather than perform actions. Tools are about doing something, often with side effects, and Claude decides when to use them. Resources are about reading data, and your application code typically decides when to fetch them, often to inject context into a prompt or to populate a UI element like an autocomplete list. So you reach for tools when the model should act, and you reach for resources when your app needs data.

Imagine a feature where users type the at sign followed by a document name to reference a file. This requires two operations. First, getting a list of all available documents so you can show an autocomplete dropdown. Second, fetching the contents of a specific document when one is mentioned. Both of these map cleanly onto resources. When the user actually mentions a document, your system fetches its contents through a resource and automatically injects them into the prompt sent to Claude, eliminating the need for Claude to make a separate tool call to fetch that information. The result is a faster, smoother experience.

Resources follow a request-response pattern. When your client needs data, it sends a read resource request with a URI that identifies which resource it wants. The MCP server processes that request and returns the data inside a read resource result. The flow looks like this: your application code asks the MCP client for a resource, the MCP client forwards the request to the MCP server, the server processes the URI, runs the appropriate function you registered, and returns the result back through the client to your code. From your application's perspective, fetching a resource is just one function call.

There are two types of resources. Direct resources have static URIs that never change. They are perfect for operations that do not need parameters, like getting the full list of documents. Templated resources include parameters in their URIs, like a URI that contains a document ID placeholder. The Python SDK automatically parses those parameters out of the URI and passes them as keyword arguments to your function. So you write a single function for fetch document by ID, register it with a templated URI, and the SDK dispatches every matching request to your function with the parsed arguments.

Resources can return any type of data, including strings, JSON objects, and binary data. You use a MIME type parameter to give clients a hint about what kind of data you are returning. Common values include application slash json for structured data, text slash plain for plain text, and application slash pdf for binary files. The MCP Python SDK automatically serializes your return values, so you do not need to manually convert objects to JSON strings. You just return the natural Python data structure, mark the MIME type, and the SDK handles the rest of the wire format.

You can test resources using the MCP Inspector. Start your server with the MCP development command pointed at your server file, then open the Inspector in your browser. You will see two distinct sections: Resources, which lists your direct, static resources, and Resource Templates, which lists your templated resources. Click on any resource to test it. For templated resources, the Inspector prompts you to provide values for each parameter in the URI template. The Inspector then shows the exact response structure your client will receive, including the MIME type and the serialized data, so you can verify everything works before integrating with a real client.