The Right Way to Start Claude Code on an AWS Project

Infrawise, an open-source tool, simplifies adding MCP servers to AWS projects by collapsing the setup process into a single command. It statically analyzes codebases, AWS infrastructure, and database schemas, then exposes context to AI coding assistants via MCP, eliminating manual configuration and debugging. The tool caches analysis for 24 hours and watches for file changes to keep context fresh.

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 https://github.com/Sidd27/infrawise collapses the whole loop into one command. It's an open-source tool npm https://www.npmjs.com/package/infrawise 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 https://github.com/Sidd27/infrawise · npm https://www.npmjs.com/package/infrawise 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.