Pulumi MCP Server

Infrastructure-as-code is one of the places where an LLM writing from memory goes wrong quietly — provider resource schemas change, and a plausible-looking property name simply fails at deploy time. The Pulumi MCP server addresses that by giving the assistant the registry itself, plus a live view of what is actually deployed in your Pulumi Cloud organisation.

Three groups of tools

Pulumi Cloud — get-stacks, resource-search, get-policy-violations and get-users let an agent answer questions about the estate you already run: which stacks exist, where a given resource lives, what policy is currently being violated, and who has access.

Registry and deployment — get-type, get-resource, get-function, list-resources, list-functions and deploy-to-aws let the agent look up real provider schemas while writing a program rather than guessing at them, and push a result to AWS.

Neo delegation — neo-bridge, neo-get-tasks, neo-continue-task and neo-reset-conversation hand a task to Pulumi Neo, Pulumi's own infrastructure agent, and then track or continue it from your assistant. This is the more unusual capability: rather than doing the work in-context, the MCP server becomes a bridge to a specialised agent that owns the change.

Setup

The current path is the remote HTTP server. In Cursor, add a pulumi entry to .cursor/mcp.json with "transport": "http" and the URL https://mcp.ai.pulumi.com/mcp. Claude Desktop and Kiro, which expect a local process, reach the same endpoint through npx mcp-remote. A local stdio implementation is also published on npm as @pulumi/mcp-server.

Who it is for

Platform and infrastructure teams already on Pulumi who want an assistant that writes against accurate provider schemas, can answer questions about the live estate, and can escalate a change to Neo rather than pretending to apply it.