Tools and the Model Context Protocol

How function calling works

A model can't run code, open a URL or query a database. What it can do is write text, and function calling (also called tool use) is a convention for writing a very particular kind of text: a structured request to run a named tool with specific arguments. Your code, the harness, does the actual work.

1. 1

   Describe

   You send the model a list of tools along with the conversation. Each tool has a name, a plain-language description, and a JSON Schema for its inputs.

2. 2

   Decide

   The model reads the descriptions and decides whether a tool would help. If so, it returns a tool call: the tool's name plus JSON arguments that match the schema. It can also return several calls at once.

3. 3

   Execute

   Your harness validates the arguments, runs the real function, and captures the output or the error.

4. 4

   Return

   You send the result back to the model, linked to the original call by an ID. The model continues: another tool call, or a final answer.

{
  "name": "search_orders",
  "description": "Search a customer's orders. Use this before answering any question about order status, refunds or delivery. Returns at most 20 orders, newest first.",
  "input_schema": {
    "type": "object",
    "properties": {
      "customer_email": {
        "type": "string",
        "description": "The customer's email address, exactly as given."
      },
      "status": {
        "type": "string",
        "enum": ["pending", "shipped", "delivered", "refunded"],
        "description": "Optional filter. Omit to return all statuses."
      },
      "since": {
        "type": "string",
        "format": "date",
        "description": "Only orders placed on or after this date (YYYY-MM-DD)."
      }
    },
    "required": ["customer_email"]
  }
}

Everything in that definition is read by the model, so everything is a prompt. The description says when to use the tool and what it returns; the enum stops the model from inventing a status like "in transit"; the date format tells it exactly how to write dates. The model's choice of tool and arguments is only as good as these words.

Designing tools agents can use well

Anthropic's guidance on agents puts it simply: invest as much effort in the agent-computer interface as you would in a human-computer interface. A badly designed tool causes failures that look like the model being dumb, when really the model was given an ambiguous or overloaded interface.

MCP: one protocol for tools and data

Before MCP, every agent framework had its own way to define tools, and every integration had to be rewritten for each one. Anthropic released the Model Context Protocol in November 2024 to fix that. MCP defines a standard way for an AI application to discover and use capabilities from external servers, so a GitHub or Postgres integration written once works in any MCP-compatible agent. In December 2025 Anthropic donated MCP to the Linux Foundation's Agentic AI Foundation (AAIF), where it is now governed alongside other agent standards.

• The host is the AI application the user interacts with, such as Claude, ChatGPT, VS Code, Cursor or goose.
• Inside the host, an MCP client manages the connection to one server.
• An MCP server exposes capabilities. It can run locally (over stdio) or remotely over HTTP.

Servers offer three core primitives. The difference between them is who decides when they are used, which is a useful design question for any capability you expose.

MCP tools can also carry annotations, added in the 2025-03-26 revision, that hint at their behavior: whether a tool is read-only, destructive, idempotent, or reaches out to the open world. Hosts use these hints to decide which calls need user approval. They are hints, not guarantees, so a host should only trust them from servers it trusts.

How the spec evolved

MCP versions are named by date. Each revision tells you what problem the community was hitting at the time: first remote access and auth, then richer interaction, then long-running work, and finally scale.

The 2026-07-28 stateless redesign

The maintainers call 2026-07-28 "the largest revision in the standard's history". The release candidate was locked on May 21, 2026, and the final spec shipped on July 28. The motivation was operational. Earlier versions assumed a long-lived session between one client and one server process, which made MCP servers awkward to scale behind load balancers or run on serverless platforms.

// 1. Client calls a tool
{ "method": "tools/call",
  "params": { "name": "book_room", "arguments": { "date": "2026-11-03" } } }

// 2. Server needs a decision before it can finish
{ "result": {
    "resultType": "input_required",
    "inputRequests": { "room": { "message": "Two rooms are free. Which one?",
                                 "options": ["Oak", "Pine"] } } } }

// 3. Client retries the same call with the answer attached
{ "method": "tools/call",
  "params": { "name": "book_room", "arguments": { "date": "2026-11-03" },
              "inputResponses": { "room": "Oak" } } }

The revision also formalized an extensions framework. Three features became official extensions rather than core spec: Tasks (long-running work, now with poll-based tasks/get and a new tasks/update), MCP Apps (interactive UIs, below) and Enterprise Managed Authorization (EMA), aimed at organizations that want MCP access governed through their own identity and authorization systems.

Finally, it deprecated Roots, Sampling and Logging, with a minimum 12-month window before removal, and the legacy HTTP+SSE transport. TypeScript, Python, Go and C# SDKs are Tier 1, and Rust is in beta.

Elicitation, structured output and MCP Apps

Three features added since mid-2025 make tools more interactive and easier for agents to rely on.

• Elicitation (2025-06-18) lets a server ask the user for input partway through an operation, with a schema describing what it needs, such as a confirmation or a choice between options. The user can accept, decline or cancel. This brings human-in-the-loop into the tool itself. URL-mode elicitation (2025-11-25) sends the user to a web page for flows that should never pass through the model, like a payment or an OAuth login.
• Structured tool output (2025-06-18) lets a tool declare an outputSchema and return machine-readable structuredContent alongside the usual text. Agents and hosts can validate and use the data directly instead of parsing prose.
• MCP Apps launched on January 26, 2026 as the first official MCP extension. A tool can return an interactive UI that renders in a sandboxed iframe inside the host, such as a chart, a form, or a design canvas. Claude, VS Code Insiders and goose supported it on day one, ChatGPT later that week, with partners including Asana, Figma, Slack, Canva, Box and Salesforce.

Authorization, the registry and trust

Remote MCP servers often act on a user's behalf: reading their email, filing tickets in their workspace. MCP uses standard OAuth 2.1 for this, and the details have tightened with each revision.

To find servers, there is an official MCP Registry, which secondary sources say reached general availability in September 2025. Third-party trackers estimate tens of thousands of listed servers by October 2026, most of them remote HTTP endpoints, though those counts have not been checked against the registry itself.

Scaling up: tool search, and where MCP stops

Connect ten MCP servers with twenty tools each and you have two hundred tool definitions, potentially tens of thousands of tokens, in context before the agent does anything. That wastes the attention budget from Module 3 and makes the model more likely to pick the wrong tool. The fix is the same progressive disclosure idea behind Agent Skills: tool search, also called deferred tool loading. The agent starts with a search tool and a short index, and loads the full definitions only for the few tools it actually needs.

MCP is excellent at one thing: letting an agent use capabilities it controls. A tool does what it is told and returns. But some of the most interesting work in 2026 involves delegating to things that are not tools at all, such as another company's agent with its own model, data, judgment and hours-long tasks. That is a different relationship, and it has its own protocol.

The two are complementary, not competing. A typical system uses MCP inside each agent to reach its tools, and A2A between agents to share work. Module 5 opens Track 2 with A2A: how agents discover each other through Agent Cards, how tasks, messages and artifacts flow between them, and what changed in version 1.0.