warming up your workspace

How AI agents talk to tools, and to each other

The story of 2026 in AI is not just bigger models, it is agents finally crossing into production: surveys put agent adoption around 79% of organizations. The unglamorous reason that became possible is a protocol. An agent is only as useful as the tools it can reach, and until recently every tool integration was bespoke glue. The fix was a standard, the way USB-C ended the drawer of incompatible chargers.

Two standards matter: one for an agent to talk to tools (the Model Context Protocol, MCP), and an emerging one for agents to talk to each other (agent-to-agent). Both are simpler than the hype suggests, they are mostly well-structured JSON.

The one idea: a tool is a typed function with a description

For a model to use a tool, it needs three things: the tool's name, a human-readable description of what it does, and a schema for its inputs. That is it. With those, the model can decide when to call it and how to fill in the arguments. A tool definition is just:

{
  "name": "get_weather",
  "description": "Get the current weather for a city.",
  "input_schema": {
    "type": "object",
    "properties": { "city": { "type": "string" } },
    "required": ["city"]
  }
}

The model reads the description to decide relevance and the schema to format the call. Everything else is plumbing around this contract.

The problem MCP solves: N×M glue

Before a standard, every agent (Claude Code, an IDE, a chatbot) needed custom code to talk to every tool (your database, GitHub, a file system). That is N agents × M tools = N×M bespoke integrations, and none of them reusable.

MCP turns that into N+M. A tool author writes one MCP server exposing their tool; any MCP-speaking agent can use it with zero custom code. The "USB-C for AI tools" line is exactly right: define the port once, and everything that speaks it interoperates.

What an MCP exchange looks like

MCP is a client-server protocol over JSON-RPC. The agent (client) asks a server what it offers, then calls it. Stripped down:

// 1. client asks the server what tools it has
{ "method": "tools/list" }

// 2. server answers with tool definitions
{ "result": { "tools": [ { "name": "get_weather", "description": "...", "input_schema": {...} } ] } }

// 3. client calls a tool
{ "method": "tools/call",
  "params": { "name": "get_weather", "arguments": { "city": "London" } } }

// 4. server returns the result, which becomes the agent's next observation
{ "result": { "content": [ { "type": "text", "text": "London: 14C, light rain" } ] } }

Three details that matter:

  • Discovery is dynamic. The agent asks tools/list at runtime, so it learns what a server can do without being recompiled. Plug in a new MCP server and the agent can use it immediately.
  • The result is fed back as an observation, which slots straight into the agent loop: the model calls a tool, the server's result re-enters the conversation, the model decides what to do next.
  • MCP also standardizes more than tools — it exposes resources (readable context like files) and prompts (reusable templates), all over the same JSON-RPC channel.

Agents talking to agents

The next layer up is interoperability between agents. Instead of one agent with many tools, you get a network of specialist agents (a research agent, a coding agent, a billing agent) that delegate to each other. The emerging agent-to-agent protocols apply the same move one level higher: a standard way for an agent to advertise its capabilities and accept a task, so a coordinator can hand work to whichever agent is best for it, without bespoke wiring between every pair.

It is the same lesson as MCP: agreeing on the interface is what turns isolated demos into a composable system. This is why "interoperability" keeps showing up as the enterprise-AI story of 2026, the models were ready; the plumbing wasn't.

Why this is worth understanding

It is tempting to think the intelligence is the whole game. But a model that can't reach your data is a very smart text box. What made agents useful this year was boring standardization: a typed function with a description, discovered at runtime, called over JSON-RPC, with results fed back into the loop. Once you see that shape, MCP and agent protocols stop being buzzwords and become "the obvious interface, finally agreed on."

And you can build both sides: a tool definition is a name plus a schema; an MCP server is a thing that lists and calls those. If you want to build agents from their parts rather than just prompt them, the loop, the tools, the protocols, that is the kind of system-building the AI track is about.

Sources