`Toolset`, take 3

[samuelcolvin]

Toolsets live again! Phoenix of #110

Rough working:

from abc import abstractmethod, ABC
from contextlib import asynccontextmanager


mcp_thing = MCPThing()

agent = Agent(
    mcp_servers=[mcp_thing],
)

# ---
#
class Toolset(ABC):

    async def __aenter__(self, run_context, sampling_callback, agent_name: str):
        pass

    async def __aexit__(self, exc_type, exc_val, exc_tb):
        pass

    @abstractmethod
    async def list_tools(self):
        return []

    async def call_tools(self, tools) -> list[Part]:
        ...

agent = Agent(
    toolset=mcp_thing,
)

agent = Agent(
    toolset=[
        FilterToolsToolset(MCPToolset(mcp_thing1), exclude='foo'),
        MCPToolset(mcp_thing2),
    ],
)

@agent.tool
def foo():
    pass


agent.run_sync()

async def main():
    async with agent.run_toolsets():

[JimFuller-RedHat]

indirectly related observation: It can be somewhat awkward dealing with tools and mcp 'tools' as separate abstractions ... often we want to interact/manage them in the same manner and wonder how toolsets could help with that.

In your example, I would like to composite up toolset equally with natively defined func tools:

agent = Agent(
    toolset=[
        FuncTools(foo)       
        MCPToolset(mcp_thing2),
    ],
)

Not sure if this makes sense, and maybe I have missed some other pydantic_ai abstraction that enables this.

[samuelcolvin]

Yes, that's exactly what we're talking about

[DouweM]

Something to consider: MCP servers can take additional metadata alongside tool args: #2000

[DouweM]

Something to consider: users want to be able to register entirely new tools during an agent run: #1814

[DouweM]

• AG-UI Protocol Integration with Pydantic AI #1864 will require support for frontend tools that are executed outside of an agent run, with results passed into the next run via message_history. That means the original run should be able to end when it calls toolset.call_tool and gets some value indicating it's pending. That value would almost function like a promise that would be resolved with an actual value (by tool call ID?) on the next run.

This could also be useful in:

• Multi-turn user prompting #2019, where a tool may stand in for getting a human into the loop
• Human-in-the-loop approval of tool calls #1995, where the user wants specific tool calls to require user approval (although here the tool would be able to run uninterrupted on the next run once approval is given, instead of the return value being provided at new-run time)