Our agentic builder has a single tool.

It is called graphql.

The agent writes a query and executes it. If the agent does not know how to do particular type of query then it can use graphql introspection. The agent only receives the minimal amount of data as per the graphql query saving valuable tokens.

It works better!

Not only we don't need to load 50+ tools (our entire SDK) but it also solves the N+1 problem when using traditional REST APIs. Also, you don't need to fall back to write code especially for query and mutations. But if you need to do that, the SDK is always available following graphql typed schema - which helps agents write better code!

While I was never a big fan of graphql before, considering the state of MCP, I strongly believe it is one of the best technologies for AI agents.

I wrote more about this here if you are interested: https://chatbotkit.com/reflections/why-graphql-beats-mcp-for...

Whoa there, you don't need to be so sadistic to your team. It's not GraphQL, but having a document describing how your API works, including types, that is important.

I expect you could achieve the same with a comprehensive OpenAPI specification. If you want something a bit stricter I guess SOAP would work too, LLMs love XML after all.

One of my agents is kinda like this too. The only operation is SPARQL query, and the only accessible state is the graph database.

Since most of the ontologies I'm using are public, I just have to namedrop them in prompt; no schemas and little structure introspection needed. At worst, it can just walk and dump triples to figure out structure; it's all RDF triples and URIs.

One nice property: using structured outputs, you can constrain outputs of certain queries to only generate valid RDF to avoid syntax errors. Probably can do similar stuff with GraphQL.

Isn't the challenge that introspecting graphql will lead to either a) a very long set of definitions consuming many tokens or b) many calls to drill into the introspection?

That is also the approach we took with Exograph (https://exograph.dev). Here is our reasoning (https://exograph.dev/blog/exograph-now-supports-mcp#comparin...). We found that LLMs do a very good job of crafting GraphQL queries for the given schema. While they do make mistakes, returning good descriptive error messages make is easy for them fix queries.

This is actually a really good use of graphql!

IMO the biggest pain points of graphql are authorization/rate limiting, caching, and mutations... But for selective context loading none of those matter actually. Pretty cool!

1000%

2 years ago I gave a talk on Vector DB's and LLM use.

https://www.youtube.com/watch?v=U_g06VqdKUc

TLDR but it shows how you could teach an LLM your GraphQL query language to let it selectively load context into what were very small context windows at the time.

After that the MCP specification came out. Which from my vantage point is a poor and half implemented version of what GraphQL already is.

your use-case is NOT Everyones use-case..(working in depth across one codebase or api but instead sampling dozens of abilities across the web or with other systems) thats the thing

how is that going to work with my use case, do a web search, do a local api call, do a graphql search, do an integration with slack, do a message etc..

> It works better!

> I strongly believe it is one of the best technologies for AI agents

Do you have any quantitative evidence to support this?

Sincere question. I feel it would add some much needed credibility in a space where many folks are abusing the hype wave and low key shilling their products with vibes instead of rigor.

Can anyone recommend an open source GraphQL-based MCP/tool gateway?

Reading this was such an immediate "aha" for me. Of course we should be using GraphQL for this. Damn. Where was this comment three months ago!

GraphQL FTW

I do think that using graphql will solve a lot of problems for people but it's super surprising how many people absolutely hate it.