Support for MCP resources

[hayk-corpusant]

Description

It seems like Pydantic AI only supports MCP Tools, not resources: https://modelcontextprotocol.io/docs/concepts/resources

These are a core part of the MCP protocol

References

No response

[samuelcolvin]

What do you think we should do to resources? Just add them to the context in all cases?

[BrandonShar]

FWIW, I think adding them all to context all the time makes the most sense. I like the idea behind requesting them as-needed, but that blurs with tool-usage so much in practice that I think I would struggle to pick between them.

[akhilbatra-angelone]

Resource calls can be parameterised for HTTP API integrations with GET methods. Client/Agent may want to filter resource on the params. Might not be a good idea to put all of it in context.

Frameworks like FastMCP consume OPENAPI specs and put all GET endpoints to resources by default unless custom routed.

[fennb]

If all MCP provided tools are added by default it is, if nothing else, consistent to have all resources (and resource templates?) added as well?

How well an agent does at actually picking/choosing remains to be seen. Some means of filtering/selecting them on an agent/MCP server basis seems nice at face value, but given their dynamic nature, I can see that being problematic.

[Kludex]

How, when and where would you folks expect resources to be added?

Should we handle MCP resources the same way as we handle tools? Or... If it's static we should add to the instructions, and dynamic as tools? I don't have an answer.

[timesler]

I think resources have to be read only when needed, not up front. There can be an arbitrary amount and they can be very large, and they can also do arbitrarily complex things on the server when the client reads them. I think it's maybe also not even possible to know all resource URIs since they can be parameterized with path parameters

I think the best way to enable access to them is by making them available via a resource reader (that can resolve URIs across multiple Mcp servers) in RunContext.

We have built out support for MCP resources in our code base by adding a resource reader to the dependency object, which works well and enables us to dynamically fetch things we want when building system prompts or making tool calls. But it would be great if resource reading could be available directly on the the ctx.state or something like that

Much less important for now, but resource subscription and unsubscription would also be great, but feels like that will be more challenging

[shlomi-schwartz]

Strong +1 on adding MCP Resources. In addition to static discovery, it would be very useful to support programmatic, on-demand registration at runtime (parity with Claude Desktop). Common cases include:

a user-supplied artifact (e.g., an image to analyze) attached for the current turn, and

a curated prompt introduced by an MCP server as part of a standard workflow.

Ideally these resources would be ephemeral and scoped to the run/session, addressable via URI, and appear in resources/list so the model can reference them. This aligns with the MCP resources model and would make Pydantic AI far more practical in real applications.

[zilto]

FWIW, I think adding them all to context all the time makes the most sense. I like the idea behind requesting them as-needed, but that blurs with tool-usage so much in practice that I think I would struggle to pick between them.

Indeed, it's blurry because everything MCP is "code to be executed", but the MCP specs intend to define different things (reference):

• Tool: something the LLM can use and request; the LLM is aware of the available tools, but not resources or prompts. According to specs, users can't / shouldn't tell the LLM what tool to use
• Resource: something available to the application (e.g., IDE); maybe the application retrieves it automatically or has a UI element to allow the user to select a resource. For example, automatically or manually adding a docs page to the context.
  • Resource are statically defined, but "resource templates" allow to dynamically define resources (this starts to look a lot like a tool...)
• Prompt: something available to the user; it's a piece of text the MCP surfaces to the user; you can think of them as natural language commands; the IDE and the LLM are not aware of prompts and treat them as regular user inputs
  • Again, you can template prompts, making it look a lot like a tool...

It's a bit convoluted and MCP implementation rarely follow these conventions, but the distinction appear useful if properly implemented by both servers and clients