Allows performing Pulumi operations such as previewing changes, deploying updates, retrieving stack outputs, and querying package resources using the Pulumi Automation API and Cloud API.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Pulumi MCP Server preview my Pulumi stack"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Note: This MCP server is currently under active development. Its API (including available commands and their arguments) is experimental and may introduce breaking changes without notice. Please file an issue on GitHub if you encounter bugs or need support for additional Pulumi commands.
A server implementing the Model Context Protocol (MCP) for interacting with Pulumi CLI using the Pulumi Automation API and Pulumi Cloud API.
This package allows MCP clients to perform Pulumi operations like retrieving package information, previewing changes, deploying updates, and retrieving stack outputs programmatically without needing the Pulumi CLI installed directly in the client environment.
The Pulumi CLI has to be installed on you machine.
This package is primarily intended to be integrated into applications that can use MCP servers as AI tools. For example, here is how you can include Pulumi MCP Server in Claude desktop's MCP configuration file:
{
"mcpServers": {
"pulumi": {
"command": "npx",
"args": ["@pulumi/mcp-server"]
}
}
}Related MCP server: Azure Platform Engineering MCP Server
The server exposes handlers for the following Pulumi operations, callable via MCP requests:
preview: Runs pulumi preview on a specified stack.
workDir (string, required): The working directory containing the Pulumi.yaml project file.
stackName (string, optional): The stack name to operate on (defaults to 'dev').
up: Runs pulumi up to deploy changes for a specified stack.
workDir (string, required): The working directory containing the Pulumi.yaml project file.
stackName (string, optional): The stack name to operate on (defaults to 'dev').
stack-output: Retrieves outputs from a specified stack after a successful deployment.
workDir (string, required): The working directory containing the Pulumi.yaml project file.
stackName (string, optional): The stack name to retrieve outputs from (defaults to 'dev').
outputName (string, optional): The specific stack output name to retrieve. If omitted, all outputs for the stack are returned.
getResource: Returns information about a specific Pulumi Registry resource, including its inputs and outputs.
provider (string, required): The cloud provider (e.g., 'aws', 'azure', 'gcp', 'random') or github.com/org/repo for Git-hosted components.
module (string, optional): The module to query (e.g., 's3', 'ec2', 'lambda').
resource (string, required): The resource type name (e.g., 'Bucket', 'Function', 'Instance').
listResources: Lists available resources within a Pulumi provider package, optionally filtered by module.
provider (string, required): The cloud provider (e.g., 'aws', 'azure', 'gcp', 'random') or github.com/org/repo for Git-hosted components.
module (string, optional): The module to filter by (e.g., 's3', 'ec2', 'lambda').
Clone the repository.
Install dependencies: npm install
Build the project: npm run build
This project is licensed under the Apache-2.0 License. See the LICENSE file for details.
| Name | Required | Description | Default |
|---|---|---|---|
| workDir | Yes | The working directory of the program. | |
| stackName | No | The associated stack name. Defaults to 'dev'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| workDir | Yes | The working directory of the program. | |
| stackName | No | The associated stack name. Defaults to 'dev'. | |
| outputName | No | The specific stack output name to retrieve. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| workDir | Yes | The working directory of the program. | |
| stackName | No | The associated stack name. Defaults to 'dev'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| module | No | The module to query (e.g., 's3', 'ec2', 'lambda'). Optional for smaller providers, will be 'index by default. | |
| provider | Yes | The cloud provider (e.g., 'aws', 'azure', 'gcp', 'random') or github.com/org/repo for Git-hosted components | |
| resource | Yes | The resource type to query (e.g., 'Bucket', 'Function', 'Instance') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| module | No | Optional module to filter by (e.g., 's3', 'ec2', 'lambda') | |
| provider | Yes | The cloud provider (e.g., 'aws', 'azure', 'gcp', 'random') or github.com/org/repo for Git-hosted components |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool names clearly distinguish registry operations (get/list resources) from CLI operations (preview, up, stack-output). Each name implies a distinct action, reducing ambiguity.
Naming style is inconsistent: 'getResource' and 'listResources' use camelCase, 'preview' and 'up' are lowercase single words, and 'stack-output' uses hyphen. No uniform verb_noun pattern.
With 5 tools, the set is well-scoped for a Pulumi MCP server covering registry and CLI basics. Each tool serves a distinct purpose without unnecessary duplication.
The tool set lacks essential Pulumi operations like stack create/destroy, config management, and resource update. The domain is only partially covered, leading to potential dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Provides capabilities that let LLM agents perform a range of infrastructure management tasks.
Plan Salesforce deploys, open pull requests and trigger pipelines from your AI client.
Query your team's drift, vulnerability, and upgrade data from any AI assistant. OAuth 2.1, 51 tools.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/VenelinMartinov/mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
