Best for
- Developers and operators who want AI assistance across the whole AWS containerization deployment flow
- Scenarios that need to quickly root-cause an ECS deployment issue
Maintained by the official AWS Labs team; the ALLOW_WRITE=false safe-by-default design is a real positive. It involves creating and deleting real cloud resources, so risk is higher than a typical local tool — all write-related tools are clearly listed here. This review is a static check of source and docs, not an actual deployment test.
An MCP server officially maintained by AWS Labs (the ECS sub-project within the awslabs/mcp monorepo), covering the full lifecycle from containerizing an app to ECS deployment and troubleshooting: containerization best-practice guidance, ECR image build/push, one-click ECS Express Mode deployment (auto-configured load balancer, auto-scaling, CloudFormation infrastructure), resource listing, and deployment diagnostics. AWS also offers a fully managed remote ECS MCP service; this entry covers the locally-runnable open-source implementation.
Recommended: uvx --from awslabs-ecs-mcp-server ecs-mcp-server (requires an AWS CLI profile with appropriate permissions configured beforehand). ALLOW_WRITE=false and ALLOW_SENSITIVE_DATA=false by default — a deliberate safe default requiring explicit opt-in for write access and sensitive data. AWS also offers a fully managed remote version; see docs.aws.amazon.com.
{
"mcpServers": {
"awslabs.ecs-mcp-server": {
"command": "uvx",
"args": ["--from", "awslabs-ecs-mcp-server", "ecs-mcp-server"],
"env": {
"AWS_PROFILE": "<your-aws-profile>",
"AWS_REGION": "<your-aws-region>",
"FASTMCP_LOG_LEVEL": "ERROR",
"ALLOW_WRITE": "false",
"ALLOW_SENSITIVE_DATA": "false"
}
}
}
}