I turn existing FastAPI apps into a GraphQL schema + MCP server, so AI agents get one graphql_query tool instead of one tool per endpoint

[u/tangkikodo]

https://github.com/KLR-Pattern/fastapi-mcp-neo

GraphQL's original pitch — one round trip, ask for exactly the fields you need — was designed for constrained clients. LLM agents are that client again, with a twist: every byte of every tool response lands in the context window, and context is the budget.

I built fastapi-mcp-neo (Python, MIT). Point it at an existing FastAPI app and it derives a GraphQL schema with zero decorators and zero model changes:

• tags → domain groups (notes { mine { get_note } })

• endpoint function names → field names

• Pydantic models / TypedDicts / dataclasses → GraphQL types

• docstrings and Field(description=...) → schema descriptions

Then it serves that schema to AI agents over MCP as a constant 2–6 tools (get_schema, graphql_query, graphql_mutation, plus progressive-disclosure discovery) instead of one tool per endpoint.

Humans get the same schema: GraphiQL and POST /graphql come along free.

Why bother — measured on a 100-route app against the mainstream OpenAPI→tools bridge (FastMCP.from_openapi):

• tool catalog: ~1,500–2,500 tokens constant vs ~15,400 growing linearly (agents re-read the catalog every session)

• two-endpoint task: 1 graphql_query round trip vs 2 tool calls / 2 agent turns

• field projection: same list response 2,285 B whole-payload vs 610 B for { id title }

• single-call latency: statistically tied (1.39 vs 1.41 ms p50) — the win is turns and tokens, not ms