API Evangelist Conversation with Jens Neuse on GraphQL Federation, Deterministic Joins, and Why MCP Has Very Little To Do With Agents Calling APIs

Hustling — just figuring it out, the same as you. We do GraphQL federation, and a lot of very big enterprises do federation: Mercedes, Rivian, eBay, many others. But the interesting part is actually not the federation part. It is what federation lets us access and see. From that vantage point, what we are currently observing is that there is a desire in a lot of companies to have agents talk to APIs, and it does not matter whether that is GraphQL or REST or anything else. If you dig deep enough into what it actually means when agents call APIs, it is a very, very complex problem — and MCP has very little to do with it. That is where WunderGraph is looking, long term. We do not have the wind at our back right now. It is hard. But we see an opportunity.

GraphQL is a query language. Instead of an API with many endpoints, you have a single endpoint and you send a query with a selection set — you are telling the server which fields you want from its graph. The reason that matters is not the endpoint count. It is the fragment. Say you are eBay with hundreds of UI components from different teams. A component defines a fragment saying “for a product, I need the URL and the rating.” Parents carry the child fragments and add their own, all the way to the root, where they compile into a single query. Compare that to REST: someone seven levels deep needs data, so fields get added at the root. Half a year later the product owner kills the use case, the UI is removed — and the REST API stays, because changing it would be breaking. Do that for months across large teams and you end up with a very complex REST API landscape. When people argue GraphQL versus REST about endpoints and POST, that is a complete misunderstanding of the problem.

With REST, good documentation and a schema are optional. You are allowed to have an OpenAPI spec and rules for how it is laid out — allowed. And REST is so under-specified that you can propagate inputs as a header, as a body, in the URL, as a parameter. How do you build a union? You can have discriminators in many different ways. GraphQL is very simple by comparison: here is a schema, we have types, inputs, enums, unions, interfaces, this is how you define them, a field can have arguments. As a large org with many teams, just agreeing on “let’s do GraphQL” is already a huge benefit — not because I am saying GraphQL is better than REST. Not at all. Honestly, I do not care. The real benefit is that we all agree on a standard for how we do things, how we do fields and arguments, and how we send queries.

Conway’s law means we are shipping our org chart. If two teams work autonomously it is simply easier for each to have its own service than to ship a monolith together, because they work at different cadences — and with ten teams it is harder still. So instead of a single GraphQL server you have multiple servers composed together through what the industry calls a router. The API consumer sees a monolith; the organization has microservices. Builders get the microservice benefits, users get the monolith ergonomics. Apollo Federation is now seven or ten years old. It is getting older, and it is in the trough of disillusionment — at least Gartner says so. But that means it is mature tech. It is ready to be adopted by enterprises.

Fifteen years in, what I have learned is that the people who are loudest in every wave are companies backed with a lot of VC money. After a while it settles down and we are back to reality. So it is about who has the biggest megaphone. There was a time when the GraphQL megaphone was the biggest. Before that, Postman had the biggest REST megaphone. Then GraphQL with Apollo — and we did not replace REST. Now we are all shouting MCP. What we actually see across our customer base is a toolbox: gRPC or REST microservices underneath, federation subgraphs on top, GraphQL for internal applications, REST with SDKs for partners and human consumers, MCP for agents. And Kafka. The mature enterprises are not thinking one versus the other. They are thinking: what is our problem, and we pick the solution.

The way MCP is structured, it assumes a model calls an MCP server and gets something back. If you want to do anything beyond one or two calls, you have to use inference to glue the calls together — and inference is slow, super expensive, and not really predictable. Say you want a report that reads from Linear and Confluence and other sources. Your model fills the context window, makes MCP calls, pulls data in, and then joins that data using inference. I simply feel like this is the wrong approach. Models are great at writing code. If you want to join data across different API calls, write a program and execute the program — and once it has run, then use inference to interpret the result. Cloudflare and others have started talking about code mode. Anything beyond about five MCP tool calls is not a long-term solution. It is architecturally wrong.

In federation we have the concept of an entity. Take a vehicle entity: the teams at Mercedes agree that every vehicle has an identifier, a UUID. One team builds a subgraph that gives you door data, another gives you window data, and they agree on that entity and key. We federate it together. Now an agent can build a query that says: give me the vehicle with window data and door data. All it needs to understand is how to build the query — it does not need to understand how to join car data. That is abstracted away. As an enterprise you can get a huge amount of value out of solving joins deterministically, where the organization agrees how data is joined and consumers do not have to figure it out at runtime. Otherwise you are relying on the LLM to make the right join at runtime. And top-tier models are not great at building complex queries against schemas they do not know, which is why we are building prompt-to-query tooling — so the model does not have to spend its own tokens and time on it.

Two patterns. First, we added MCP to the router early, without thinking about it much: you keep a folder of persisted GraphQL queries, we turn each query description into an MCP tool and compile the query variables into its JSON Schema. So if you have a GraphQL schema and a folder of queries, you have an MCP server — governed by the schema, type safe, well documented. The large majority of our customer base now has an MCP server in that style, and not because we pushed it. The business came and said “we need to build agents, make us an MCP server,” and they already had the graph. Authorization is the topic that keeps growing there — enterprises want very fine-grained authorization for specific operations, as in, is this agent allowed to perform this operation? Second, Cosmo Connect compiles a subgraph’s GraphQL schema into a protobuf definition, and we built a skill that implements the gRPC server. The router solves N+1 with batching, so user, posts and comments is three batched gRPC calls. Getting a GraphQL server right is hard for an agent; a gRPC server with a few functions is not. So you can hand Claude an OpenAPI spec and in about fifteen minutes your REST API is a subgraph.

I am excited to be in the API economy — I came to learn it pre-AI. I started at a very large news network in Germany with a heterogeneous set of thirty-plus APIs: an old Java CMS, things returning XML, GraphQL, gRPC, databases. We were building Alexa skills, iOS and Android apps and websites against that, and it was really tough. Building a REST API to enable mobile is where I learned about OpenAPI, and about thinking of an API as a product — designing it first rather than building it and seeing what happens. The thing that stuck with me, and that I am seeing again now: HTTP has always had a user agent header. I never thought much of it. Hypermedia described exactly this — an agent goes to a URL, downloads hypertext, follows the links. And now we have these agents, these programs, and it is just weird that we are doing Web MCP and not looking at the hypertext. But I am excited, because agents want to interact with the world, and I am pretty sure that goes through APIs again.