An MCP server for verified infrastructure
Coding agents invent Terraform. They produce a module block with argument names that look plausible and do not exist, and you find out at init time - or worse, at apply time. The IaC Bazaar MCP server removes the guessing: it gives your agent a live, read-only view of 183 verified modules - each one statically validated, 117of them proven by a real apply → verify → destroy - together with their real input and output schemas.
Status - not published to npm yet
The server is built and lives in the IaC Bazaar repository, and the API it reads is public and live today. The package @iac-bazaar/mcp is not on the public npm registry yet, so the npx commands below do not resolve right now. They are the exact commands that work the moment it is published. Want it sooner? Get in touch.
The tools it exposes
Five tools, all read-only. The server never writes anything - not to your cloud, not to the catalog, not to your filesystem.
search_modulesSearch the catalog by free text, cloud, tool or price tier. Every match carries its verification status, so the agent can prefer a module that has actually been applied, verified and destroyed.
get_moduleOne module: verification proof, version, licence, price band - plus its exact input variables (name, type, required, sensitive, default), its outputs and a known-good example, when a token is configured and that account may read the module's contract.
list_providersEvery cloud/provider in the catalog with a module count.
list_stacksCurated reference-architecture stacks - sets of verified modules that compose into a production foundation, such as a landing zone or a Kubernetes platform.
get_stackOne stack: the ordered modules it comprises, how they wire together, and how many of them are live-tested.
Add it to Claude Code
claude mcp add iac-bazaar -- npx -y @iac-bazaar/mcp
# ...or with a registry token, so get_module returns input/output schemas:
claude mcp add iac-bazaar --env IAC_BAZAAR_TOKEN=iacb_... -- npx -y @iac-bazaar/mcpCursor, Windsurf, any MCP client
The server speaks MCP over stdio, so any client that can spawn a command works. Add it to your client's MCP config:
{
"mcpServers": {
"iac-bazaar": {
"command": "npx",
"args": ["-y", "@iac-bazaar/mcp"],
"env": { "IAC_BAZAAR_TOKEN": "iacb_..." }
}
}
}Drop the env block to run without a token - search, verification proof and pricing all still work; only the input/output schemas are withheld. Then ask your agent things like “search iac-bazaar for a verified AWS VPC module and show me its required inputs”, and it will call search_modules then get_module.
Configuration
IAC_BAZAAR_URLOverride the API base. Defaults to the public origin - you only need this to point the server at a different deployment.IAC_BAZAAR_TOKENOptional registry token (iacb_<40 hex>), minted at /account/tokens. Sent asAuthorization: Beareron the module-detail request - it is what unlocks a module's input/output contract. It is the same tokenterraformandtofuuse for the module registry, so one credential covers both.
What is public, and what is not
The catalog itself is public: searching it, and reading any module's verification proof, price and SHA-256 checksum, needs no credential. A module's declared input/output contract is the sellable part, so it follows the same ladder as the rest of the site:
- no token — no contract, for any module.
- token, no subscription — free-band contracts.
- builder — adds basic; team adds professional; enterprise — the whole ladder.
- owned modules — always readable, whatever their band.
When a contract is withheld, get_modulesays so explicitly and names what would unlock it. It never reports an empty input list - an agent that read “no inputs” would go right back to inventing them.
Under the hood
The server is a thin client over the public JSON API - /api/v1/modules, /api/v1/providers and /api/v1/stacks. Nothing the MCP server can see is anything you could not fetch with curl and the same token; it exists so an agent finds it without being told where to look.