You know the drill for adding an MCP server to a project: dig the exact command string out of the docs, hand-write a .mcp.json with an absolute path you'll typo once, restart the editor, and discover no tools showed up because the server expected a config file you haven't created yet. Plenty of MCP servers lose their would-be users somewhere inside that loop.
Infrawise collapses the whole loop into one command. It's an open-source tool (npm) that statically analyzes your codebase, AWS infrastructure, and database schemas, then exposes that context to AI coding assistants over MCP — so Claude Code knows your actual partition keys, GSIs, and indexes instead of guessing from source files. This post is about the part that usually kills tools like this before they deliver any value: setup.
Section 1: One command, four steps
npm install -g infrawise # or skip install and use npx
cd your-project
infrawise start --claude
start does four things, in order:
1. Probes your environment. If there's no infrawise.yaml in the project, it generates one. It reads AWS_PROFILE if set; otherwise it looks at your configured AWS profiles — one profile means zero questions, several means one prompt asking which to use. That's the entire interview. (If you want the full guided wizard instead, infrawise start --interactive runs it.)
2. Runs the analysis. It scans your AWS services, database schemas, and codebase, builds a graph of services, tables, indexes, and query patterns, and runs rule-based analyzers over it. No LLM is involved in this step — extraction and analysis are deterministic, so the same infrastructure always produces the same graph.
3. Writes .mcp.json to your project root. This is the file you'd otherwise write by hand:
{
"mcpServers": {
"infrawise": {
"command": "infrawise",
"args": [
"serve",
"--stdio",
"--config",
"/absolute/path/to/infrawise.yaml"
]
}
}
}
4. Opens Claude Code. Claude Code reads .mcp.json automatically and starts the session with all 21 infrawise tools available — schema lookups, per-function analysis, GSI suggestions, queue and topic details, the lot.
If the claude CLI isn't installed, start tells you exactly that and where to get it, instead of failing silently.
Section 2: Day two — you never type infrawise again
This is the part that matters more than the first run. .mcp.json doesn't point at a long-running server you have to remember to start. It tells the editor how to spawn one: every time you launch Claude Code in that project, the editor itself runs infrawise serve --stdio as a child process. There is no port to keep free, no background daemon to babysit, no "is the server running?" debugging session.
So the second-day workflow is:
claude
That's it. No infrawise command anywhere.
Two mechanisms keep the context from going stale underneath you:
A 24-hour analysis cache. The analysis from start is cached. When the editor spawns the server and the cache is fresh, the session begins instantly with the existing graph. Once the cache is older than 24 hours, the next session start refreshes it. The freshness is also visible to the assistant itself: get_infra_overview returns an analyzedAt timestamp, an ageSeconds value, and a stale flag, so Claude can tell you — or decide on its own — when the picture it has is old. (This came out of a reader question on an earlier post about deterministic analysis; it shipped as a proper feature.)
A file watcher inside the session. While the server is running, it watches the repository for file changes and re-runs code analysis on save. Write a new function that calls DynamoDB.scan() mid-session, and the code graph reflects it — you don't need to restart anything for the assistant to see what you just wrote.
Infrastructure changes are the one thing that won't propagate automatically mid-session — if you just added a table or changed a GSI in AWS, run infrawise analyze to force a full re-scan rather than waiting out the cache. And if the config itself has drifted from reality (new AWS account, different profile), infrawise start --rediscover deletes infrawise.yaml and the .infrawise/ cache directory and rebuilds both from scratch.
Section 3: Not a Claude Code shop? Same command, different flag
The --claude flag is one of three editor targets, and none of them changes what gets analyzed — only where the MCP config lands:
-
infrawise start --cursorwrites.cursor/mcp.jsonand opens Cursor. -
infrawise start --vscodewrites into.vscode/mcp.jsonand opens VS Code. This one merges rather than overwrites: if you already have other MCP servers registered in that file, they survive. Infrawise adds its own entry alongside them. -
infrawise startwith no flag writes.mcp.json, prints the launch command for each editor, and exits — for any other MCP-capable editor, point it atinfrawise serve --stdio --config /path/to/infrawise.yaml.
And for the teammates who don't use an AI editor at all, the same analysis runs as a CI gate:
infrawise check --fail-on high
check runs a fresh analysis and exits non-zero when any finding reaches the threshold severity (high is the default; medium and low tighten it). A full-table scan on a production DynamoDB table fails the build whether or not anyone on the team has ever opened Claude Code.
Section 4: What the assistant actually does with it
The payoff for the setup being this short is that the context is there before you need it. Without it, an AI assistant reading only your source files will happily suggest a .scan() on a table with 50 million rows, or recommend adding a GSI you already have. With the MCP tools connected, it can call get_table_schema for the exact columns and keys, analyze_function for a Lambda's real trigger event shape, or suggest_gsi for a ready-to-use index definition matched to your table's billing mode — before writing the query, not after you've reviewed it.
I've written about those analysis capabilities in earlier posts; the point of this one is narrower. A context tool only works if it's actually connected, and "actually connected" has to cost less than the problem it solves. Pasting a schema into a prompt costs thirty seconds, every session, forever. infrawise start --claude costs one command, once.
Conclusion
The gap between "this MCP server exists" and "this MCP server is running in my editor" is where most infrastructure context tools die. Infrawise's answer is to make the editor own the server lifecycle: one start command probes, analyzes, writes the editor config, and launches; from then on the editor spawns infrawise serve --stdio itself, a 24-hour cache keeps session starts instant, and a file watcher keeps the code graph current while you work.
Try it on a real project — the first start on an actual AWS account is where it gets interesting: GitHub · npm
Key Takeaways
-
infrawise start --claudeis the entire setup: probe environment, generateinfrawise.yaml, analyze, write.mcp.json, open Claude Code with 21 MCP tools. - After the first run, just launch your editor — it spawns
infrawise serve --stdiofrom.mcp.jsonon its own. No daemon, no port, no second command. - Analysis is cached for 24 hours and refreshed at session start when stale; the assistant can check freshness itself via
get_infra_overview. - File changes are picked up mid-session by a watcher; infrastructure changes need
infrawise analyze, and--rediscoverrebuilds config from scratch. -
--cursorand--vscodetarget other editors (the VS Code writer merges with existing MCP servers), andinfrawise check --fail-on highgates CI with the same analysis.
Top comments (0)