Stephan Schmidt - May 29, 2026

GraphQL Comeback Because of AI?

Why AI agents might bring back an API style most teams already moved away from

I wrote about GraphQL in the past, but lost track of it for some time until Leif Hanack of feddi fame asked me about my opinion on GraphQL and AI.

I was startled. GraphQL is something I had put to rest, because I found it too slow, too complicated, and too easy to turn into a security problem. And while every programming language natively supports REST, you have to operate servers for GraphQL.

Not interested for the things I or my clients are doing.

When I was writing APIs in the past, there were two consumers I had in mind. One consumer of the AP was another service integrating against a known endpoint with hardcoded fields (think microservices). The other was a browser or mobile client (think SPA), written by a developer who could read the docs and didn’t mind getting a bit more data than they needed for that usecase (depending on the existing engineering culture). REST fits both cases and it is easy to understand and easy to get working (really easy - compared to get GraphQL working!).

What I came to in that discussion with Leif is that there is now a third consumer - which I realized in principle before but not it’s practical implications. AI agents, or tools for AIs to use, and the agent is not like the other two usecases and it differs in major ways.

The agent has a context window that costs real money per token. Reading documentation costs money and every extra field you return costs money. My usual way to save tokens is writing a small CLI client (a new way to integrate data into AI) that calls a REST endpoint, then transforms the answer into something like CSV, with command line flags to filter, limit fields and discover available data. Side note: the AI might be doing customer support in one call and billing cleanup in the next, so you end up with many API access tokens and many scopes to manage - which I also solved with CLI clients tied into a password manager that stores the tokens, so the AI never sees them.

REST is built around resources, GraphQL is built around fields, and for agents fields are the better building block to build on. Both for the data they pull and for the access they should have. And it gets stronger the more autonomous the agent becomes and the less hand holding you want to do as a human. Don’t want to describe in detail what the AI should do? Then you want everything discoverable by the AI.

But isn’t that MCP? MCP is a different interface to me:

Human or agent → MCP server or CLI → GraphQL → underlying services

MCP and GraphQL are not competing, because they are at different layers. MCP and CLI tools are for the agent to find tools and talk to them. You can put an MCP server in front of REST and that’s what most people do today. But then the MCP server has to invent, by hand, a typed schema and a way to shape the response per call. This is also where lots of “tools” come into play that reduce token costs, cutting and compressing noisy MCP/REST combinations that just dump all fields for discoverability.

All of that is what you get “for free” with GraphQL. An MCP server or CLI tool in front of a GraphQL backend can just pass queries through, instead of hardcoding which fields each tool returns in each request.

Or, again, just dumping all fields as REST based tools do today.

Which is the biggest complaint about REST: overfetching. You ask for /users/42, the server gives you a user object with forty fields, you wanted only two of those. Not only does it include 40 fields, but all orders, invoices and everything else, because that’s easier than making it discoverable for the AI. For a browser this is fine. Bandwidth is cheap, async keeps the app responsive, networks are fast (I still remember watching progressive JPGs load line by line on my 56k modem, today Spotify downloads megabytes in seconds over 5G), JSON parses fast on today’s CPUs, and nobody notices.

An AI agent is different though. Every byte the API returns ends up in the model’s context window, and the context window is the bottleneck for multi-step work. A user object with forty fields, when the agent only needs the email and the team id, is not only a waste of bandwidth but a waste in the reasoning sense. And one complaint I hear from everyone: AI is sooo slow. Those other thirty-eight fields stay in context for the rest of the conversation, costing money and time on every later call, and pushing out things the model could use instead. The dreaded 50% mark of context, where everything gets worse is approaching fast.

These problems add up. When an agent does ten or twenty tool calls, and every call drags in five times more data than needed, the window fills and the model gets worse at the work.

The N+1 problem, which everyone has stumbled over already with databases/SQL, makes things worse. You fetch a list of N items and then make one more request per item to load related data, turning what should be one query into N+1 round trips. It’s the footgun in ORMs and REST APIs, and for an agent each round trip has also a context-window cost. A normal REST workflow for an agent: GET /users to find someone, then GET /users/42/team to find their team, then GET /teams/7/members to see who’s on it. For that reason many REST APIs I have seen used for AI just drop all the fields and nested entities at once. In GraphQL this is a single query returning exactly what you asked for with no waste.

The second thing is schemas.

If you’re lucky, the REST contract is OpenAPI and it is up to date, because if it isn’t, “read the SDK source” is what the eager agent does instead: websearch, then read the source.

GraphQL solves that too, because it ships an introspectable, typed schema as part of the API itself. The agent can ask the server which types exist, what fields they have, what arguments they take, what’s deprecated. The schema is not separate documentation that some human has to keep in sync. The schema is the system describing itself. This helps the agent tremendously to make the right call, instead of experimenting around until it finds the data it needs.

Then there is: Security. I know everyone tags it on as an afterthought, and it was my main quarrel with GraphQL in the past: too difficult, and too easy to get wrong. GraphQL is not more secure than REST, but GraphQL security is more expressive. GraphQL has the concepts to express the kind of access control an agent needs, and REST mostly does not, at least not in a standard and granular way as in REST it’s orthogonal, mostly bolted on (one reason REST is easy, oh the tradeoffs!) .

REST often stops at resource-level scopes, calendar.read, repos.write, and there is no field-level option even if you wanted one. How often have I had to force feed security like CASBIN (an open-source authorization library for access control beyond simple roles, down to attribute- and field-level rules) into companies?

GraphQL is different. Resolvers run per field, so authorization runs per field, so you can write grants that actually match what an agent needs. This is harder to get right, because every field is a place where authorization can be wrong as a human. For agents the situation is very different, and hard but expressible beats easy but too simple - because today you create the GraphQL API with the right access control settings with an AI.

The next benefit for AI is short. GraphQL errors are typed, include the path in the query that failed, and have an extensions field for application-specific error data. REST gives you an HTTP status and whatever the API author decided to put in the body (hope they return JSON with a sub-error struct), which varies between providers and sometimes within the same provider.

“The field user.team.name failed because the requester has no read access on team 7” is something the agent can route on. “400 Bad Request, body is HTML” is something the agent has to parse with another LLM call, which costs more money and is unreliable.

What is more difficult? HTTP caching is basically free with REST and a real engineering project with GraphQL. CDNs understand REST natively and every HTTP library on every platform speaks REST without a special server. File uploads and streaming are straightforward over REST and awkward over GraphQL. Operationally REST is much simpler, e.g. no query cost analyzer to tune.

GraphQL did not take the API world by storm the way everyone expected, because of the downsides I mentioned at the beginning. AI is tabula rasa, the requirements now are very different and GraphQL might be just the protocol access layer AIs need. Lower token cost, schema introspection, discoverability, fine-grained auth, and structured errors.

Will GraphQL make a comeback, or even an universal breakthrough?

I’m much more positive on GraphQL than when I abbondend it. I think GraphQL is worth an experiment. There’s a good probability I’ll run one next.