MCP - model context protocol
MCP (Model Context Protocol) standardizes how an LLM client discovers, lists and calls capabilities exposed by servers: tools (actions), resources (data) and prompts (templates). A single interface to integrate with any source.
What it is
MCP () is an open protocol that standardizes the conversation between an LLM client (the host, usually an IDE or chat app) and external servers that expose capabilities. Instead of each tool provider inventing its own API, every speaks the same JSON-RPC and every MCP client discovers everything the same way.
Think of USB-C for agents. The physical part changed once; the ecosystem won. The same idea here: the protocol changes once, and a server written for Claude Desktop works in Cursor, in Continue and in any host that forwards the message.
the notes in this topic are pinned to the specification revision 2025-06-18 of the Model Context Protocol. Later releases may introduce new capabilities (sampling, elicitation, roots) and change existing contracts; check the spec version the SDK declares before adopting.
Host, client and server: the topology
Three roles coexist in the specification. Confusing them is the most common mistake when reading the documentation.
host: the application where the user is (IDE, chat, agent). It hosts the clients and coordinates permissions. In general a host runs many clients.
client: lives inside the host, talks to a single server via JSON-RPC. It is the object that serializes the calls and negotiates capabilities.
server: the process that exposes tools, resources and prompts. It can run locally via stdin/stdout, or remotely via HTTP with SSE. It is where the integration logic lives.
The typical local transport is stdio: the host spawns the server as a subprocess and speaks JSON-RPC line by line. In distributed environments, the transport is Streamable HTTP, with POST for messages and GET with text/event-stream for notifications.
Host (Claude Desktop, Cursor, VS Code, own app)
|
| 1:N
|
+-- MCP Client (stdio) <--> local MCP Server (e.g. filesystem)
+-- MCP Client (stdio) <--> local MCP Server (e.g. postgres)
+-- MCP Client (HTTP+SSE)<--> remote MCP Server (e.g. SaaS API)
Transport is always JSON-RPC 2.0. Session state is per connection.Tools, resources and prompts
The server exposes three kinds of capability, each with a clear role in the agent's cycle:
tools: actions the model can invoke. Analogous to function calls: name, JSON schema, side effects. The LLM chooses when to call based on the description.
resources: data the host can read. Passive, identified by name or URI (e.g. file:///docs/spec.pdf, db://customers/42). The host decides when to include them in the context; the model only sees the content the host chose.
prompts: prompt templates the user invokes explicitly (e.g. '/summarize this file'). They are not discovered by the model; they live as slash commands in the host.
{
"name": "docs-server",
"version": "0.2.1",
"capabilities": {
"tools": { "listChanged": true },
"resources": { "subscribe": true, "listChanged": true }
},
"tools": [
{
"name": "search_docs",
"description": "Searches for relevant passages in the documentation base.",
"inputSchema": {
"type": "object",
"properties": {
"query": { "type": "string" },
"top_k": { "type": "integer", "default": 5 }
},
"required": ["query"]
}
}
],
"resources": [
{
"uri": "file:///docs/architecture.md",
"name": "architecture",
"mimeType": "text/markdown"
}
]
}How the client discovers capabilities
When the host brings up an MCP client, the first message is initialize, with the protocol version and the client's capabilities. The server responds with its own capabilities. From then on, the host calls tools/list, resources/list and prompts/list to assemble the available catalog.
Each capability can declare listChanged: true, indicating that the server will emit notifications/resources/list_changed or notifications/tools/list_changed when something changes. The host re-lists and updates the catalog without needing to restart.
import { Client } from '@modelcontextprotocol/sdk/client/index.js';
import { StdioClientTransport } from '@modelcontextprotocol/sdk/client/stdio.js';
const transport = new StdioClientTransport({
command: 'npx', args: ['-y', '@modelcontextprotocol/server-filesystem', '/docs'],
});
const client = new Client({ name: 'host', version: '1.0.0' }, { capabilities: {} });
await client.connect(transport);
const { tools } = await client.listTools(); // -> catalog for the LLM
const { resources } = await client.listResources(); // -> available data
const result = await client.callTool({
name: 'search_docs',
arguments: { query: 'how does checkpoint work', top_k: 3 },
});Strengths
- interoperability: one MCP server serves several hosts without rewriting; switching IDEs does not mean rewriting the integration
- dynamic discovery: tools and resources appear at connection time, without restarting the host
- clear separation of roles: tools are actions, resources are data, prompts are templates, with no ambiguity
- flexible transport: stdio for local, HTTP+SSE for distributed; the contract over the wire is the same
Limitations
- tools are still model actions: the server can call dangerous APIs, and authorization and sandboxing are left to the host
- the spec evolves fast: 2025-06-18 is this topic's pin; sampling/elicitation/roots are expanding areas
- remote debugging is harder: HTTP+SSE hides the lifecycle; logs and handlers are equally important
- trust on first connect: the host must trust the server; package signing and allowlists are still a deployment responsibility
connections on the map
- Tool callingspeaks the protocolMCP - model context protocol
updated on 14/10/2026 · sources to go deeper · report an error
in other domains
- Securing the agent itselfvibecodingevery connected MCP server widens what the agent can do
- Secrets ScanningappsecMCP server tokens leak the same way
Study before
test what you learned
Loading questions…