INTEGRATION

MCP Tools

The Model Context Protocol is a standard way for applications to hand an LLM its tools and data — so a tool is written once and works in any client that speaks it.

The Problem It Solves

Every tool built for every application, over and over

Without a protocol

Every pair is bespoke

Each application invents its own way to declare tools and pass results. Connecting a data source to an assistant means writing an integration specific to that pair, and writing it again for the next assistant.

M × Napplications × data sources
With MCP

One interface on both sides

Applications learn to speak MCP once. Tool authors implement a server once. Anything that speaks the protocol can talk to anything else without either side knowing about the other.

M + Nclients plus servers

Host, Client, Server

Three roles, and only the host ever talks to the model

Role 1

Host

The application the user is in. It owns the conversation, calls the model, and decides which servers to connect and what to allow.

an IDE, a chat app
→
Role 2

Client

A connector inside the host, one per server. It holds the session, translates between host and protocol, and keeps servers isolated from each other.

one per connected server
→
Role 3

Server

The program exposing capability: tools to call, resources to read, prompts to reuse. It knows nothing about the model or the conversation.

files, database, an API

The model never connects to a server. It only ever sees tool descriptions the host chose to show it, and asks the host to run one — exactly the tool-call loop from the agents page, with the wire format standardised.

What a Server Exposes

Three primitives, distinguished by who decides to use them

Tools

Actions that can be invoked, each with a JSON Schema describing its arguments. Searching, writing a file, querying a database, calling an API.

Chosen by: the model, subject to host approval

Resources

Readable context identified by URI — a file, a record, a page of documentation. Read, not executed, so exposing one has no side effects.

Chosen by: the application, or the user picking context

Prompts

Reusable templates the server offers, often surfaced as slash commands or menu entries. They package a known-good way to ask for something.

Chosen by: the user, explicitly

A Tool Definition

A name, a description written for the model, and a schema for the arguments

tools/list — what the server advertises
{
  "name": "search_invoices",
  "description": "Search invoices by customer and date range.
                   Returns matching invoice numbers and totals.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "customer": { "type": "string", "description": "Customer name" },
      "from":     { "type": "string", "format": "date" },
      "to":       { "type": "string", "format": "date" },
      "limit":    { "type": "integer", "default": 20 }
    },
    "required": ["customer"]
  }
}

The description is prompt engineering, not documentation — it is what the model reads when deciding whether this tool fits. The schema is the contract the host validates against before anything runs, which is what stops a malformed or invented argument from reaching your code.

A Session, Message by Message

MCP uses JSON-RPC, so every exchange is a request with a matching response

1
Client →
{ "method": "initialize", "params": { "protocolVersion": "...", "capabilities": { ... } } }
2
← Server
{ "result": { "serverInfo": { "name": "invoices" }, "capabilities": { "tools": {}, "resources": {} } } }
3
Client →
{ "method": "tools/list" }
4
← Server
{ "result": { "tools": [ { "name": "search_invoices", "inputSchema": { ... } } ] } }
5
Client →
{ "method": "tools/call", "params": { "name": "search_invoices", "arguments": { "customer": "Acme", "from": "2024-01-01" } } }
6
← Server
{ "result": { "content": [ { "type": "text", "text": "3 invoices, total 4,180.00" } ] } }

Steps 1–4 happen once, at connect time. Steps 5–6 repeat for every tool the model asks for, and the result in step 6 goes back into the conversation as the observation the next turn reasons over.

How Client and Server Connect

The same messages, carried two different ways

stdio

Local subprocess

The host launches the server as a child process and speaks over standard input and output. Nothing listens on a port, the server inherits local credentials, and its lifetime is tied to the host. The usual choice for filesystem and developer tooling.

HTTP

Remote server

The server runs as a service reached over HTTP, with streaming for messages pushed back to the client. Suits shared and hosted integrations — and moves authentication and network policy to the front of the design.

Worth Knowing

Practical consequences of putting a protocol in the middle

Tools cost context

Every advertised tool's name, description and schema sits in the prompt on every call. Connecting a dozen chatty servers spends tokens before the user types anything.

Descriptions decide accuracy

Models pick tools by reading descriptions. Two similarly worded tools get confused; a vague one gets called at the wrong moment or never at all.

The host holds the permissions

The protocol carries the request; it does not decide whether it should run. Approval, sandboxing and rate limits are the host's job.

Results are untrusted input

Whatever a server returns enters the model's context. If it contains instructions, a naive agent may follow them — treat tool output as data.

Servers are composable

A host can connect several at once, so capability is added by attaching a server rather than by rebuilding the application.

It is model-agnostic

Nothing in the protocol assumes a particular provider. The host maps MCP tools onto whatever tool-calling format its model expects.

Back to the start

What is an LLM?

You have come full circle — from what a model is to the protocol that gives it hands