Infracodebase 🤝 your IDE

We're super excited to ship the Infracodebase MCP server publicly today.

We've been using it internally for the last couple weeks, and it's fit seamlessly into our local developer setup. Working in Claude Code, the agent has our actual rulesets, coding guidelines, and CI compliance state in front of it before it writes a single line. Same in Cursor, Claude Desktop, and Windsurf.

From day 1 we knew we wanted to meet application developers where they are: in the IDE and increasingly in the terminal. (Looking at you, Claude Code.)

Now you can use it too.

Endpoint: https://infracodebase.com/api/mcp. Auth: personal access token from the Infracodebase web app. Install: one config block per client. Full install guide and snippets at github.com/onwardplatforms/infracodebase-mcp.

The Gap

In a regulated environment, generating IaC is the easy part. Getting IaC that matches your standards, your security team's constraints, and your platform team's patterns is the hard part.

A generic agent will happily generate a module. It will not know that every S3 bucket has to set block_public_access = true, that the security team has a ruleset banning 0.0.0.0/0 ingress, or that the last CI run flagged six rules on this file. It will write plausible code. CI will reject it. The loop repeats.

External frameworks are well understood. Internal standards are not. They encode how your business actually operates: risk tolerance, architectural decisions, real-world constraints. They are not on the internet, and an LLM cannot guess them.

That is the gap.

The usual answers are bad:

• Stuff guidelines into the system prompt. Doesn't scale past two rulesets, doesn't reflect changes, and burns tokens on rules that aren't relevant to the file being edited.
• Tell the developer to read the docs. The whole point of an agent is that they don't.
• Build a custom agent that does the IaC for you. Now you own a worse Cursor.

We picked a different shape.

The Shape

Infracodebase is an operating system for enterprise cloud: universal context, ubiquitous tooling, and an agent harness. The MCP server is the ubiquitous-tooling layer reaching into the IDE.

It is a governance data registry, not another agent. It exposes the metadata your existing agent needs to write code that will pass CI:

• The workspace identity for a given git remote
• The rulesets attached to that workspace, and whether each is required
• The full text of any ruleset, on demand
• The system prompt our CI compliance evaluator uses
• The findings from the last evaluation, filterable by rule

The split matters. Inference happens on the customer's machine, against the customer's code, in the customer's IDE. We don't run a hosted writer model. We don't see the file you're editing. The MCP surface is read-mostly and the canonical compliance gate is still CI.

In practice: the agent calls get_workspace_context to load active rulesets, fetches the required ones with get_ruleset_details, writes the IaC citing the rules that drove each decision, and calls list_compliance_findings before recommending a push. CI then re-runs the same evaluator the agent loaded over MCP. No drift between local reasoning and the gate.

Why MCP, Not an API

We have a REST API. We don't want every customer building a wrapper around it for each agent platform. MCP is the right substrate for three reasons:

1. Tool selection is the agent's job, not the prompt's. It picks the right tool for the moment. A static prompt can't.
2. It's already in the box. Claude Code, Claude Desktop, Cursor, Windsurf, and VS Code all speak MCP natively.
3. Streamable HTTP scales. Stdio over npx is fine for personal tooling. For an enterprise governance surface called by every developer in an org, we want a hosted HTTP endpoint with live authz.

Authorization

Tokens are user-scoped personal access tokens. Two scopes: read and execute. Authorization is live. The MCP server runs every call through the same RBAC engine the web app uses. Revoke a user's workspace access in the UI, the next MCP call fails. Nothing cached, no parallel permission system to drift.

The install path is: create a token in Settings, paste it into one JSON block in your client, done. OAuth Dynamic Client Registration is coming next, which will replace the PAT step.

Install

For Claude Code it's a single command:

claude mcp add --scope user --transport http infracodebase \
  https://infracodebase.com/api/mcp \
  --header "Authorization: Bearer $ICB_TOKEN"

Full snippets for Claude Desktop, Cursor, Windsurf, and a per-client rules-file template live in the public README. We also recommend committing a rules file (CLAUDE.md, .cursor/rules/infracodebase.mdc, or .windsurfrules) so the agent uses the MCP server on every relevant turn rather than only when it remembers to. The token-creation dialog in the web app generates one for you.

If you are running platform in financial services, healthcare, defense, or any regulated environment, and your team has been holding agents at arm's length from production because the output never quite matches your standards, pull a token and tell us where it falls down.

Compliance is not a topping. It is baked in. Wherever you work.