Part II: The Toolkit

Chapter 04

Tools, Function Calling & Protocols (MCP, A2A)

How agents use tools, how to design reliable function contracts, and how MCP and A2A standardize tool access and agent-to-agent delegation.

Tools are how agents touch the world. This chapter covers tool design that models can actually use, the Model Context Protocol, and the emerging agent-to-agent layer.

Function calling: the contract

Every tool is a contract: a name, a natural-language description, and a JSON schema of parameters. The model never executes anything — it emits a structured request ('call check_inventory with sku=A-114'), your runtime executes it, and the result is appended to context for the next reasoning step. Modern APIs harden this with strict structured outputs, guaranteeing the arguments parse against your schema. That mechanical reliability is solved; what still separates good agents from flaky ones is tool design:

  • Write descriptions for the model, not the docs site — state when to use the tool, when not to, and what it returns. Ambiguous descriptions are the top cause of wrong-tool calls.
  • Keep the toolbox small and orthogonal — ten well-separated tools outperform forty overlapping ones. Merge near-duplicates; split grab-bags.
  • Return errors the model can act on — 'date must be YYYY-MM-DD' lets the agent self-correct; a bare 500 forces a guess.
  • Make actions idempotent or confirmable — retries happen. Design tools so calling twice is safe, or require a confirmation token for irreversible operations.
  • Bound everything — timeouts, result-size caps, pagination. One tool returning a 200K-token blob can blow the context budget for the whole run.

MCP: the USB-C of agent tooling

Before late 2024, connecting M applications to N tools meant M x N bespoke integrations. The Model Context Protocol — released by Anthropic in November 2024 and since adopted across OpenAI, Google, and Microsoft products — replaces that with one open client-server standard over JSON-RPC: any MCP-capable app can discover and invoke any MCP server's tools, resources, and prompt templates.

BEFORE: N x M custom integrations
AFTER: N + M via one protocol
App A App B App C
App A App B App C
CRM Email DB Web
MCP — one open standard
CRM Email DB Web
12 brittle connectors to maintain
7 components, each built once

Figure 4.1 — The integration math that made MCP inevitable: M x N connectors collapse to M + N.

Adoption moved fast and is now measurable rather than anecdotal. The official registry held roughly ten thousand public server records by mid-2026, with GitHub showing about sixteen thousand repositories tagged as MCP servers. Stacklok's 2026 software survey found about 41% of organizations running MCP servers in limited or broad production. Governance matured too: the ecosystem now sits under the Linux Foundation's agentic AI umbrella, and the 2026 roadmap focuses on exactly the pains production surfaced — stateless transports so servers scale behind ordinary load balancers, a richer Tasks primitive for long-running work, and enterprise authorization.

HOST (your agent app / IDE / chat)
MCP Server: CRM
MCP Client
session, discovery, auth
model decides which tools to call;
client speaks JSON-RPC to servers
tools + resources
MCP Server: Postgres
query tools
MCP Server: Files
stdio (local) or streamable HTTP (remote)
read / write

Figure 4.2 — MCP architecture: a host embeds a client; servers expose tools, resources, and prompts.

Security note before you wire everything together

Treat MCP servers like any third-party dependency. Scope credentials per server, pin
versions, and remember that tool descriptions and tool results are inputs to your model — a
malicious or compromised server can attempt prompt injection through either. Allowlist
servers in production; never auto-install from the open registry.

A2A and the agent-to-agent layer

MCP connects an agent to tools. The complementary question — how independent agents discover and delegate to each other across vendors — is addressed by Agent2Agent (A2A), launched by Google in April 2025 and now also under Linux Foundation governance. Agents publish capability descriptions called Agent Cards; peers invoke them over HTTP with streaming updates for long tasks. Support is still uneven: Google's ADK generates Agent Cards natively and CrewAI added A2A delegation in 2026, while most other frameworks are earlier on the curve. IBM's ACP explored similar ground before consolidating into the same ecosystem. The pragmatic 2026 stance: use MCP for tool access today, design multi-agent seams so A2A can slot in, and don't force inter-agent messaging through MCP — teams

report meaningfully faster delivery using each protocol for its own layer.

Applications
support desks, coding agents, copilots, internal automations
Agent <-> Agent: A2A
Agent Cards, task delegation across vendors (Google, Apr 2025; Linux Foundation)
Agent <-> Tools: MCP
tools, resources, prompts over JSON-RPC (Anthropic, Nov 2024; ~10K public servers)
Models & runtimes
frontier APIs, open-weight models, local inference

Figure 4.3 — The 2026 protocol stack: MCP for the tool boundary, A2A for the agent boundary.

~10K

public MCP servers in the official
registry
MCP Registry, May 2026

41%

of orgs run MCP in production
(limited or broad)
Stacklok 2026 survey

2

open protocols cover tools
(MCP) and agents (A2A)
Linux Foundation AAIF