There's a FastAPI post making the rounds about turning an API into an agent-friendly MCP service, and it names a problem anyone who has wired tools into an agent already feels in their bones. Two of them, actually. First, as your endpoint count climbs, every tool registration eats context before the agent has done anything useful. Second, a single list endpoint can return hundreds of KB or a few MB, and the moment that lands in the conversation your context budget is gone.
The author's fix borrows from GraphQL: treat each endpoint's return annotation as a node tree, expose a schema you can query for the full list of available methods, and let the caller pick only the fields it wants. The project claims 95%-plus test coverage and says it's early and iterating fast — I'll treat both as the author's statements rather than something I've verified. But the shape of the idea is sound, and it's worth separating from the MCP packaging it ships in.
Why context discipline is the real theme
If you read the rest of what builders are posting right now, the subtext is the same everywhere. People are rationing Claude usage so they don't burn an allowance, trading tips on not maxing out a plan, and building dashboards just to watch how many tokens a Gemini account has left before it resets. The common thread isn't model quality. It's that context and token budget have become the scarce resource, and anything that quietly inflates them is a tax you pay on every single call.
So the durable lesson from that FastAPI post isn't "adopt MCP." It's narrower and more portable: don't dump your whole catalog and your whole response into the agent. Let it ask what's available, then let it ask for exactly the fields it needs. That principle survives no matter what transport or framework you're on.
Rebuilding it as a hosted endpoint instead of a pile of tools
Here's the version I'd build on VicroCode, and it deliberately drops the heavy part. Instead of registering dozens of fat tools that each advertise themselves and each dump a large payload, you host one small Python backend and expose two routes.
The first route is `GET /schema`. It returns a compact list of callable methods with their argument shapes and the field tree each one can return. This is the "available methods" catalog, and the whole point is that it's small — names, types, nesting, nothing else. The agent reads this once to learn what it can do, which replaces the cost of registering many tools up front.
The second route is `POST /query`. It takes a method name, arguments, and a field selection — the GraphQL-style pick. The backend runs the real work, then prunes the response down to only the requested fields before it ever leaves the server. A 2 MB list becomes a few hundred bytes of exactly what was asked for. You can keep the batching idea too: accept an array of selections in one request so the agent calls three methods in a single round trip instead of three. On VicroCode you can run Python online for both routes and host them as a published API endpoint, which the in-platform agent then calls as a single tool.
Make the field map inspectable, not magic
The part I'd invest in is the field map, because that's where this kind of layer quietly rots. In the FastAPI original the schema is derived from return annotations. In a rebuild you'll often be stitching together your own data sources, so you want an explicit, editable record of which method exposes which fields, what type each is, and whether a field is safe to return at all.
A SQLite table is the honest home for that. One row per field: method name, field path, type, nullable, and an include/exclude flag so you can hide anything sensitive from the pickable set. Your `/query` route validates every requested field against this table before pruning, so a bad selection fails loudly instead of leaking an unexpected column. The nice side effect is that the whole contract becomes something you can open and read. When the agent picks a field that doesn't exist, you don't guess — you open the SQLite editor, look at the row, and fix the map. That beats re-deriving a schema in your head every time behavior drifts.
Where this stops being MCP, honestly
I want to be clear about the boundary, because it's easy to oversell. What I've described is not an MCP server. It's a plain hosted HTTP endpoint that an agent calls as one tool. On VicroCode that fits the confirmed path — Python execution, API endpoint hosting, in-platform tool calls, and a SQLite database behind it — and it's a good fit for AI agent development where the agent and the backend live in the same platform.
What it is not: a drop-in MCP transport for an external client like a desktop app that speaks the MCP protocol over stdio. That's outside the capabilities I'd map here, so if your requirement is genuine MCP interoperability with third-party hosts, this approach doesn't cover it, and I wouldn't pretend otherwise. You keep the two ideas that actually move the needle — schema-first discovery and field-level picking with batching — and you give up the MCP label.
I also won't claim a specific context saving. The direction is obviously favorable, since you're returning a slice instead of the whole payload, but any "we cut tokens by X%" number depends entirely on your data and your selections, so treat it as unverified until you measure it on your own endpoints.
The practical trade-offs
Two frictions are worth naming before you start. The field map is maintenance you now own; if your underlying data changes and the table doesn't, your schema lies to the agent. Build the validation step so a stale map produces a clear error rather than silent wrong data. And batching is lovely until one method in the batch fails — decide early whether a partial batch returns partial results with per-call errors, or fails the whole request, because the agent's retry behavior depends on that choice.
None of this is exotic. It's a small Python service, one SQLite table, and a discipline about what you let into context. The FastAPI post is right that the problem is real. You just don't need the whole MCP apparatus to steal the part that matters.