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.
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.
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.
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 --cursor
writes .cursor/mcp.json
and opens Cursor.infrawise start --vscode
writes into .vscode/mcp.json
and opens VS Code. This one infrawise start
with no flag writes .mcp.json
, prints the launch command for each editor, and exits — for any other MCP-capable editor, point it at infrawise 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.
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.
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
infrawise start --claude
is the entire setup: probe environment, generate infrawise.yaml
, analyze, write .mcp.json
, open Claude Code with 21 MCP tools.infrawise serve --stdio
from .mcp.json
on its own. No daemon, no port, no second command.get_infra_overview
.infrawise analyze
, and --rediscover
rebuilds config from scratch.--cursor
and --vscode
target other editors (the VS Code writer merges with existing MCP servers), and infrawise check --fail-on high
gates CI with the same analysis.