What is MCP?

What MCP standardises, and what it does not

Before MCP, every harness invented its own way of describing external tools: one shape for Claude Desktop, another for a custom agent framework, a third for an IDE plugin. The same GitHub or Postgres integration ended up rewritten for each host. MCP defines the wire between them. A server declares the tools, resources and prompt templates it offers over JSON-RPC 2.0, and any client that speaks the protocol can list them, call them and stream their output.

What MCP does not change is how a model asks for a tool to run. The model still emits a structured tool call back to your program, and your program still decides whether to execute it. MCP sits one layer out from that: it is how the host learned that the tool existed in the first place, and how it will forward the call to whichever process owns the implementation.

How is an MCP server actually structured?

An MCP server is a process that answers JSON-RPC requests over one of the defined transports: stdio for a local subprocess, or Streamable HTTP for a remote service. It advertises three kinds of primitive. Tools are functions the model can request, with a name, a description and a JSON Schema for arguments. Resources are read-only pieces of context identified by URI, like a file or a database row, that the client can attach to a request. Prompts are named templates a user can pick from a menu in the host.

The client discovers all three by calling tools/list, resources/list and prompts/list after the initial handshake. Servers can also declare capabilities the other way: sampling lets a server ask the client's model to complete something on its behalf, and roots let the client tell the server which filesystem paths are in scope. Every message is versioned, so a client and server negotiate a protocol revision before doing anything else.

Security lives at the client, not the protocol

MCP is a transport and a schema. It does not authenticate a user, it does not decide whether a tool call is safe to run, and it does not sandbox the server process. Those decisions belong to the host that embeds the client. In practice this means the same guardrails you would apply to any tool integration still apply: scope credentials to the server that needs them, keep destructive operations behind an explicit approval, and treat content that comes back from a resource as untrusted input.

The prompt injection surface is worth naming. A resource that a server fetched from the open internet, or a tool result that quotes a ticket description, can contain instructions aimed at the model. MCP does not filter that content, and neither does the model. If your host runs tools without a human in the loop, the boundary is your validation code, not the protocol.

MCP in a real developer workflow

The payoff shows up when the same server is reused. A Postgres MCP server you wrote for one editor also works in another IDE, in a terminal agent, and in a hosted assistant, as long as each is a compatible client. The Model Context Protocol organisation on GitHub maintains reference servers for filesystem, Git, GitHub, Slack and others, plus SDKs in TypeScript, Python, Go, Kotlin and C#, so most integrations start from a template rather than a blank file.

Adoption grew quickly through 2025: Anthropic shipped MCP in Claude Desktop and the Claude API, OpenAI added MCP support to the Agents SDK and ChatGPT desktop, and Google announced it for Gemini. Because the spec is versioned and open, a server written today will keep working as new clients arrive, which is the point of standardising the boundary at all.

client starts the server as a subprocess:
  $ npx -y @modelcontextprotocol/server-filesystem /work/repo

client sends (JSON-RPC over stdin):
  {"jsonrpc":"2.0","id":1,"method":"initialize",
   "params":{"protocolVersion":"2025-06-18",
             "capabilities":{},
             "clientInfo":{"name":"demo","version":"0.1"}}}

server replies:
  {"jsonrpc":"2.0","id":1,
   "result":{"protocolVersion":"2025-06-18",
             "capabilities":{"tools":{},"resources":{}},
             "serverInfo":{"name":"filesystem","version":"0.6.2"}}}

client sends:
  {"jsonrpc":"2.0","id":2,"method":"tools/list"}

server replies with the tool catalogue:
  {"jsonrpc":"2.0","id":2,
   "result":{"tools":[
     {"name":"read_file",
      "description":"Read a UTF-8 file inside an allowed root.",
      "inputSchema":{"type":"object",
        "properties":{"path":{"type":"string"}},
        "required":["path"]}},
     {"name":"write_file", "description":"...", "inputSchema":{"...":"..."}}
   ]}}