LocalStack MCP Server

Official

by localstack

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each 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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.6/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 2 community issues answered or closed in the last 6 months
- 12 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![localstack-mcp-server MCP server](https://glama.ai/mcp/servers/localstack/localstack-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/localstack/localstack-mcp-server)

Score Badge

Copy to your README.md:

[![localstack-mcp-server MCP server](https://glama.ai/mcp/servers/localstack/localstack-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/localstack/localstack-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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