{"slug": "stop-sending-your-ai-assistant-40-tables-when-it-only-needs-3", "title": "Stop Sending Your AI Assistant 40 Tables When It Only Needs 3", "summary": "Infrawise has developed an MCP server that prevents AI coding assistants from wasting tokens on irrelevant database schema. The server exposes three key tools—get_infra_overview, get_table_schema, and get_graph_summary—that allow agents to request only the schema they need for a specific task, reducing context noise and improving response accuracy. This approach avoids the pitfalls of either providing no schema (leading to incorrect assumptions about production data) or dumping the entire schema (wasting tokens and distracting the model).", "body_md": "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`\n\n, `payments`\n\n, `inventory_reservations`\n\n. 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.\n\nMultiply 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`\n\ntable that has nothing to do with the bug you're fixing.\n\nInfrawise'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.\n\nWithout something like this, an AI coding assistant reading your codebase has two options, and both are wrong in a different direction.\n\n**Option one: no schema at all.** The model reads your source files, sees a `DocumentClient.scan()`\n\ncall, 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.\n\n**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.\n\nInfrawise'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.\n\nThe server exposes 21 tools, but three of them define the whole pattern.\n\n`get_infra_overview`\n\nis 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.\"\n\n`get_table_schema`\n\nis 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`\n\nmatches `public.orders`\n\nwithout 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`\n\ninstead of `orders`\n\n.\n\n`get_graph_summary`\n\nis 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`\n\nfor orientation, `get_table_schema`\n\nfor the two or three tables actually in scope, and `get_graph_summary`\n\nonly when the task is broad enough to need it — reviewing an entire service, tracing relationships across five different tables and functions at once.\n\nTake the checkout bug from the top. An agent working through it calls `get_infra_overview`\n\nonce 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`\n\n, sees a query joining on `payment_id`\n\n, and calls `get_table_schema`\n\nwith `[\"orders\", \"payments\"]`\n\n. Back comes exactly two schemas: column types, the foreign key from `orders.payment_id`\n\nto `payments.id`\n\n, and the indexes on both tables. That's the entire fetched context for the task — two tables, not forty.\n\nIf the bug turns out to touch `inventory_reservations`\n\ntoo, the agent just adds it to the next `get_table_schema`\n\ncall. 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.\n\nCompare 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`\n\neven reports a `freshness`\n\nfield with an age and a `stale`\n\nflag 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.\n\nThe 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.\n\nIt 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`\n\nonce per session for the table inventory, then `get_table_schema`\n\nonly for the tables the current query touches, and treat `get_graph_summary`\n\nas 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.\n\nNone of this requires the developer to think about it. You don't decide when to call `get_table_schema`\n\nversus `get_graph_summary`\n\n— 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.\n\n`get_infra_overview`\n\nis a compact, column-free snapshot meant for orientation — names and types, not detail.`get_table_schema`\n\nfetches 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`\n\nstill 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.", "url": "https://wpnews.pro/news/stop-sending-your-ai-assistant-40-tables-when-it-only-needs-3", "canonical_source": "https://dev.to/siddharth_pandey_27/stop-sending-your-ai-assistant-40-tables-when-it-only-needs-3-19b7", "published_at": "2026-07-07 08:35:15+00:00", "updated_at": "2026-07-07 08:58:14.037580+00:00", "lang": "en", "topics": ["developer-tools", "ai-agents", "large-language-models", "ai-infrastructure"], "entities": ["Infrawise", "Claude Code", "MCP"], "alternates": {"html": "https://wpnews.pro/news/stop-sending-your-ai-assistant-40-tables-when-it-only-needs-3", "markdown": "https://wpnews.pro/news/stop-sending-your-ai-assistant-40-tables-when-it-only-needs-3.md", "text": "https://wpnews.pro/news/stop-sending-your-ai-assistant-40-tables-when-it-only-needs-3.txt", "jsonld": "https://wpnews.pro/news/stop-sending-your-ai-assistant-40-tables-when-it-only-needs-3.jsonld"}}