mine just is the gh cli. is the advantage of graphql that they can compose a query that would take multiple cli invocations?

CLI still has the possibility of being a little more token efficient, at worst it may use graphql behind the scenes.

For our company, we advertise the graphql schema to bots and they can one-shot whatever task they're trying to do. I've found that it's so good that I cancelled building an an MCP server and any skill. Just a well documented GQL schema. It's pretty remarkable.

> "I've found that it's so good that I cancelled building an an MCP server and any skill. Just a well documented GQL schema. It's pretty remarkable."

This gave me a chuckle, there's some subtle irony here- especially if the documentation of the GQL schema was work that needed to be done!

That's completely fair, I did spend a day or 2 having AI rewrite the field descriptions based on the code. for bots, by bots!

I think you might also have a GQL schema that's particularly well suited to what those bots need. Either that or your backend schema is relatively simple and the GQL schema covers all its possible data compositions.

Can you provide an example of this schema?

[flagged]

no the advantage of graphql is that the caller can limit the response to only the information that they need. in a REST API the caller has to filter out the extraneous information. using LLMs to do the filtering uses up context window

This is not fully true.

Most agents will use curl | jq to slice what they need (assuming a known API)

Yea- its just a matter of whether the work is delegated to the client or offered by the server. Making sure what is served is in a really quality schema is generally the most efficient path- ime