Clear logo

MCP Resources Are Underrated

11 Dec 2025
Ankit Solanki
Co-founder at Clear. Exploring all possibilities of AI.
Engineering

MCP is here to stay. It's become a Schelling point for the community, and I feel it will continue to gain traction. Just as I was writing this, I noticed that Anthropic has donated stewardship of the MCP protocol to the Agentic AI Foundation.

We've been thinking deeply about our MCP integration story, and I have recently started to build strong conviction that MCP Resources are criminally underrated. To understand why resources are useful, let's first understand the problem with MCP tools.

MCP Tools have a context problem

A typical MCP integration works like this:

  • The agent's harness exposes MCP tools to the LLM provider
  • In response to a completion API, the LLM may invoke an MCP tool
  • This tool's response is given back to the LLM

An MCP server could expose any tool. For example: a Google Drive MCP could be exposing files on a connected Google Drive; and these files could wildly vary in sizes.

What happens if the tool response is huge?

Large tool responses are a problem

Naive solution: send the whole response to the LLM? This is expensive: maybe the tokens consumed here could be better used elsewhere? Maybe the response is larger than the LLM supports and your agent crashes?

Truncating MCP tool responses

Another option is truncation. Either the MCP server itself could truncate large results, or the agent harness should anyway truncate results over certain sizes.

This gives you safety: MCP tool calls cannot consume unlimited tokens. But this comes at the cost of context loss: who decides what to truncate? What if the most critical information needed for the agent was truncated?

MCP Resources are a solution

The MCP protocol has support for resource templates:

Resource templates allow servers to expose parameterized resources using URI templates.

Resources are exposed as URIs. Critically: a tool response could contain resource links, and we have the agent harness access the entire resource.

Tools returning MCP resource URIs

This means:

  • Large responses from tools can be converted to resources
  • Agents and agent harnesses can inspect resources directly
  • Depending on your system design, you could compose these together with other LLM tools and get to interesting emergent behaviour.

Here's an example:

// Request
{
  "method": "tools/call",
  "params": {
    "name": "read_google_drive_file",
    "arguments": {
      "id": "c85b4851-bd61-4352-84a2-6e0c6b6d3dce"
    }
  }
}

// Response without Resources
{
  "content": [
    {
      "type": "text",
      "text": "...... huge text"
    }
  ]
}

// Response with Resources
{
  "content": [
    {
      "type": "text",
      "text": "...... small text snippet"
    },
    {
      "type": "resource_link",
      "uri": "gdrive://file-id-123"
    }
  ]
}

This can enable composition:

  • The agent's harness could read the resource and save the file to disk
  • The agent could then use other local tools (eg: read_file, grep, execute_code, etc) to further process this file.

The MCP protocol in fact has a first-party way of doing this: resource links:

A tool MAY return links to Resources, to provide additional context or data. In this case, the tool will return a URI that can be subscribed to or fetched by the client.

Most MCP servers don't expose resources though. This part of the protocol seems really unexplored and under-appreciated.

Addendum: Code Execution

Anthropic recently wrote about a different pattern: using code execution to interact with MCP servers. This is a really powerful pattern, though I feel it's something that can be combined with MCP Resources.

  • MCP servers are fast becoming a glue layer
  • Any given MCP server doesn't know which type of client would connect to it.
  • The server doesn't know if the client is using code execution or just LLM tool calls.
  • Thus, well-behaved servers need to be defensive about context usage in tool calls, and large responses will end up being truncated somehow.
  • Resources are the officially blessed way to expose data to clients.

Code execution doesn't remove the need for MCP resources. It makes MCP resources even more useful!

We're adopting this MCP resource-link pattern heavily in servers we control. Our agents will support this pattern as well. Unfortunately, MCP Server authors need to start adopting this pattern for it to gain traction though.

We're hoping that this post can spark a discussion about this.

← Back to all posts