MCP Is the GraphQL of AI (and That's Fine)

Every few months a new acronym arrives and people talk about it like it changed everything. Right now that acronym is MCP, the Model Context Protocol. I want to make a simple argument: MCP is not a new idea. It is a new interface. And the closest thing we already have to it is GraphQL.

When you point a tool like GraphiQL at a GraphQL server, something nice happens. The tool asks the server, "What can you do?" and the server answers with its whole schema: every type, every field, every argument, and a short description for each one. This is called introspection. It is just a normal query, sent to the same endpoint, that returns metadata instead of data.

Because of introspection, a client does not need to read documentation before it starts. It can discover the API at runtime, build a request that matches the schema exactly, and know before sending it whether the request is valid.

MCP has the same trick, with different names. An MCP host (the AI app, like Claude or VS Code) opens a client for each MCP server. The first thing that client can do is send a server/discover

request. The server replies with the protocol versions it speaks, its identity, and its capabilities: whether it offers tools, resources, prompts, and whether it can send change notifications.

Then the client asks for the details. It sends tools/list

and gets back something like this:

{
  "name": "weather_current",
  "title": "Weather Information",
  "description": "Get current weather information for any location worldwide",
  "inputSchema": {
    "type": "object",
    "properties": {
      "location": { "type": "string", "description": "City name, address, or coordinates" },
      "units": { "type": "string", "enum": ["metric", "imperial", "kelvin"], "default": "metric" }
    },
    "required": ["location"]
  }
}

Look at that shape. A name. A description. A typed schema for the arguments. That is a GraphQL field definition wearing a JSON Schema coat. There are matching resources/list

and prompts/list

calls for the other two primitives, and a tools/call

to actually run something. Discover, then act. Same as GraphQL.

That last row is the only real difference, and it is the whole point of MCP.

The one real difference: who reads the description #

In GraphQL, the description on a field is a comment for a human developer. Nobody's code depends on it.

In MCP, the description is the product. The docs describe it as a "detailed explanation of what the tool does and when to use it." The AI host collects every tool from every connected server into one registry and hands the list to the model. The model reads the descriptions and decides, on its own, which tool to call and with what arguments. So MCP tool descriptions are written the way you would brief a new colleague: what this does, when to use it, what not to do with it.

That is a design choice about the audience, not a new kind of protocol.

Why I say "nothing new" #

Once you see the introspection pattern, the rest of MCP looks very familiar:

It runs on JSON-RPC 2.0. Not a new wire format. JSON-RPC has been around since 2010.It borrows from the Language Server Protocol. The spec says so directly. LSP is the thing that lets one language server work in every editor. MCP wants to let one tool server work in every AI app. Same idea, different ecosystem.Transports are the usual suspects. Either stdio for local processes, or HTTP POST with optional Server-Sent Events for remote servers, with bearer tokens, API keys, or OAuth for auth. Nothing you have not deployed before.Caching hints look like HTTP caching. Discovery and list responses carry attlMs

and acacheScope

. That isCache-Control

with a new spelling.Even routers are doing it. An IETF draft from Huawei proposes letting network switches and routers act as MCP servers. The tools are things likenetwork.cli.exec

andnetwork.yang.get

. In other words, MCP sits on top of CLI, NETCONF and YANG, which already existed, and simply describes them in a way an AI client can read. (Note: that draft is a work in progress, expired in April 2026, and was written against an older version of the spec, so treat it as a signal of direction rather than a standard.)

An MCP server is, in most cases, a thin wrapper that calls the REST or GraphQL API you already have. The business logic, the database, the auth: all of that stays where it was.

Now, I want to be fair, there are the parts that do not map cleanly onto GraphQL.

Elicitation goes the other way. An MCP server can a tool call and ask theusera question through the client, for example to confirm a dangerous action. GraphQL servers do not talk back to the human.Prompts and resources are first-class. GraphQL exposes fields. MCP also exposes reusable prompt templates and readable resources (files, records, schemas) as separate primitives with their own list calls.Discovery is required on the server side. GraphQL introspection is often switched off in production. In MCP, every server must implementserver/discover

, because without it the model has nothing to reason about. (Clients may skip it, but servers cannot.)Descriptions are treated as untrusted. Because the model acts on the description text, the spec says hosts should treat tool descriptions from unknown servers as untrusted, and should get user consent before any tool runs. GraphQL never needed a rule like that, because nobody executes a docstring.

None of these change my main point. They are details of the interface, added because the reader is a model instead of a developer.

So what? #

If you already understand how a GraphQL client learns a schema at runtime, you already understand MCP. Replace "developer reads the schema" with "model reads the tool list," and replace "query" with "tool call." The rest is transport, auth, and caching that you have seen before.

That is not a criticism. Good standards are usually boring. MCP's real contribution is not a new protocol. It is an agreement, across many AI apps, on how to describe existing software so a model can use it. Introspection for LLMs. That is enough.

Sources: the MCP intro, architecture overview and specification (2026-07-28), plus the IETF draft draft-zeng-mcp-network-mgmt-01.