MCP is like GraphQL: Governance matters more than the interface

The most valuable information in this article is placing MCP on the extension line of GraphQL, rather than treating it as a new protocol noun. This experimental design's control is necessary. Over the past month, I led students running AI agents, comparing baselines against standard function calling, REST tool descriptions, and retrieval-augmented generation. Initially, I thought MCP was just repackaging tool calls. After using it for a while, my view changed slightly: what it truly brings is pulling "what the model can call, how to call, and what returns after calling" out of the prompt, turning it into a governable interface layer.

This resembles GraphQL's history. GraphQL's core isn't query syntax, but schema. Hygraph's piece on "API of intent" stated it bluntly: the schema itself is documentation. For human developers, this saves effort; for models, it's almost giving them a map. Models don't need to guess fields from vague natural language but can generate queries around types, fields, and relationships. In knowledge graph experiments, we often encounter similar judgments: schema granularity determines the reasoning ceiling. Too coarse, and models have no grip; too fine, and maintenance costs explode.

However, GraphQL's lessons are there too. It was once expected to solve all problems with one endpoint, but many teams later found the real trouble wasn't how to write queries, but who has permission to query, which fields are queryable, the cost of a single query, and whether complex nesting drags down the backend. If MCP only learns GraphQL's flexibility but not its governance, problems will be more obvious. Because behind MCP isn't human frontends, but models. Models combine calls, hallucinate, and explain errors as reasonable paths.

I've recently looked at several arXiv papers on tool learning. Dataset bias needs consideration: task sets usually choose APIs with clear boundaries, clean fields, stable return values, and low failure costs. In real enterprise environments, tools often connect to databases, payments, CRMs, internal docs, and even can write files, send notifications, and change configs. This experimental design's control group can't just compare completion ability; it must also compare unauthorized call rates, duplicate call costs, and state consistency after interruptions. I wrote recently that AI agents' spending capability precedes their earning capability; this holds for MCP too. The more open the interface, the easier it is for models to make actions that look smart but are honest on the bill.

Schema is documentation, and also an attack surface

Methodologically, the place where MCP and GraphQL should merge most is introspection. Zuplo's piece says GraphQL APIs can be automatically converted to MCP servers, relying on schema introspection to generate tools. This idea is attractive, especially for enterprises with existing GraphQL. Lewis et al.'s RAG paper also reminds us that external knowledge integration isn't just throwing materials into context; index structure, evidence sources, and update frequency all change results. Tool interfaces are the same: if an MCP server just hard-translates REST interfaces into function lists, models are still guessing; if it exposes typed schemas, constraints, and examples, models at least have verifiable boundaries.

However, I don't agree with opening all capabilities to models. Apollo's piece says future MCP is GraphQL, meaning making each API a separate MCP server is too fragmented; better to aggregate with GraphQL. This judgment makes sense, but depends on the scenario. Before opening ecosystems, accounts must be settled. When guiding graduate student experiments, a simple principle is: fix variables first, then talk about generalization. MCP's generalization ability is strong, provided permissions, audits, costs, and rollbacks are fixed first. Otherwise, what you see isn't intelligence, but a pile of irreproducible side effects. Opening multiple agent sessions simultaneously causes machines to freeze easily; this phenomenon isn't just a compute issue, but uncontrolled state tracking.

So when this article says "that's fine," I think it's only half right. Being like GraphQL isn't the problem; the problem is whether it inherits GraphQL's governance framework. In the REST and OpenAPI era, interfaces constrained humans via documentation; in the MCP era, interfaces must constrain models via types, permissions, and evaluation. Baselines should compare under the same task: handwritten prompts, OpenAPI tool specs, GraphQL-to-MCP, RAG-only. Metrics must be layered: task success rate, token cost, error recovery time, permission violation counts. Comparing only whether requests can be sent is meaningless, just like in knowledge graphs, we can't compare only entity linking F1 without checking if downstream reasoning is biased by schema noise.

Looking forward, my judgment is that MCP won't directly become GraphQL, but within the next year or two, a governed MCP will emerge: generated from OpenAPI or GraphQL schemas, with default capability whitelists, call budgets, audit logs, and evaluation harnesses. Enterprises will first calculate costs, permissions, and reproducibility in small closed ecosystems, then gradually open links. The winning protocol won't necessarily be the most flexible, but the one most like a paper's appendix: checkable, reproducible, and locatable when problems occur.

---

📌 This article is compiled from Hacker News, original source: https://aien.me/mcp-is-the-graphql-of-ai-and-thats-fine/

Copyright belongs to the original author. This article is a compilation and independent analysis based on public reports.