MCP (Model Context Protocol) is an open protocol that standardizes how an AI application discovers and calls external tools and data sources, using JSON-RPC 2.0 over a small set of defined transports. A tool exposed once as an MCP server works with any MCP-compatible client, replacing one custom integration per tool per agent.

Key takeaways

  • MCP standardizes discovery and calling, not decision-making — the model still decides which tool to call and with what arguments, the same way it does for any tool definition in its context.
  • Messages are JSON-RPC 2.0, exchanged over standard input/output for a local server process or HTTP with server-sent events for a remote one — MCP doesn't invent a new wire format.
  • A server exposes tools, resources and prompts; a client is the AI application that connects to one or more servers and surfaces what they offer to the model.
  • The problem it replaces is N agents × M tools worth of bespoke integration code — write a tool once as an MCP server, and any MCP client can use it.
  • MCP doesn't guarantee tool quality or safety — a badly described tool is just as confusing to a model over MCP as a badly described one defined inline, and a client still has to decide what it trusts enough to connect to.

The integration problem before a shared protocol

Before a shared protocol, giving an AI agent access to, say, a company's internal ticket system meant writing an integration specific to that one agent's tool-calling interface. A different agent runtime wanting the same access needed its own separate integration, even though the underlying operation — read a ticket, create a ticket — never changed. Multiply that by every tool an organization wants to expose and every agent runtime that might want to call it, and the integration surface grows as a product of the two numbers, not a sum.

What the protocol actually specifies

MCP defines a small, specific set of things: how a client discovers what a server offers (its tools, readable resources, and reusable prompts), how it calls a tool and receives a structured result, and how errors are reported — all expressed as JSON-RPC 2.0 requests and responses. The transport is one of a short, defined list: standard input/output when the server runs as a local subprocess, or HTTP with server-sent events when it's a remote service. None of this is novel wire-format engineering — JSON-RPC is decades old — which is part of the point: the protocol's job is agreement on shape, not invention of mechanism.

What MCP specifies vs. what it deliberately leaves to the client or server.
Concern Specified by MCP? Who actually decides
Message format for calling a toolYesJSON-RPC 2.0, defined by the spec
How a client discovers available toolsYesA defined discovery/listing exchange
Which tool the model chooses to callNoThe model, from the tool's name/description/schema
Whether a server is trustworthy to connect toNoThe client/user, same as installing any other software
What the tool actually does internallyNoWhoever wrote the server
MCP is not a security boundary by itself. Connecting to an MCP server grants it whatever access its tools expose, the same trust decision as installing any other piece of third-party software. The protocol standardizes the calling convention; it doesn't vouch for what's on the other end of the connection.

Server and client, concretely

An MCP server is a process — local or remote — that wraps something useful: a database, a file system, a SaaS API, a search index, and exposes a defined set of tools and resources through MCP's message format. An MCP client is the AI application — an IDE plugin, an agent runtime, this very kind of coding assistant — that connects to one or more servers, lists what they offer, and calls their tools on the model's behalf when the model decides to use one. The same server, written once, works with any client that speaks the protocol; that reuse is the entire value proposition.

Documented vs. inferred vs. unsupported

What's actually established about MCP.
Claim Status Basis
MCP uses JSON-RPC 2.0 as its message format Documented Directly stated in the published MCP specification
The model, not the protocol, decides which tool to call Documented Consistent with how tool-calling works generally in current LLM APIs — the protocol supplies definitions, not decisions
MCP will become the universal standard every AI tool adopts Unsupported A prediction about adoption, not a fact about the protocol's current mechanics — stated far more confidently elsewhere than the evidence for it warrants
MCP makes tool integrations inherently more secure Unsupported MCP standardizes the calling convention; it does not change the underlying trust decision of what a connected server is allowed to do
Curious how an agent decides what to read in the first place? The map-then-fetch pattern post covers the file-selection side of the same tool-calling picture.

Badri Dutta

Software engineer · 15 years building for the web

Fifteen years building for the web, now including day-to-day work with MCP-connected coding agents. This piece exists to separate the protocol's actual, specific job from the broader hype around it.

Full background →