# Pulumi MCP > Pulumi connects your AI agent directly to your cloud infrastructure state. It lets you list stacks, track deployment history, and audit resource outputs—all through conversation. Check stack status (`get_stack`), review deployed IPs or URLs (`get_stack_outputs`), and manage tags for cost-center filtering without ever opening the Pulumi console. ## Overview - **Category:** loved-by-devs - **Price:** Free - **Tags:** infrastructure-as-code, cloud-deployment, automation, stack-management, cloud-native, api-integration ## Description Your AI agent connects directly to your Pulumi infrastructure state, letting you manage cloud resources through natural language commands. You'll treat it like having a dedicated infra ops engineer sitting right next to you. **Stack Management and Organization.** You can list every isolated project environment in the organization using `list_stacks`, giving you an inventory of all your stacks along with their resource counts and last update times. When you need a fresh, clean sandbox for testing, use `create_stack` to spin up a new, dedicated stack within a specific Pulumi project. If that test stack is empty and you're done with it, remember to call `delete_stack`; this action permanently wipes the environment. **Metadata Control.**To keep your costs straight and know exactly where something belongs, you can use tags. You retrieve existing key-value labels on any specific stack using `list_stack_tags`. If you need to add or update a filter—say, marking it as `environment=staging` or `team=backend`—you run `set_stack_tag`. **Reading the State.** When you're unsure what state things are in, start with `get_organization`. This function pulls high-level metadata about your entire Pulumi organization. To check the specific setup of one environment, use `get_stack` to pull all the current configuration and details for a named stack. You can also confirm who initiated any change by calling `get_current_user`, which returns the GitHub identity used for every API call. **Auditing Deployments.** To track what's happened over time, you list everything using `list_deployments`. This shows you the full history of deployments for a stack, detailing the version number, whether it succeeded or failed, and exactly when those changes were made. To dive deep into one specific run, call `get_deployment` to get detailed status information for that single deployment version. **Inspecting Live Outputs.** After a successful deploy, you need to know where your stuff lives—the IPs, the URLs, the ARNs. You read all those exported values using `get_stack_outputs`. This tells you the live configuration data published by your infrastructure program after it successfully deployed. **Mechanics Summary.** When you're dealing with a specific stack, remember these tools: To get its current status and details, run `get_stack`. To see what was deployed in the past, check the list using `list_deployments` or focus on one version via `get_deployment`. If you need to filter resources by metadata, use `list_stack_tags` or update those filters with `set_stack_tag`. You'll never have to open a console just to get these facts. ## Tools ### create_stack Creates a new, isolated environment (stack) for your Pulumi program in the specified project. ### delete_stack Permanently removes an empty stack; this action cannot be undone. ### get_current_user Returns the GitHub identity used for API calls, confirming who initiated a change. ### get_deployment Retrieves detailed status information for one specific version of a deployment run. ### get_organization Fetches high-level metadata about an entire Pulumi organization. ### get_stack Gets the current configuration and details for a specific stack, confirming its existence and state. ### get_stack_outputs Reads all exported values (like IPs or URLs) that your infrastructure program published after deployment. ### list_deployments Lists the full history of deployments for a stack, showing status, changes, and timestamps. ### list_stack_tags Retrieves all key-value metadata labels currently applied to a specific stack. ### list_stacks Provides an inventory of every available stack in the organization, showing resource counts and last update times. ### set_stack_tag Adds or updates a custom key-value tag on a specific infrastructure stack for better filtering. ## Prompt Examples **Prompt:** ``` Show me all stacks in my organization. ``` **Response:** ``` I found 6 stacks in your organization: 'my-infra/dev' (last updated 2h ago, 24 resources), 'my-infra/staging' (last updated yesterday, 24 resources), 'my-infra/prod' (last updated 3 days ago, 24 resources), 'networking/prod' (last updated last week, 8 resources), 'database/dev' and 'database/prod' (both created but never updated). ``` **Prompt:** ``` What was the result of the latest deployment to my-infra/prod? ``` **Response:** ``` The latest deployment (v12) to my-infra/prod succeeded 3 days ago. It created 2 resources (new S3 bucket and CloudFront distribution), updated 1 resource (EC2 instance type changed) and left 21 unchanged. The deployment took 4 minutes and was triggered by user alice. ``` **Prompt:** ``` Show me the exported outputs from the prod stack. ``` **Response:** ``` The prod stack exports the following outputs: `api_url: https://api.example.com`, `cdn_url: https://cdn.example.com`, `db_endpoint: postgres://db.example.com:5432`, `s3_bucket_arn: arn:aws:s3:::my-prod-bucket` and `vpc_id: vpc-0abc123`. Would you like details on any of these? ``` ## Capabilities ### List all infrastructure stacks Retrieves a full inventory of your isolated project environments (dev, staging, prod) across the organization. ### Manage stack state and tags Creates new stacks or sets key-value metadata tags on existing stacks for filtering purposes. ### Track deployment history Lists all past deployments, showing the version number, status, resource changes (created/deleted), and who triggered them. ### Get specific stack details Retrieves detailed information about a single, specified Pulumi stack. ### Audit deployed output values Reads the exported configuration data (URLs, IPs) from the latest successful deployment of a stack. ## Use Cases ### Debugging a broken endpoint URL The frontend team reports that the service endpoint is wrong. Instead of asking the networking engineer to check the console, they ask their agent: 'Show me the latest `api_url` output for the prod stack.' The agent runs `get_stack_outputs` and returns the correct ARN instantly. ### Auditing cost center allocation The finance team needs to know which stacks belong to the 'Marketing' department. They use their agent: 'List all stacks tagged with `team=marketing`.' The tool runs `list_stack_tags`, providing a filtered, auditable list for billing. ### Verifying prerequisite environments A developer needs to know if the necessary 'database/staging' stack exists before running their code. They prompt: 'List all stacks in my organization.' The agent runs `list_stacks` and confirms its presence, allowing them to proceed safely. ### Rollback analysis A deployment failed last night. Instead of sifting through logs, the ops engineer asks: 'What changed in the last two deployments to my-infra/prod?' The agent runs `list_deployments`, summarizing resource changes and failure points. ## Benefits - Stop opening the Pulumi Console. Use `list_stacks` to get an immediate inventory of all environments in one prompt, saving minutes of navigation time. - Pinpoint exact resource changes after a failed rollout. Running `list_deployments` shows which resources were created or deleted in version v12—all without manually comparing logs. - Never guess a connection string again. Use `get_stack_outputs` to pull the latest API URLs, database endpoints, and ARNs directly into your chat window. - Accountability through tagging. Apply metadata tags using `set_stack_tag`. You can enforce that every new stack needs `environment=staging` before it's considered complete. - Audit permissions upfront. Call `get_current_user` first. This verifies the identity making the API calls, which is critical when setting up CI/CD agents. ## How It Works The bottom line is: you talk to your agent, and it performs the necessary multi-step sequence of reads and writes against your actual cloud state. 1. Subscribe to the server and provide your Pulumi Access Token. 2. Your AI client uses the token to authenticate against the Pulumi API. 3. The agent executes tools (e.g., `list_stacks`) based on natural language commands, returning structured infrastructure data. ## Frequently Asked Questions **How do I get a Pulumi Access Token?** Log in to the [**Pulumi Console**](https://app.pulumi.com), go to **Account Settings > Access Tokens**, click **Create Token**, give it a name and copy the token immediately — it starts with `pul_` and won't be shown again. **What is a Pulumi stack?** A stack is an isolated, independently configurable instance of your Pulumi program. Stacks typically represent different environments like dev, staging and prod. Each stack has its own configuration, state, outputs and deployment history. Use list_stacks to discover all stacks in an organization. **Can I see the deployment history of a stack?** Yes! Use `list_deployments` with the org name, project name and stack name. It returns the update history showing version number, status (succeeded, failed, in-progress), start/end time and resource change counts. Use `get_deployment` with a specific version for detailed logs and error messages. **Can I view the outputs of a stack?** Yes! Use `get_stack_outputs` with the org name, project name and stack name. It returns all exported output values from the latest successful deployment, such as URLs, IP addresses, resource IDs and connection strings. This is useful for discovering endpoint addresses after infrastructure deployment. **How do I use Pulumi to set or check tags on my stacks?** You manage organization and filtering using key-value pairs. You call `set_stack_tag` to add metadata like 'environment=prod' or 'cost-center=finance'. This helps your AI agent isolate specific infrastructure groups when you need to audit them. **What happens if I run the Pulumi delete_stack tool?** This action is irreversible, so be careful. The `delete_stack` tool permanently removes an entire isolated instance of your code. Always confirm you need to remove all associated resources before letting your agent proceed. **How can I use Pulumi to list all my infrastructure stacks?** Running `list_stacks` returns a full overview of every stack in the organization. You get details like the stack name, project, last update time, and resource count, which is great for quickly auditing your environment landscape. **How does Pulumi verify which user is running my operations?** You use `get_current_user` to get the authenticated identity details. This confirms the GitHub login, name, and email address tied to the access token. It's key for auditing who actually triggered a deployment or change.