MCP tool calling can connect autonomous agents and tools without either side being designed around the other.
2
MCP sampling lets a tool that needs an LLM proxy its request through the client instead of managing separate model access.
3
Putting inference inside an MCP tool can keep SQL instructions and other specialist context out of the main agent's context window.
Summary
Samuel Colvin argues that MCP can cover much of the agent-to-agent communication work that people are trying to solve with new protocols. His focus is autonomous agents and custom Python code, rather than MCP's original desktop and coding-agent use case. He concentrates on tool calling, then explains why MCP adds features that a simple OpenAPI description would not provide, including dynamic tools, streaming logs, sampling, tracing, and standard-input/standard-output operation. The main technical example is a research agent that queries BigQuery for PyPI download data. A nested agent inside the MCP tool writes and validates SQL, retries failed queries, and sends progress logs through MCP. Sampling allows that nested agent to use the main client's LLM access. Colvin also shows how Logfire traces the client, server, nested agent, model calls, and generated SQL. The argument is practical rather than absolute. MCP is not all anyone needs, but it can avoid unnecessary protocol proliferation.
MCP tool calling fits autonomous-agent code even though that was not its original focus
Colvin separates his use case from MCP's original emphasis on desktop and coding agents such as Claude Desktop, Cursor, and Windsurf. Prompts and resources matter in those environments, but he says they do not apply much to autonomous agents written in custom code. Tool calling is the MCP primitive that matters most here. Its basic design lets an agent connect to tools without being built specifically for them, while the tools can work without knowing the agent. Colvin compares this with browsers and websites communicating over a shared protocol.
MCP adds capabilities that a plain OpenAPI tool description does not cover
Colvin answers the common question of why MCP could not simply be OpenAPI. He points to tools that can appear or disappear as server state changes, logs returned while a tool is still running, and sampling, which lets a server request an LLM call through the client. He also mentions tracing and observability. MCP's ability to run effectively as a subprocess over standard input and standard output is another practical difference. These features matter when a tool call is a long-running or stateful part of an agent execution.
Sampling lets nested MCP agents borrow the client's model access
A more complex MCP system can contain tools that are themselves agents. Those nested agents may need to call an LLM, which otherwise means configuring model access and paying for a separate connection on every remote server. Sampling lets the MCP server send an LLM request back through the client. The client proxies it to the model, returns the response to the server, and the tool continues. Colvin calls sampling powerful, while noting that it was not widely supported at the time of the talk. Pydantic AI supports it on both the client and server sides.
A nested research tool can generate and validate its own SQL
The demonstration uses a research agent and an MCP tool that queries the BigQuery public dataset for PyPI download counts. Pydantic AI supplies dependencies, output validation, and retries. The validator removes markdown code fences from generated SQL, checks the table name, runs the query, and raises model retry if the query fails. That sends feedback to the LLM so it can try again. The query results are converted into a list of dictionaries and formatted as XML, which Colvin says models are good at reviewing.
MCP context logs can show progress before a long tool call finishes
The tool receives an MCP context object and calls its log function during execution. Those messages travel back to the client and ultimately to the user before the tool has completed. Colvin describes this as useful for a coding-agent interface, where a user needs to know that work is still happening, and for a web application running deep research that may take minutes. MCP also has a progress concept for cases where the tool can report how far through a query it is.
Inference inside the tool keeps specialist instructions out of the main agent
The MCP server registers a PyPI downloads tool with a description and passes the user's question into it. Colvin says the central agent could generate the SQL itself, but that would require placing SQL instructions and table details in the main tool description. Models do not seem to like that much data in a description, and sending it to the main agent adds context overhead on every call. Having the MCP tool run its own inference keeps the SQL-specific context local. The main agent can then call the tool with a natural-language request.
Logfire exposes the nested client-server and sampling calls
Colvin uses Logfire to inspect the execution trace. The outer agent calls a model, which decides to call the MCP tool. The MCP client calls the MCP server, and a separate Pydantic AI agent inside that server calls an LLM through the client using sampling. The trace makes the repeated client-server path visible. It also shows the XML-like query result returned to the outer agent and the final natural-language response. Colvin then opens the nested agent span to inspect the exact SQL that it generated.
"There are an awful lot of things that MCP can do and that people are over complicating the situation sometimes trying to come up with new ways of doing agent-to-agent communication."01:30
Who should watch
You are building autonomous agents in Python and are deciding whether to adopt MCP or another agent communication protocol.
Your tools need their own model calls, progress updates, validation retries, or access to detailed traces.
You want to keep specialist instructions, such as SQL generation rules, out of the context sent to a main agent.
