Pulumi MCP Server Cursor IDE Setup 2026 (Stacks, Registry, Neo Delegation)

How do you connect Pulumi to Cursor? Add a pulumi entry to .cursor/mcp.json with "transport": "http" pointed at Pulumi's hosted Remote MCP Server, https://mcp.ai.pulumi.com/mcp — there's nothing to install locally. Restart Cursor, complete the OAuth prompt in your browser on first connect, pick which Pulumi Cloud organization to authorize, and confirm the green dot in Settings → Tools & Integrations → MCP Tools. From there the agent can query your actual Pulumi stacks, search resources across your cloud, and look up provider/registry docs without you leaving the editor.

This is Pulumi's own server, hosted and OAuth-authenticated by default — not a self-run binary you have to keep updated. That's a real difference from most infra-as-code MCP servers, which tend to be local processes wrapping a CLI. If your team already runs Terraform alongside Pulumi, or manages resources across AWS, Azure, and GCP, the value here is less "generate IaC from scratch" and more "let the agent look at what's actually deployed" — real stack state and policy violations, not just what's in a .ts or .py file.

Quick reference

Prerequisites

Step 1: Add the Remote MCP Server to Cursor

{
  "mcpServers": {
    "pulumi": {
      "transport": "http",
      "url": "https://mcp.ai.pulumi.com/mcp"
    }
  }
}

Save to .cursor/mcp.json (project-scoped) or ~/.cursor/mcp.json (global), then fully quit and reopen Cursor — MCP servers only load at startup, a restart alone via "reload window" isn't always enough to pick up a new entry.

Step 2: Complete OAuth and pick an organization

The first tool call (or the first time Cursor tries to initialize the connection) triggers a browser-based OAuth flow against your Pulumi Cloud account. Two things happen here that are easy to miss:

1. You authenticate as yourself, not as a service account — this server acts with your own Pulumi Cloud permissions, so if you can't see a stack in the Pulumi Cloud UI, the agent won't be able to either.
2. You choose which organization to authorize. If you're a member of more than one Pulumi Cloud org, pick deliberately — the agent will only see stacks and resources in the org you authorize during this step, not all of them.

If OAuth fails to redirect back into Cursor, it's almost always a browser popup/redirect block rather than a Pulumi-side problem — check that first before assuming the token or org is wrong.

Step 3: Alternative — token-based auth

If your environment doesn't support the interactive OAuth flow (headless CI, some remote dev setups), generate a personal access token at app.pulumi.com/account/tokens and use it in place of the browser flow where your client supports a token field. Treat this token like any other cloud credential — it carries your account's actual permissions, not a scoped-down read-only view.

Step 4: Claude Desktop and Claude Code (for comparison)

Cursor and Windsurf both speak HTTP transport natively, so the config in Step 1 is the whole setup. Claude Desktop doesn't support raw HTTP MCP servers yet, so it goes through a local bridge process instead:

{
  "mcpServers": {
    "pulumi": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://mcp.ai.pulumi.com/mcp"]
    }
  }
}

Claude Code uses a CLI command instead of a config file:

claude mcp add --transport http pulumi https://mcp.ai.pulumi.com/mcp

Cursor doesn't need either of these — the direct "transport": "http" block from Step 1 is sufficient, and skipping the mcp-remote bridge means one fewer local process to keep track of.

Step 5: Verify the connection

List my Pulumi stacks and tell me which ones have policy violations right now.

or, to exercise the registry lookup path instead of live stack state:

Look up the Pulumi AWS provider's aws.s3.Bucket resource and show me its required inputs.

A real answer with actual stack names or resource schema fields confirms OAuth and org selection went through correctly. An empty response to the first prompt despite stacks existing in the Pulumi Cloud UI usually means you authorized the wrong organization in Step 2.

What it exposes

The tool surface splits into three groups:

Pulumi Cloud — get-stacks lists stacks across the authorized org; resource-search searches and analyzes resources across all stacks using Lucene query syntax (this is the one to reach for instead of grepping through stack outputs manually); get-policy-violations surfaces policy pack failures; get-users returns org membership info.

Registry — get-type, get-resource, get-function, list-resources, and list-functions look up provider schema documentation directly, so the agent can answer "what inputs does aws.s3.Bucket take" without you switching to a browser tab.

Neo delegation — neo-task-launcher, neo-get-tasks, neo-continue-task, and neo-reset-conversation hand off longer-running infrastructure tasks to Pulumi Neo, Pulumi's own cloud-side agent, rather than having Cursor's agent try to carry the whole task itself. This matters for anything that's genuinely long-running or needs to survive past a single editor session.

There's also a narrower deployment tool, deploy-to-aws, scoped specifically to AWS deploys rather than a general-purpose apply across every cloud provider.

Everything under "Pulumi Cloud" and "Registry" is read/query — it reflects what's already deployed or what a provider schema says, not something the agent is creating on your behalf. deploy-to-aws and the Neo delegation tools are the ones that can actually cause something to happen; know which category a tool call falls into before approving it in an agentic loop.

Local alternative: @pulumi/mcp-server

If you don't want a Pulumi Cloud account in the loop at all — say, you just want an agent generating Pulumi IaC code locally against the Pulumi CLI rather than querying deployed state — Pulumi also publishes @pulumi/mcp-server on npm as a local, CLI-backed alternative. It requires the Pulumi CLI installed on the machine running it. This guide focuses on the hosted Remote MCP Server above since that's what most Cursor + Pulumi Cloud setups actually want; check the npm package page directly if the local-only path is what you're after.

Common mistakes

Authorizing the wrong organization during OAuth. If you're in multiple Pulumi Cloud orgs, this is the single most common cause of "the agent says I have no stacks" — it's not missing stacks, it's looking at the wrong org.

Assuming resource-search needs exact Lucene syntax memorized. Start with a broad, plain-language-ish query and narrow it once you see what comes back, rather than trying to write a precise Lucene query on the first attempt.

Expecting the registry tools to reflect your own custom providers. get-type/get-resource/get-function are built against published provider schemas — for anything genuinely custom and unpublished, the agent won't have registry data to look up.

Treating a personal access token as low-risk. It carries your actual Pulumi Cloud permissions. Anywhere you'd hesitate to paste a cloud provider credential, hesitate the same way here.

Troubleshooting

OAuth popup never completes. Check for a blocked redirect or popup blocker in your default browser before assuming the server itself is down.

Connected, but every stack query returns empty. Wrong organization authorized — repeat the OAuth flow and select the org that actually owns the stacks you expect to see.

Resource-search returns nothing for a query that should match. Start broader. A Lucene query that's too narrow on the first attempt is a much more common cause of empty results than a real server issue.

Nothing connects at all, timeout on every call. Confirm outbound HTTPS to pulumi.com domains isn't blocked by a corporate firewall or VPN split-tunnel — since this is a fully hosted server, network reachability is the first thing to rule out.

Claude Desktop config doesn't work with the same JSON as Cursor. Claude Desktop needs the mcp-remote bridge from Step 4 — it can't consume the direct "transport": "http" block Cursor uses.

Related guides

Frequently Asked Questions

Is there an official Pulumi MCP server? Yes — Pulumi runs a hosted Remote MCP Server at https://mcp.ai.pulumi.com/mcp, authenticated via OAuth against your Pulumi Cloud account. There's also a local, npm-distributed alternative, @pulumi/mcp-server, for CLI-backed IaC generation without a Cloud account.

Do I need to install anything locally to use it with Cursor? No. Cursor speaks HTTP transport natively, so pointing .cursor/mcp.json at the remote endpoint is the entire setup — no binary, no Docker image, no local process to keep updated.

Why does the agent say I have no Pulumi stacks when I know I do? You likely authorized the wrong Pulumi Cloud organization during the OAuth flow. The server only sees stacks in the org selected at connect time, and re-running the OAuth flow lets you pick a different one.

What's Pulumi Neo, and what do the neo-* tools do? Neo is Pulumi's own cloud-side agent. The neo-task-launcher, neo-get-tasks, neo-continue-task, and neo-reset-conversation tools delegate longer-running infrastructure tasks to it instead of having the editor's agent carry the entire task itself.

Can this server actually deploy or change infrastructure, or is it read-only? Most of it — stack listing, resource search, policy violations, registry lookups — is read-only. deploy-to-aws and the Neo delegation tools are the exceptions and can cause real changes, so treat those calls differently from the query tools when reviewing what an agent is about to do.

Official docs cited