# Using Atlas with Pulumi in 2026 > Pulumi's MCP server exposes the local Automation API and Pulumi Cloud to Atlas, so it can read stack outputs and iterate on pulumi preview until the plan is clean. Pulumi's MCP server exposes the local Automation API and Pulumi Cloud to Atlas, so it can read stack outputs, look up provider schemas, and iterate on pulumi preview until the plan is clean. Add it with atlas mcp add pulumi -- npx -y @pulumi/mcp-server@latest stdio, remembering the trailing stdio argument, then authenticate with pulumi login or PULUMI_ACCESS_TOKEN. ## What Pulumi's MCP server gives Atlas Pulumi's MCP server exposes the local Automation API and Pulumi Cloud to Atlas, which is two capabilities in one connection. In 2026 Atlas can read stack outputs, look up provider schemas, and iterate on pulumi preview until the plan is clean, all without leaving the terminal. Pulumi is infrastructure as code written in a real programming language, which means the agent writing it needs two kinds of knowledge. It needs the provider's resource schema, so the resource it declares actually has the properties it sets. And it needs the current state of the stack, so it knows what already exists. Pulumi's MCP server supplies both: provider schema lookups on one side, and the local Automation API plus the Pulumi Cloud API on the other. Atlas holds both at once, which is why the TypeScript it writes tends to preview cleanly. ## Adding Pulumi's MCP server to Atlas Add Pulumi's server with atlas mcp add pulumi -- npx -y @pulumi/mcp-server@latest stdio, and remember the trailing stdio argument. Leaving stdio off is the most common Pulumi setup mistake in 2026, because the package needs to be told which transport to speak before it will start. The command has a shape that trips people: @pulumi/mcp-server@latest is the package, and stdio is an argument the package itself requires. Omit it and the server does not come up, which surfaces to Atlas as a tool connection failure rather than a clear message about a missing argument. Once the server is registered, Atlas gains Pulumi's provider schema lookup and stack tools. Pulumi Cloud users have a shorter alternative available, described below, which skips the local process altogether. ## Authenticating Atlas to Pulumi Atlas has 2 ways to authenticate to Pulumi in 2026: run pulumi login, or set PULUMI_ACCESS_TOKEN. Pulumi's MCP server talks to both the local Automation API and the Pulumi Cloud API, so one credential covers both halves of what Atlas needs. pulumi login is the interactive path and it is what most developers already have on their machine. PULUMI_ACCESS_TOKEN is the non-interactive path, appropriate for CI or a machine where you do not want a browser handshake. Either satisfies the MCP server, because the server uses the same credential resolution as the Pulumi CLI itself. Atlas therefore has exactly the Pulumi access your own login has: it can read the stack outputs you can read, and it can preview against the stacks you can preview against. ## Skipping the local process with Pulumi Cloud Pulumi Cloud users can skip the local process entirely. Register the hosted endpoint with atlas mcp add pulumi --url https://mcp.ai.pulumi.com/mcp then run atlas mcp auth pulumi. That is a 2 command setup with no npx, no Node dependency, and no local server for Atlas to keep alive. The hosted route at https://mcp.ai.pulumi.com/mcp is the simplest way to connect Atlas to Pulumi if your stacks already live in Pulumi Cloud. atlas mcp add pulumi registers the URL and atlas mcp auth pulumi handles the authentication handshake. Choose the local @pulumi/mcp-server@latest stdio process instead when you need the local Automation API specifically, or when policy says the MCP process has to run inside your own boundary. Both give Atlas provider schemas and stack state, they differ in where the work happens. ## The daily workflow: stack outputs, schema, TypeScript, preview The Atlas and Pulumi loop in 2026 is four moves. Ask Atlas to read the stack outputs, look up the provider's resource schema, and add the resource in TypeScript. Then let Atlas run pulumi preview, read the plan diff, and iterate until nothing unexpected is being replaced. Reading the stack outputs first is what stops Atlas from writing a resource that duplicates one you already have. Looking up the provider's resource schema is what stops it from setting a property that does not exist. With both in hand, the TypeScript Atlas writes is grounded, and pulumi preview becomes the check rather than the discovery mechanism. The word to watch in the preview diff is replace. A resource being replaced rather than updated is how Pulumi tells you something is about to be destroyed and recreated, and Atlas should iterate until nothing unexpected is being replaced. ## Pin @pulumi/mcp-server in CI Pulumi marks the MCP API experimental, so pin @pulumi/mcp-server to a version in CI rather than tracking @latest. In 2026 an experimental API can change its tool surface between releases, and a pinned version is what keeps an Atlas pipeline reproducible from one run to the next. The @latest tag is fine on a developer machine, where a breaking change is an inconvenience you notice immediately. In CI it is a liability: a pipeline that passed yesterday fails today because the MCP server's tools moved, and nothing in your repository changed. Pulumi is explicit that the MCP API is experimental, which is a standing invitation to pin. Choose a version, pin @pulumi/mcp-server to it in the Atlas configuration your CI uses, and upgrade deliberately after you have seen the release notes. ## Setup 1. Add Pulumi's server, remembering the trailing stdio argument: atlas mcp add pulumi -- npx -y @pulumi/mcp-server@latest stdio 2. Authenticate with pulumi login, or set PULUMI_ACCESS_TOKEN, since the server talks to both the local Automation API and the Pulumi Cloud API. 3. Pulumi Cloud users can skip the local process entirely: atlas mcp add pulumi --url https://mcp.ai.pulumi.com/mcp then atlas mcp auth pulumi 4. Ask Atlas to read the stack outputs, look up the provider's resource schema, and add the resource in TypeScript. 5. Let Atlas run pulumi preview, read the plan diff, and iterate until nothing unexpected is being replaced. 6. Pin @pulumi/mcp-server to a version in CI, because Pulumi marks the MCP API experimental. ## FAQ ### how to connect atlas to pulumi mcp server Run atlas mcp add pulumi -- npx -y @pulumi/mcp-server@latest stdio. The trailing stdio argument is required, and omitting it is the most common setup mistake. ### pulumi mcp server not starting missing stdio argument The package needs the transport named explicitly. Use atlas mcp add pulumi -- npx -y @pulumi/mcp-server@latest stdio, with stdio as a trailing argument. ### how does the pulumi mcp server authenticate Authenticate with pulumi login, or set PULUMI_ACCESS_TOKEN. The server talks to both the local Automation API and the Pulumi Cloud API with that credential. ### is there a hosted pulumi mcp endpoint Yes. Pulumi Cloud users can skip the local process entirely: atlas mcp add pulumi --url https://mcp.ai.pulumi.com/mcp then atlas mcp auth pulumi. ### can atlas run pulumi preview and fix the plan Yes. Let Atlas run pulumi preview, read the plan diff, and iterate until nothing unexpected is being replaced. ### should i pin the pulumi mcp server version Yes in CI. Pulumi marks the MCP API experimental, so pin @pulumi/mcp-server to a version rather than tracking a moving tag. ### can atlas write pulumi resources in typescript Yes. Ask Atlas to read the stack outputs, look up the provider's resource schema, and add the resource in TypeScript. The schema lookup keeps the properties real. --- Canonical HTML: https://runatlas.sh/resources/integrations/pulumi Source of truth: aeo_pages row `/resources/integrations/pulumi` (segment: Integrations) (this file is generated from it, never hand-edited). Licence: Atlas is proprietary with a free core. It is not open source and there is no public source repository.