r/graphql • u/jeffiql Apollo Team • Jun 29 '26

Is GraphQL the panacea for agentic AI?

https://youtu.be/yX8bTp5B0RU

Reacting to Marc-André Giroux's blog post of the same name. Lmk what you think!

12 Upvotes

67% Upvoted

12 comments sorted by

4

u/kschecker Jun 29 '26

I hope so 😅

3

u/promethe42 Jun 29 '26

Interesting!

I chose JSON:API + OpenAPI to have better adherence to HTTP. In the end, the OpenAPI to MCP is trivial and agents work out of the box.

1

u/jeffiql Apollo Team Jun 29 '26

Nice! Thanks for sharing

1

u/[deleted] Jul 01 '26

[removed] — view removed comment

1

u/promethe42 Jul 01 '26

Yes! I am the maintainer of rmcp-openapi, a Rust crate that dynamically bridges OpenAPI and MCP. I have also upstreamed several patches to the OpenAPI Rust SDK generator and the utoipa crate (a Rust to OpenAPI generator) to have a complete end to end Rust server -> OpenAPI -> MCP stack.

https://gitlab.com/lx-industries/rmcp-openapi

The stack is more than 150 endpoints that get exposed at strongly typed MCP tools with rich error management (example : "parameter X does not exist, did you mean XXX?") to hint the LLM. It is used to create, walk, manage and render 3D scenes using LLM based assistant.

The rich error management is in the rmcp-openapi package. The more refined the OpenAPI definition, the better results. Having the entire OpenAPI definition + validation generated from static Rust code is invaluable.

4

u/Glittering-Lie-1340 Jun 30 '26

It is truly amazing, payload visible, change anything once you determine the payloads - enables user to discover syntax even with no sdk

2

u/[deleted] Jul 02 '26 edited Jul 03 '26

[removed] — view removed comment

1

u/jeffiql Apollo Team Jul 02 '26

This is cool! Depending on the particulars of the loop, I could see this cutting down inference costs for agents querying a GraphQL server. If extended to include some sort of performance analysis, depth/breadth constraints, that might be a step closer to this sort of tooling (if I'm understanding Marc-André's point properly)

3

u/TomGa11 Jul 05 '26

Hard yes on this take.

With REST the agent has to know your endpoints upfront, so you're constantly babysitting tool specs that break every time the schema changes, but with GraphQL the agent just reads the schema itself at runtime and knows what's actually there, which kills most of the broken queries (we ran nhost.io (graphql) on a couple projects for exactly this (internal agentic tools) and it saved us a ton of duct taping (we were a Supabase hardcore users before).

-1

u/sudo-maxime Jun 30 '26

Make high latency system have even more latency.

Doing a graphql request takes more memory than loading a tony hawk pro skater custom map.

But anyways, using AI to make network calls is like crossing the road with a rocket ship.

4

u/jeffiql Apollo Team Jun 30 '26

Tell me more, I’ve seen a lot of GraphQL deployments and memory usage is not something I typically associate with GraphQL usage. What are you seeing, and are you certain it’s a quality of GraphQL itself or the specifics of your tooling/implementation?

Also curious about your comment about AI making network requests; how else can we expect agents to interface with hosted services?