Toolsets, OpenAPI and Model Context Protocol

[samuelcolvin]

TL;DR I spoke to @dsp on Friday, and the plan is to add support for MCP to PydanticAI via something I'm currently calling "toolsets".

One of the things I've realised while building PydanticAI is that building tools to give agents access to resources is going to be quite resource intensive and repetative — say you want to build an agent to interact with slack, 90% of your time will be spend figuring out the slack API and dealing with auth and reties, not building the agent.

I therefore propose the following process to make this kind of thing easy with PydanticAI:

1. Add the concept of reusable "Toolsets" which contain multiple tools, their own state (e.g. http connection) and their own relation to agent dependencies
2. Add a Toolset to support OpenAPI scheme APIs - e.g. so you could register an API which has an OpenAPI schema in a few lines of code - this should cover many common cases where you don't need full bidirectional communications
3. Add support for registering MCP toolsets
4. Create our own toolsets for interacting with common tools like slack, gmail, search etc. - this should be simple since I think many of these are already build for MCP, see here

[skylarbpayne]

Was instantly thinking of this as I saw the release. I would love to help with this if you're looking for some extra hands!

[phil65]

Hello! Just stumbled over this, I´m working on a project which incoroporates many of the same ideas, but in a different way. It´s basically a backend for both mcp servers as well as pydantic-ai agents. Perhaps it´s interesting for you. :)

https://github.com/phil65/LLMling

[arjuna-dev]

This framework has a very nice collection of tools and keeps everything quite simple. Only a few of them are API related but a lot of them seem to be quite useful:

https://docs.griptape.ai/stable/griptape-tools/

[datajoely]

Hi Everyone, excited to see where this goes. The link between OpenAPI, Pydantic, FastAPI is so well established you don't need me to explain it! MCP is looking like the equivalent of OpenAPI for this world, so naturally we're starting to familiar looking libraries like this...

Using PydanticAI today against a well documented OpenAPI endpoint one has to essentially re-implement tools for each of the endpoints one has spent time documenting, validating and implementing on the FastAPI side. It would be really cool to imagine a future where one could:

• Point PydanticAI at an openapi.json definition and it would automatically register the discovered endpoints as tools. Today, the decorator only syntax doesn't really lend itself to this nicely.
• Point PydanticAI to an instantiated FastAPI app which has much more information than just the OpenAPI schema available (e.g. more complex model/field validators, docstrings that Griffle can scoop up etc).

[slavakurilyak]

+1 for Model Context Protocol support as their open-source tooling has grown quite a bit over the past 60 days

Toolsets can also assist in dealing with third-party data which is often raw and unstructured

[jonchun]

I've started an experimental implementation of MCP tools. It currently is a little hack-y right now and depends on #881

Unfortunately the official mcp python library requires 3.10+ which is incompatible with with pydantic's support for 3.9 -- I was too lazy to look into fixing the UV errors so i just bumped a bunch of stuff to 3.10, but for the official release we probably want to do something different

https://github.com/jonchun/pydantic-ai/tree/mcp

The meat of the change is in _pydantic.mcp_function_schema() that generates a function schema based off an MCP tool
main...jonchun:pydantic-ai:mcp

[dsp]

I've started an experimental implementation of MCP tools. It currently is a little hack-y right now and depends on #881

Unfortunately the official mcp python library requires 3.10+ which is incompatible with 3.9 -- I was too lazy to look into fixing the UV errors so i just bumped a bunch of stuff to 3.10, but for the official release we probably want to do something different

I can look into what it takes to use 3.9. We rely on some features like pattern matching and new union syntax , but if needed I think we can manage to downgrade

[jonchun]

@dsp - to be clear pydantic-ai already supports 3.9 and the problem is mcp (new dependency) only supports 3.10+. The issue would be not downgrading but rather supporting the mcp package on 3.9 (or choosing to drop support for 3.9 in pydantic ai)

[dsp]

@dsp - to be clear pydantic-ai already supports 3.9 and the problem is mcp (new dependency) only supports 3.10+. The issue would be not downgrading but rather supporting the mcp package on 3.9 (or choosing to drop support for 3.9 in pydantic ai)

Sorry. I am the maintainer of mcp, I meant 3.9 in the mcp sdk.

Notable 3.9 is going to EOL in October, so we would support it only for 8 months

[jonchun]

@dsp - That makes a lot more sense, thanks!

Bringing Python 3.9 support into MCP seems like unnecessary effort, especially since it’s reaching EOL in October. Instead, it might be worth exploring what it would take to drop 3.9 support for pydantic-ai. Maybe MCP support could be handled as a separate package for now and merged later when the time is right?

[datajoely]

I vote for killing 3.9 now 💀

[dsp]

@dsp - That makes a lot more sense, thanks!

Bringing Python 3.9 support into MCP seems like unnecessary effort, especially since it’s reaching EOL in October. Instead, it might be worth exploring what it would take to drop 3.9 support for pydantic-ai. Maybe MCP support could be handled as a separate package for now and merged later when the time is right?

That's one option. Selfishly I would love to say way more agents build around MCP so for I would be interested to make it as easy as possible to use MCP for Pydantic AI users, even if that means lowering the Python version on the MCP side.

[jonchun]

https://pypistats.org/packages/pydantic-ai

According to this, there's a decent number of 3.9 downloads (~1000/day) -- No idea how accurate these numbers are though.