The LocalStack MCP Server is an experimental server that provides AI assistants with comprehensive tools to manage LocalStack containers and automate AWS development workflows locally.
Container Management: Start, stop, restart, and monitor LocalStack container status with built-in Pro authentication and custom environment variable injection
Infrastructure Deployment: Deploy or destroy CDK and Terraform projects to LocalStack with automatic project type detection, parameterized deployments, and configuration management
Log Analysis: Parse and analyze LocalStack logs for troubleshooting with summary reports, error detection, request analysis, and raw log output filtering by service and operation
IAM Policy Management: Configure IAM enforcement levels (enforced, soft, disabled), search for permission violations, and automatically generate IAM policies from detected access failures
Chaos Engineering: Inject, manage, and clear service faults and network latency effects for resilience testing with configurable targeting and probability settings
Cloud Pods Management: Save, load, delete, and reset LocalStack state snapshots for streamlined development workflows and testing scenarios
AWS CLI Integration: Execute AWS CLI commands directly against the LocalStack container using the awslocal wrapper with command sanitization and error detection
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., "@LocalStack MCP Server start the LocalStack container and show its status"
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.
Let an AI agent manage and interact with LocalStack on your machine.
The LocalStack MCP server is currently available as an experimental public preview. For questions, issues or feedback, please utilize theLocalStack Community slack or submit a GitHub Issue
LocalStack emulates the cloud on your local machine so software teams and AI agents can validate security, quality, and reliability faster and more safely than the cloud allows. This Model Context Protocol (MCP) server lets any MCP client (Cursor, Claude, VS Code, and more) start LocalStack, deploy infrastructure, and debug your local cloud in natural language.
Set up the server in your MCP client with the interactive wizard:
npx -y @localstack/localstack-mcp-server initThe wizard detects your installed clients, asks how you want to run the server, and writes the configuration for you. You need a LocalStack Auth Token; the wizard reads LOCALSTACK_AUTH_TOKEN from your environment or asks for it. For the full options, prerequisites, and manual setup, see Installation.
Related MCP server: AWS MCP Server
Once the server is configured, talk to LocalStack through your agent in natural language:
"Start LocalStack and deploy the Terraform project in ./infra, then tell me which resources came up."
"My Lambda calls are failing. Read the LocalStack logs, find the permission errors, and generate an IAM policy that fixes them."
"Inject 500ms of latency into DynamoDB and confirm my retry logic still works."
"Search the LocalStack docs for how to enable S3 event notifications and summarize the steps."
The server connects MCP-compatible apps directly to your local LocalStack environment and its emulated AWS services, so your assistant can operate the stack securely without custom scripts or manual setup.
This server eliminates custom scripts and manual LocalStack management. Your agent can:
Start, stop, restart, and monitor LocalStack for AWS container status with built-in auth.
Deploy CDK, Terraform, and SAM projects with automatic configuration detection.
Search LocalStack documentation for guides, API references, and configuration details.
Parse logs, catch errors, and auto-generate IAM policies from violations.
Inject chaos faults and network effects into LocalStack to test system resilience.
Manage LocalStack state snapshots via Cloud Pods for development workflows.
Export, import, inspect, and reset LocalStack state locally with Export & Import State file-based workflows.
Install, remove, list, and discover LocalStack Extensions from the marketplace.
Launch and manage Ephemeral Instances for remote LocalStack testing workflows.
Replicate external AWS resources into LocalStack with AWS Replicator so IaC stacks can resolve shared dependencies locally.
Inspect LocalStack application flows with App Inspector traces, spans, events, payload metadata, and IAM policy evaluations.
Start repeatable LocalStack workflows from ready-made MCP prompts, including infrastructure validation and integration test generation.
This server provides your AI with dedicated tools for managing your LocalStack environment:
All tools in this MCP server requireLOCALSTACK_AUTH_TOKEN.
Tool Name | Description | Key Features |
Manages LocalStack runtime operations for AWS and Snowflake stacks | - Execute start, stop, restart, and status checks- Integrate LocalStack authentication tokens- Inject custom environment variables- Verify real-time status and perform health monitoring | |
Handles infrastructure deployment to LocalStack for AWS environments | - Automatically run CDK, Terraform, and SAM tooling to deploy infrastructure locally- Enable parameterized deployments with variable support- Process and present deployment results- Requires you to have | |
Analyzes LocalStack for AWS logs for troubleshooting and insights | - Offer multiple analysis options including summaries, errors, requests, and raw data- Filter by specific services and operations- Generate API call metrics and failure breakdowns- Group errors intelligently and identify patterns | |
Handles IAM policy management and violation remediation | - Set IAM enforcement levels including | |
Injects and manages chaos experiment faults for system resilience testing | - Inject, add, remove, and clear service fault rules- Configure network latency effects- Comprehensive fault targeting by service, region, and operation- Built-in workflow guidance for chaos experiments- Requires a valid LocalStack Auth Token | |
Manages remote LocalStack Cloud Pods for development workflows | - Save current state as a Cloud Pod- Load previously saved Cloud Pods instantly- Delete Cloud Pods from remote cloud-backed storage- Use this for managed remote state snapshots, not local export/import files- Requires a valid LocalStack Auth Token | |
Manages local file-based LocalStack state export/import workflows | - Export LocalStack state to a local file on disk through the LocalStack State REST API- Import LocalStack state from a local file- Inspect current LocalStack state as JSON metamodel data- Reset all state or only selected services- Supports service-level granularity for export, reset, and inspect- Use this for local disk workflows; use Cloud Pods for remote cloud-backed snapshots- Requires a valid LocalStack Auth Token | |
Installs, uninstalls, lists, and discovers LocalStack Extensions | - Manage installed extensions ( | |
Manages cloud-hosted LocalStack Ephemeral Instances | - Create temporary cloud-hosted LocalStack instances and get an endpoint URL- List available ephemeral instances, fetch logs, and delete instances- Supports lifetime, extension preload, Cloud Pod preload, and custom env vars on create- Requires a valid LocalStack Auth Token | |
Runs AWS CLI commands inside the LocalStack for AWS container | - Executes commands via | |
Replicates external AWS resources into a running LocalStack instance | - Start single-resource replication jobs with a resource type and identifier or ARN- Start batch replication jobs, such as SSM parameters under a path prefix- Poll job status by job ID and list existing jobs- List resource types supported by the running Replicator extension- Reads source AWS credentials from the MCP server environment and supports optional target account or region overrides | |
Inspects LocalStack application traces, spans, events, and IAM evaluations | - Enable or disable App Inspector for the running LocalStack instance- List and inspect traces to understand AWS service-to-service flows- Drill into spans, events, payload metadata, and IAM policy evaluation events- Filter by service, region, operation, resource, ARN, status, and time range- Requires a valid LocalStack Auth Token and the App Inspector feature in the connected LocalStack license | |
Searches LocalStack documentation through CrawlChat | - Queries LocalStack docs through a public CrawlChat collection- Returns focused snippets with source links only- Helps answer coverage, configuration, and setup questions without requiring LocalStack runtime | |
Runs SQL against the LocalStack Snowflake emulator through the | - Execute SELECT, DDL (CREATE/DROP), DML (INSERT/UPDATE/DELETE), and SHOW/DESCRIBE statements from a query string or a |
Prompts are user-selected workflow templates exposed by MCP clients as slash commands or quick actions. They frame multi-step LocalStack tasks so the assistant follows the same phases, evidence requirements, and reporting format every time.
Prompt Name | Description | Arguments |
| Deploys an IaC project to LocalStack, validates declared resources with live AWS probes and App Inspector evidence, then writes and runs deterministic integration tests. |
|
The fastest way to install the MCP server is the interactive setup wizard:
npx -y @localstack/localstack-mcp-server initThe wizard:
lets you choose how to run the server (npx on your machine, or the self-contained Docker image),
checks the prerequisites (Node.js, Docker) and tells you how to fix anything missing,
picks up your LOCALSTACK_AUTH_TOKEN from the environment, or asks for it,
lets you pass extra LocalStack config (e.g. DEBUG=1,PERSISTENCE=1),
detects your installed MCP clients (Cursor, Antigravity, Claude Code, Claude Desktop, VS Code, Codex, OpenCode, Amazon Q CLI) and writes the right configuration for each one you select.
It can also run fully non-interactively, e.g. in dotfiles or scripts:
npx -y @localstack/localstack-mcp-server init --method npx --client cursor,claude-code --yesTo remove the server from your clients again:
npx -y @localstack/localstack-mcp-server removeRun npx -y @localstack/localstack-mcp-server init --help for all options.
Docker installed and running. The MCP server manages the LocalStack container directly through the Docker API.
cdklocal, tflocal, or samlocal installed in your system path if you want to deploy CDK, Terraform, or SAM projects
Snowflake CLI (snow) installed in your system path if you want to use the Snowflake tool
A valid LocalStack Auth Token configured as LOCALSTACK_AUTH_TOKEN (required for all MCP tools)
Node.js v20 or higher installed in your system path
Add the following to your MCP client's configuration file (e.g., ~/.cursor/mcp.json). This configuration uses npx to run the server, which will automatically download and install the package if needed. The server manages LocalStack through your Docker daemon; any deployment CLIs used by tools run from your host PATH.
{
"mcpServers": {
"localstack": {
"command": "npx",
"args": ["-y", "@localstack/localstack-mcp-server"],
"env": {
"LOCALSTACK_AUTH_TOKEN": "<YOUR_TOKEN>"
}
}
}
}All LocalStack MCP tools require LOCALSTACK_AUTH_TOKEN to be set. You can get your LocalStack Auth Token by following the official documentation.
If you installed from source, change command and args to point to your local build:
{
"mcpServers": {
"localstack": {
"command": "node",
"args": ["/path/to/your/localstack-mcp-server/dist/cli.js"],
"env": {
"LOCALSTACK_AUTH_TOKEN": "<YOUR_TOKEN>"
}
}
}
}The localstack/localstack-mcp-server Docker image bundles Terraform/tflocal, CDK/cdklocal, SAM/samlocal, and the Snowflake CLI. The only required host dependency is Docker. The container uses the mounted Docker socket to run LocalStack as a sibling container on the host; state lives in a named Docker volume (localstack-mcp) unless LOCALSTACK_VOLUME_DIR points at a host directory.
If you use the deployer tool with local Terraform, CDK, or SAM projects, bind-mount those project paths into the MCP container and pass the in-container path to the tool. The simplest convention is to mount projects at the same absolute path they use on the host.
{
"mcpServers": {
"localstack": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-v",
"/var/run/docker.sock:/var/run/docker.sock",
"--add-host",
"host.docker.internal:host-gateway",
"--add-host",
"s3.host.docker.internal:host-gateway",
"--add-host",
"snowflake.localhost.localstack.cloud:host-gateway",
"-e",
"LOCALSTACK_AUTH_TOKEN",
"-e",
"LOCALSTACK_HOSTNAME=host.docker.internal",
"-v",
"/Users/you/projects:/Users/you/projects",
"localstack/localstack-mcp-server:latest"
],
"env": { "LOCALSTACK_AUTH_TOKEN": "<YOUR_TOKEN>" }
}
}
}See docs/DOCKER.md for the run command, MCP client config, IaC project mounts, CDK notes, and troubleshooting.
Variable Name | Description | Default Value |
| The LocalStack Auth Token to use for the MCP server | None |
| The explicit LocalStack container name to use for Docker-based tools. When unset, the server auto-detects standard LocalStack containers such as | Auto-detect |
| Docker image the |
|
| Host directory mounted at | Per-OS cache dir |
| Override the gateway port bindings for |
|
| Docker daemon endpoint used for all container operations ( | Platform default socket |
| Host path of the Docker socket mounted into the LocalStack container (for Lambda). Validated to exist when set explicitly. |
|
| Inclusive host port range published for external services on |
|
| Disable MCP analytics when set to |
|
| Set to |
|
| Source AWS access key used by AWS Replicator to read external AWS resources | None |
| Source AWS secret access key used by AWS Replicator to read external AWS resources | None |
| Source AWS region used by AWS Replicator | None |
Since v0.6.0 the MCP server no longer uses (or requires) the localstack CLI. The LocalStack container is created directly through the Docker Engine API. Behavioral differences from CLI-driven starts:
~/.localstack/*.env config profiles and DOCKER_FLAGS are not read at start. Pass configuration through the envVars argument of the localstack-management start action, or set LOCALSTACK_-prefixed variables in the MCP server's environment (LocalStack aliases LOCALSTACK_<NAME> to <NAME> natively).
Besides LOCALSTACK_*/PROVIDER_OVERRIDE_*, only a curated set of common unprefixed config variables is forwarded from the host environment (DEBUG, LS_LOG, SERVICES, PERSISTENCE, EAGER_SERVICE_LOADING, ENFORCE_IAM, IAM_SOFT_MODE, EXTENSION_AUTO_INSTALL, APP_INSPECTOR, DNS_ADDRESS, MAIN_DOCKER_NETWORK, and the LAMBDA_*/CFN_*/SNOWFLAKE_*/SF_* families).
Port 443 is published by default. If something else uses port 443 locally, set GATEWAY_LISTEN=:4566 to skip it.
If you previously used lstk, note the container the server creates is named localstack-main (externally started localstack-aws containers are still detected and managed; restart preserves their name, image, and volume).
For AWS Replicator-specific source credentials, you can use the AWS_REPLICATOR_SOURCE_ prefixed variants instead of the unprefixed variants. Do not mix the prefixed and unprefixed source credential groups; when any AWS_REPLICATOR_SOURCE_ variable is set, the Replicator tool reads the source configuration only from that group.
Built on the XMCP framework, you can add new tools by adding a new file to the src/tools directory and documenting it in the manifest.json file.
Pull requests are welcomed on GitHub! To get started:
Install Git and Node.js
Clone the repository
Install dependencies with yarn
Build with yarn build
This repository includes MCP Server Tester for tool validation in direct mode and LLM host mode.
Run direct MCP tests (deterministic):
yarn test:mcp:directRun Gemini-based MCP host evals:
export GOOGLE_GENERATIVE_AI_API_KEY="<your-gemini-key>"
export LOCALSTACK_AUTH_TOKEN="<your-localstack-auth-token>"
yarn test:mcp:evalsOpen the latest MCP Server Tester HTML report:
npx mcp-server-tester openRun both:
yarn test:mcpNotes:
MCP tests target the lifecycle-aware local server command node dist/cli.js by default.
LOCALSTACK_AUTH_TOKEN is required for all MCP tool usage and test suites.
You can override the target command with:
MCP_TEST_COMMAND
MCP_TEST_ARGS (space-separated arguments)
Executes an AWS CLI command against the running LocalStack container using the 'awslocal' wrapper.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | The AWS CLI command to execute (e.g., 's3 ls', 'dynamodb list-tables'). Do not include 'awslocal' or 'aws'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful context beyond annotations (e.g., it runs against a LocalStack container using 'awslocal'), but annotations are minimal (only a title), so the description carries more burden. It does not disclose behavioral traits like error handling, rate limits, or authentication needs, which are relevant for a command execution tool.
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?
The description is a single, efficient sentence that is front-loaded with the core purpose and includes essential details (e.g., 'awslocal' wrapper) without any wasted words, making it highly concise and well-structured.
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?
Given the tool's complexity (executing arbitrary AWS CLI commands), lack of output schema, and minimal annotations, the description is adequate but incomplete. It does not explain return values, error cases, or execution constraints, which are important for an agent to use it correctly in varied contexts.
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?
The schema description coverage is 100%, so the schema already documents the 'command' parameter thoroughly. The description adds minimal value by clarifying not to include 'awslocal' or 'aws' in the command, but this is a minor enhancement beyond the schema's details.
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?
The description clearly states the tool's purpose with specific verbs ('executes') and resources ('AWS CLI command against the running LocalStack container'), and it distinguishes itself from siblings by specifying the 'awslocal' wrapper, which is unique to this tool among the listed siblings.
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?
The description provides clear context on when to use this tool (for AWS CLI commands against LocalStack) and implicitly distinguishes it from alternatives by mentioning the 'awslocal' wrapper, but it does not explicitly state when not to use it or name specific alternative tools for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Injects, manages, and clears chaos faults and network effects in LocalStack to test system resilience.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | The specific chaos engineering action to perform. | |
| rules | No | An array of fault rules. Required for 'inject-faults', 'add-fault-rule', and 'remove-fault-rule' actions. | |
| latency_ms | No | Network latency in milliseconds. Required for the 'inject-latency' action. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true (mutation), readOnlyHint=false, and idempotentHint=false, but the description adds valuable context: it clarifies that the tool handles both 'chaos faults' and 'network effects' (e.g., latency), which helps the agent understand the scope beyond just faults. However, it doesn't detail rate limits, auth needs, or specific destructive outcomes like data loss.
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?
The description is a single, efficient sentence that front-loads key actions ('injects, manages, and clears') and the purpose ('to test system resilience'). Every word earns its place without redundancy or fluff, making it easy for an agent to parse quickly.
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?
Given the tool's complexity with 3 parameters, 100% schema coverage, and no output schema, the description is reasonably complete: it covers the tool's domain (chaos engineering) and key actions. However, it could improve by hinting at output behavior (e.g., what 'get-faults' returns) or error handling, as annotations only cover basic hints.
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?
Schema description coverage is 100%, so the schema fully documents parameters like 'action' with enum values and 'rules' with nested properties. The description adds no additional parameter semantics beyond implying chaos-related inputs, meeting the baseline of 3 since the schema does the heavy lifting.
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?
The description clearly states the tool's purpose with specific verbs ('injects, manages, and clears') and resources ('chaos faults and network effects in LocalStack'), plus the goal ('to test system resilience'). It distinguishes itself from sibling tools like logs-analysis or deployer by focusing on chaos engineering rather than deployment, logging, or client operations.
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?
The description implies usage for testing resilience in LocalStack, but it doesn't explicitly state when to use this tool versus alternatives like the 'localstack-aws-client' for normal operations or 'localstack-logs-analysis' for post-failure analysis. No exclusions or prerequisites are mentioned, leaving the agent to infer context from the chaos engineering domain.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manages LocalStack Cloud Pods with following actions: save, load, delete, reset
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | The Cloud Pods action to perform. | |
| pod_name | No | The name of the Cloud Pod. This is required for 'save', 'load', and 'delete' actions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations indicate destructiveHint=true, readOnlyHint=false, and idempotentHint=false, which already inform the agent that this tool can be destructive, is not read-only, and is not idempotent. The description adds minimal behavioral context by listing the actions, but it doesn't elaborate on what 'destructive' means (e.g., data loss from delete/reset) or mention any rate limits, authentication needs, or side effects. With annotations covering the safety profile, the description adds some value but not rich behavioral details.
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?
The description is extremely concise and front-loaded: a single sentence that directly states the tool's purpose and lists all actions. There's zero waste or redundancy, making it easy for an agent to parse quickly. Every word earns its place by conveying essential information efficiently.
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?
Given the tool's complexity (managing Cloud Pods with destructive actions), annotations provide safety hints, but there's no output schema. The description is minimal—it lists actions without explaining what they do, their outcomes, or prerequisites. For a tool with destructive potential and no output schema, more context on behavior and results would be helpful. It's adequate as a basic overview but has clear gaps in completeness.
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?
Schema description coverage is 100%, with clear descriptions for both parameters: action (enum of save, load, delete, reset) and pod_name (required for save, load, delete). The description doesn't add any meaning beyond what the schema provides—it merely lists the actions without explaining their semantics or how pod_name interacts with them. Given the high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
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?
The description clearly states the tool's purpose: 'Manages LocalStack Cloud Pods with following actions: save, load, delete, reset'. It specifies the resource (Cloud Pods) and the four specific actions available. However, it doesn't differentiate this tool from its siblings (like localstack-management or localstack-deployer), which might also manage LocalStack resources. The description is clear but lacks sibling differentiation.
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?
The description provides no guidance on when to use this tool versus alternatives. It lists the actions but doesn't explain the context for choosing save, load, delete, or reset, nor does it mention when to use this tool over sibling tools like localstack-management. There's no explicit when/when-not usage or alternative recommendations, leaving the agent without practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deploys or destroys AWS infrastructure on LocalStack using CDK or Terraform.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | The action to perform: 'deploy'/'destroy' for CDK/Terraform, or 'create-stack'/'delete-stack' for CloudFormation. | |
| projectType | No | The type of project. 'auto' (default) infers from files. Specify 'cdk' or 'terraform' to override. | auto |
| directory | No | The required path to the project directory containing your infrastructure-as-code files. | |
| variables | No | Key-value pairs for parameterization. Used for Terraform variables (-var) or CDK context (-c). | |
| stackName | No | The name of the CloudFormation stack. Required for 'create-stack' and 'delete-stack'. | |
| templatePath | No | The local file path to the CloudFormation template. Required for 'create-stack' if not discoverable from 'directory'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable context beyond annotations: it specifies that the tool works with CDK, Terraform, and CloudFormation, and mentions 'deploys or destroys' which aligns with the destructiveHint=true annotation. While annotations cover safety (destructive, non-idempotent, non-readonly), the description clarifies the scope (AWS infrastructure on LocalStack) and methods (CDK/Terraform), providing useful behavioral context without contradiction.
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?
The description is a single, efficient sentence that immediately communicates the core functionality. It's front-loaded with the essential action and context, with zero wasted words or redundant information. Every word earns its place in conveying the tool's purpose.
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?
Given the tool's complexity (6 parameters, destructive operations, multiple project types) and lack of output schema, the description provides basic context but could do more. It covers what the tool does but doesn't address potential side effects, error conditions, or what happens after deployment/destruction. The annotations help with safety context, but for a tool with destructiveHint=true, more behavioral guidance would be beneficial.
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?
With 100% schema description coverage, the input schema already documents all 6 parameters thoroughly. The description doesn't add any parameter-specific semantics beyond what's in the schema (e.g., it doesn't explain how 'variables' differ between CDK and Terraform implementations). The baseline score of 3 reflects adequate coverage through the schema alone.
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?
The description clearly states the tool's purpose: 'Deploys or destroys AWS infrastructure on LocalStack using CDK or Terraform.' It specifies the verb (deploy/destroy), resource (AWS infrastructure), and environment (LocalStack). However, it doesn't explicitly differentiate from sibling tools like 'localstack-aws-client' or 'localstack-management', which might also interact with LocalStack infrastructure.
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?
The description implies usage context (CDK/Terraform/CloudFormation projects on LocalStack) but doesn't provide explicit guidance on when to use this tool versus alternatives like 'localstack-aws-client' for direct AWS API calls or 'localstack-management' for administrative tasks. No when-not-to-use scenarios or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Configures LocalStack's IAM enforcement and analyzes logs to automatically generate missing IAM policies.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | The action to perform: 'set-mode' to configure enforcement, 'analyze-policies' to generate a policy from logs, or 'get-status' to check the current mode. | |
| mode | No | The enforcement mode to set. This is required only when the action is 'set-mode'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is not read-only, not idempotent, and not destructive, but the description adds context about what the tool does (configuring enforcement and analyzing logs). However, it doesn't disclose important behavioral traits like whether changes are persistent, what permissions are needed, or how the analysis works. With annotations covering basic safety, the description provides some value but lacks depth.
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?
The description is a single, efficient sentence that front-loads the core functionality. Every word earns its place without redundancy or fluff, making it easy to parse quickly.
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?
For a tool with 2 parameters, 100% schema coverage, and no output schema, the description is minimally adequate. It covers the high-level purpose but lacks details on usage context, behavioral nuances, or output expectations. Given the annotations provide basic safety info, it's complete enough to understand what the tool does but not how to use it effectively.
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?
Schema description coverage is 100%, with clear enum descriptions for both parameters. The description mentions 'configures LocalStack's IAM enforcement' and 'analyzes logs', which loosely map to the 'set-mode' and 'analyze-policies' actions, but adds no additional semantic details beyond what the schema provides. Baseline 3 is appropriate given high schema coverage.
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?
The description clearly states the tool's purpose: configuring IAM enforcement and analyzing logs to generate missing policies. It uses specific verbs ('configures', 'analyzes', 'generates') and identifies the resource (IAM policies). However, it doesn't explicitly differentiate from sibling tools like 'localstack-logs-analysis' or 'localstack-management', which might have overlapping functionality.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, appropriate contexts, or exclusions. Given the sibling tools include 'localstack-logs-analysis' and 'localstack-management', which might handle similar tasks, the lack of differentiation is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
LocalStack log analyzer that helps developers quickly diagnose issues and understand their LocalStack interactions
| Name | Required | Description | Default |
|---|---|---|---|
| analysisType | No | The analysis to perform: 'summary' (default), 'errors', 'requests', or 'logs' for raw output. | summary |
| lines | No | Number of recent log lines to fetch and analyze. | |
| service | No | Filter by AWS service (e.g., 's3', 'lambda'). Used with 'errors' and 'requests' modes. | |
| operation | No | Filter by a specific API operation (e.g., 'CreateBucket'). Requires 'service'. Used with 'requests' mode. | |
| filter | No | Raw keyword filter. Only used with 'logs' mode. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating safe, non-destructive operations. The description adds value by specifying it's for 'diagnosing issues' and 'understanding interactions,' which implies analysis and reporting rather than modification. However, it doesn't disclose additional behavioral traits like rate limits, authentication needs, or what 'analyze' entails (e.g., returns structured data vs. raw text). No contradiction with annotations exists.
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?
The description is a single, clear sentence that efficiently states the tool's purpose without redundancy. It's front-loaded with the core function ('LocalStack log analyzer') and avoids unnecessary details. However, it could be slightly more structured by hinting at key parameters or use cases, but overall it's appropriately sized and wastes no words.
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?
Given the tool's moderate complexity (5 parameters, no output schema) and rich annotations (readOnly, idempotent, non-destructive), the description is adequate but incomplete. It covers the high-level purpose but lacks details on output format, error handling, or integration with sibling tools. Without an output schema, the description should ideally hint at return values (e.g., 'provides analysis reports'), but it doesn't, leaving gaps for the agent.
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?
Schema description coverage is 100%, with each parameter well-documented in the input schema (e.g., analysisType with enum values, lines with default, service/operation/filter usage contexts). The description adds no parameter-specific information beyond what the schema provides. According to guidelines, with high schema coverage (>80%), the baseline score is 3, as the description doesn't need to compensate but also doesn't enhance parameter understanding.
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?
The description clearly states the tool's purpose: 'LocalStack log analyzer that helps developers quickly diagnose issues and understand their LocalStack interactions.' It specifies the verb 'analyze' and resource 'LocalStack logs' with the goal of diagnosis and understanding. However, it doesn't explicitly differentiate from sibling tools like 'localstack-management' or 'localstack-aws-client' which might also interact with logs or diagnostics.
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?
The description provides no guidance on when to use this tool versus alternatives. It mentions helping developers diagnose issues, but doesn't specify scenarios, prerequisites, or exclusions. For example, it doesn't clarify if this is for production debugging, testing, or how it differs from other tools like 'localstack-management' that might handle logs. This leaves the agent with minimal context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage LocalStack lifecycle: start, stop, restart, or check status
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | The LocalStack management action to perform | |
| envVars | No | Additional environment variables as key-value pairs (only for start action) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide basic hints (readOnlyHint=false, destructiveHint=false, idempotentHint=false), but the description adds useful context about lifecycle management actions. It doesn't contradict annotations and clarifies the tool's scope beyond what annotations alone convey, though it lacks details on side effects, permissions, or error handling.
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?
The description is a single, efficient sentence that front-loads the core purpose and lists all actions. Every word earns its place with no redundancy or fluff, making it highly concise and well-structured for quick understanding.
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?
Given the tool's moderate complexity (lifecycle management with 2 parameters), annotations cover basic behavioral hints, but there's no output schema. The description adequately explains what the tool does but lacks details on return values, error conditions, or integration with sibling tools, leaving some gaps for an agent to infer usage.
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?
With 100% schema description coverage, the schema fully documents the two parameters (action with enum values, envVars with constraints). The description doesn't add parameter-specific details beyond what's in the schema, so it meets the baseline of 3 without compensating with extra semantic information.
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?
The description clearly states the tool's purpose as managing LocalStack lifecycle with specific actions (start, stop, restart, status). It uses a clear verb ('manage') and identifies the resource ('LocalStack lifecycle'). However, it doesn't explicitly differentiate from sibling tools like localstack-deployer or localstack-aws-client, which might have overlapping functionality.
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?
The description implies usage context by listing the available actions, but doesn't provide explicit guidance on when to use this tool versus alternatives like localstack-deployer or localstack-aws-client. There's no mention of prerequisites, dependencies, or specific scenarios where this tool is preferred over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0localstack-deployer5 fields changedInput schema / properties / action / descriptionPrevious value: -"The deployment action to perform: 'deploy' to create/update resources, or 'destroy' to remove them."New value: +"The action to perform: 'deploy'/'destroy' for CDK/Terraform, or 'create-stack'/'delete-stack' for CloudFormation."Input schema / properties / action / enumPrevious value: -[
- "deploy",
- "destroy"
-]New value: +[
+ "deploy",
+ "destroy",
+ "create-stack",
+ "delete-stack"
+]Input schema / properties / stackNameAdded value: +{
+ "description": "The name of the CloudFormation stack. Required for 'create-stack' and 'delete-stack'.",
+ "type": "string"
+}Input schema / properties / templatePathAdded value: +{
+ "description": "The local file path to the CloudFormation template. Required for 'create-stack' if not discoverable from 'directory'.",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "action",
- "directory"
-]New value: +[
+ "action"
+]localstack-aws-clientlocalstack-chaos-injectorlocalstack-cloud-podslocalstack-deployerlocalstack-iam-policy-analyzerlocalstack-logs-analysislocalstack-managementEach tool has a clearly distinct purpose with no overlap: AWS client execution, chaos injection, cloud pods management, infrastructure deployment, IAM policy analysis, log analysis, and lifecycle management. The descriptions clearly differentiate their domains and functions, making misselection unlikely.
All tools follow a consistent 'localstack-' prefix with descriptive hyphenated suffixes (e.g., aws-client, chaos-injector). This uniform pattern makes the tool set predictable and easy to navigate, with no deviations in naming style.
With 7 tools, the server is well-scoped for managing LocalStack, covering key areas like execution, testing, deployment, security, diagnostics, and lifecycle. Each tool earns its place without feeling excessive or insufficient for the domain.
The tool set provides comprehensive coverage for LocalStack management, including core operations, resilience testing, and diagnostics. A minor gap exists in direct resource management (e.g., creating or querying specific AWS services), but agents can work around this using the AWS client tool.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
The AWS Knowledge MCP server is a fully managed remote Model Context Protocol server that provides real-time access to official AWS content in an LLM-compatible format. It offers structured access to AWS documentation, code samples, blog posts, What's New announcements, Well-Architected best practices, and regional availability information for AWS APIs and CloudFormation resources. Key capabilities include searching and reading documentation in markdown format, getting content recommendations, listing AWS regions, and checking regional availability for services and features.
MCP server for building and testing AI agents with multi-model experimentation and insights.
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/localstack/localstack-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
