# The Right Way to Start Claude Code on an AWS Project > Source: > Published: 2026-07-14 09:40:36+00:00 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.