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.
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.
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.
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.
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.
get_infra_overview
is a compact, column-free snapshot meant for orientation — names and types, not detail.get_table_schema
fetches 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_summary
still 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.