Tool Calling and MCP (Model Context Protocol) Explained

Tool calling: how a model "uses" software

An LLM only produces tokens; it cannot open a file or call an API by itself. Tool calling (also called function calling) bridges the gap:

1. Your application sends the model the conversation plus a list of tools, each with a name, a description and a JSON Schema for its parameters.
2. If a tool would help, the model replies with a structured tool call instead of (or alongside) text: {"name": "get_weather", "arguments": {"city": "Shanghai"}}.
3. Your code validates the arguments, executes the tool and sends the result back as a tool message.
4. The model reads the result and either answers or calls another tool.

sequenceDiagram
  participant App as Your application
  participant LLM as Model
  participant Tool as Tool / API
  App->>LLM: messages + tool definitions (name, description, JSON Schema)
  LLM-->>App: tool_call get_weather(city="Shanghai")
  App->>Tool: execute (after validation and permission check)
  Tool-->>App: temp_c=21, sky=cloudy
  App->>LLM: tool result
  LLM-->>App: "It is 21 °C and cloudy in Shanghai."

A tool definition looks like this (format varies slightly by provider — see the OpenAI and Anthropic docs):

{
  "name": "search_issues",
  "description": "Search GitHub issues in one repository. Use for questions about bugs or feature requests. Returns at most 20 issues with number, title, state and URL.",
  "input_schema": {
    "type": "object",
    "properties": {
      "repo":  { "type": "string", "description": "owner/name, e.g. 'ollama/ollama'" },
      "query": { "type": "string", "description": "keywords; supports 'is:open'" }
    },
    "required": ["repo", "query"]
  }
}

The model was trained to emit such calls; the security boundary is your code, which decides what actually runs.

Why a protocol was needed

Before MCP, every AI application integrated every tool separately: M apps × N tools = M×N custom integrations. The Model Context Protocol (MCP), introduced by Anthropic in November 2024 (announcement), makes it M + N: a tool provider writes one MCP server, and any MCP-capable application can use it. It is often described as "USB-C for AI apps".

MCP architecture

flowchart LR
  subgraph Host["Host application (desktop assistant, IDE, coding agent)"]
    LLM["Model"]
    C1["MCP client"]
    C2["MCP client"]
  end
  C1 <-->|"stdio (local process)"| S1["MCP server: files / git / browser"]
  C2 <-->|"Streamable HTTP + OAuth"| S2["Remote MCP server: SaaS / database"]

• Host – the AI application the user runs; it contains the model loop and creates one client per server connection.
• Server – exposes capabilities. Messages are JSON-RPC 2.0; servers run locally over stdio or remotely over Streamable HTTP, with an OAuth-based authorisation model for remote servers (specification).

Servers offer three primitives (architecture):

Clients can also offer features to servers, such as sampling (letting a server ask the host's model for a completion), roots (which folders a server may see) and elicitation (asking the user for input). On connection, client and server negotiate versions and capabilities; the client then lists the tools and passes their definitions to the model.

Many apps listed on this site act as MCP hosts or servers — e.g. Claude, Claude Code, Cherry Studio and 5ire as clients; iMCP (macOS Messages, Contacts, Reminders, Calendar) and Peekaboo (screen capture) as servers.

MCP and A2A

MCP connects an agent to tools and data ("vertical"). The Agent2Agent protocol (A2A), started by Google, connects agents to each other ("horizontal"): an agent publishes an Agent Card describing its skills and endpoint, and other agents delegate tasks to it (a2a-protocol.org). In December 2025 MCP was contributed to the newly formed Agentic AI Foundation under the Linux Foundation (press release), and A2A joined it in August 2026, so both are now vendor-neutral standards. More in A2A and Multi-agent Systems.

Writing tools agents can actually use

Tool quality is one of the biggest levers on agent success (How AI Agents Work). Practical rules, consistent with Anthropic's guidance on writing tools for agents:

1. Describe purpose and limits – when to use the tool, when not to, what it returns.
2. Fewer, task-shaped tools beat thin wrappers around every API endpoint; avoid near-duplicates that confuse selection.
3. Clear parameter names, types, enums and examples in the schema.
4. Return concise, relevant output – paginate or filter; don't dump 10,000 lines into the context.
5. Actionable errors – "repo not found; expected 'owner/name'" helps the model recover; a stack trace does not.
6. Least privilege and approvals – read-only by default; destructive actions need confirmation. Tool descriptions themselves can be an attack vector (Prompt Injection and Tool Poisoning).

Try it

Connect a local MCP server to an MCP-capable desktop app, ask a question that requires it, and inspect the tool calls the app shows. Then read the server's tool descriptions: you are reading the prompt the model sees.