Say your service has 40 tables. You ask Claude Code to fix a bug in checkout — a function that touches exactly three of them: orders, payments, inventory_reservations. If your MCP server hands the model your whole schema graph on every call just to answer that, you've spent a few thousand tokens of context on 37 tables nobody asked about, before the model has written a single line of code.
Multiply that by every tool call, every session, every developer on the team, and "just give it the schema" turns into a real line item — slower responses, a noisier context window, and a model more likely to get distracted by a campaigns table that has nothing to do with the bug you're fixing.
Infrawise's MCP tools are built around a specific answer to this: never send more schema than the task needs, and give the agent an explicit way to ask for exactly what it's missing.
The two bad defaults
Without something like this, an AI coding assistant reading your codebase has two options, and both are wrong in a different direction.
Option one: no schema at all. The model reads your source files, sees a DocumentClient.scan() call, and has no way to know that table has 50 million rows and a GSI it isn't using. It writes code that compiles and looks reasonable and is wrong the moment it touches production data — because "wrong" here isn't a syntax problem, it's a missing fact about your infrastructure that isn't in any file it can read.
Option two: dump everything, every time. Paste the full schema — every table, every column, every foreign key, every DynamoDB GSI — into the prompt so the model definitely has what it needs. This works, in the sense that the model now has the fact it's missing. It also means every single request pays for the full graph whether the task touches one table or fifteen. Context windows aren't free, and neither is the model's attention: the more irrelevant schema it has to read past, the more likely it latches onto the wrong table or a stale column name from a service you don't even own.
Infrawise's MCP server is designed around a third option: give the agent a cheap way to see what exists, then let it ask for detail only on the things it's actually going to touch.
How the lookup actually works
The server exposes 21 tools, but three of them define the whole pattern.
get_infra_overview is the entry point. It returns a compact snapshot — every table and collection by name and database type, queue and topic names, secret names, Lambda names, high-severity findings — no columns, no foreign keys, no indexes. It's meant to answer "what exists here" in a few hundred tokens, not "give me everything about it."
get_table_schema is where the actual detail lives, and it's scoped on purpose: it takes a list of 1 to 20 table or collection names and returns, per name, the columns with data types and nullability, primary keys, foreign keys (so an agent building a join knows the path without guessing), indexes, DynamoDB partition/sort keys, or a MongoDB estimated document count. Row data is never included — this is schema, not a data dump. Names are matched case-insensitively and by suffix, so asking for orders matches public.orders without the agent needing to know your schema prefix in advance. Ask for a table that doesn't exist and instead of a bare failure, you get up to five closest name matches back — useful when the agent guessed order instead of orders.
get_graph_summary is still there, and it still returns everything — every node, every edge, every finding, no filtering. It's the tool description that makes the intent explicit: it exists as the tool to reach for when you genuinely need the full picture across services, not the one an agent should reach for to answer "what does the orders table look like." The default path is get_infra_overview for orientation, get_table_schema for the two or three tables actually in scope, and get_graph_summary only when the task is broad enough to need it — reviewing an entire service, tracing relationships across five different tables and functions at once.
What this looks like on a real task
Take the checkout bug from the top. An agent working through it calls get_infra_overview once and learns there are 40 tables across Postgres and DynamoDB, plus a queue and a couple of Lambdas — cheap, one call, no column data yet. It's now looking at orders.ts, sees a query joining on payment_id, and calls get_table_schema with ["orders", "payments"]. Back comes exactly two schemas: column types, the foreign key from orders.payment_id to payments.id, and the indexes on both tables. That's the entire fetched context for the task — two tables, not forty.
If the bug turns out to touch inventory_reservations too, the agent just adds it to the next get_table_schema call. It never had to have asked for it upfront, and it never had to eat the cost of the other 37 tables it was never going to look at.
Compare that to the alternative most teams reach for without a tool like this: pasting the schema export once, keeping it in context, and hoping it doesn't drift as the schema changes. Infrawise's tables come from a fresh analysis (get_infra_overview even reports a freshness field with an age and a stale flag once the cached analysis passes 24 hours), so the agent knows when to ask for a re-run instead of working off of something that quietly went out of date three deploys ago.
Why this matters beyond the token count
The token savings are the visible part, but the more important effect is on accuracy. A model given forty tables' worth of columns has to do implicit filtering — figure out which of them are relevant, hold the rest as noise. Give it three tables that are actually in scope, and there's no filtering step: everything in context is something it's going to use. That's a smaller, sharper problem than "here's a schema, find what you need," and models are measurably better at smaller, sharper problems.
It also composes with what AGENTS.md calls out directly for large-database use cases — a text-to-SQL or query-writing agent should call get_infra_overview once per session for the table inventory, then get_table_schema only for the tables the current query touches, and treat get_graph_summary as the tool of last resort, not the default. That's the same pattern the checkout example walks through, just named as the recommended path for exactly the case where dumping everything hurts most — a database with hundreds of tables where "just paste the schema" was never realistic in the first place.
None of this requires the developer to think about it. You don't decide when to call get_table_schema versus get_graph_summary — the agent does, because the tool descriptions say when to reach for each one. The developer experience is just: ask Claude Code to fix the bug, and it already knows which two tables matter.
Key Takeaways
- Two bad defaults exist for schema context: give an AI assistant nothing (it guesses and gets it wrong) or give it everything (it pays for and gets distracted by tables it will never touch).
-
get_infra_overviewis a compact, column-free snapshot meant for orientation — names and types, not detail. -
get_table_schemafetches full column, key, and index detail for up to 20 named tables at a time, matched case-insensitively by short name, with fuzzy suggestions on a miss. -
get_graph_summarystill returns the full graph — it's the explicit escape hatch for cross-service work, not the tool an agent should reach for to answer a question about two tables. - The pattern scales down naturally to large databases: fetch the inventory once per session, then pull schemas only for the tables the current task actually touches.
Top comments (0)