Which integrations are available for this server?

Allows investigation of AWS ECS deployment and runtime issues, collecting evidence from services, tasks, deployments, and service events, as well as target group health from ELBv2, to diagnose unhealthy services and correlate symptoms.

How do I use InfraLens MCP?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@InfraLens MCP why is orders-api-service unhealthy?" 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.

InfraLens MCP

by bharisagar

Overview Schema Source Related Servers Discussions Admin

Python

Remote

InfraLens MCP

InfraLens MCP is a read-only Model Context Protocol server and CLI for investigating AWS ECS deployment and runtime issues. The MVP focuses on AWS ECS Fargate services behind an Application Load Balancer.

The tool is designed to answer questions such as:

Why is the ECS service orders-api-service unhealthy?

InfraLens investigates the named service, collects evidence from AWS, correlates symptoms, and returns structured findings that explain what is failing, why it is likely failing, which evidence supports the finding, what to check next, and what remediation is recommended.

Status

The MVP implements ECS, ELBv2, CloudWatch Logs, limited IAM failure parsing, deterministic analyzers, investigation orchestration, MCP tools, CLI output, tests, Docker, pre-commit, and CI. All AWS collection paths are read-only and use dependency-injected boto3 clients.

Related MCP server: aws-ecs-mcp

Problem Statement

ECS incidents often involve overlapping signals from service events, stopped tasks, target-group health, health-check configuration, application logs, and downstream dependencies. A generic checklist is slow and can lead engineers to fix the wrong layer. InfraLens MCP produces evidence-backed findings for deployment failure, target-group configuration issues, network timeout, readiness endpoint failure, downstream dependency failure, container startup failure, and permission failure.

Architecture

flowchart LR
    User["Engineer or MCP client"] --> CLI["CLI"]
    User --> MCP["MCP server"]
    CLI --> Tools["Tool adapters"]
    MCP --> Tools
    Tools --> Service["Investigation service"]
    Service --> ECSCollector["ECS collector"]
    Service --> ELBCollector["ELBv2 collector"]
    Service --> LogsCollector["CloudWatch Logs collector"]
    Service --> IAMParser["IAM failure parser"]
    ECSCollector --> ECS["Amazon ECS read APIs"]
    ELBCollector --> ELB["ELBv2 read APIs"]
    LogsCollector --> Logs["CloudWatch Logs read APIs"]
    Service --> Evidence["Evidence service"]
    Evidence --> Analyzers["Deterministic analyzers"]
    Analyzers --> Findings["Evidence-backed findings"]
    Findings --> Result["InvestigationResult"]

AWS SDK calls live in collectors, not MCP tool handlers. Collection, analysis, orchestration, redaction, and presentation are separate layers.

Supported AWS Services

Amazon ECS clusters, services, deployments, service events, running tasks, stopped tasks, and task definitions
ELBv2 Application Load Balancers, listeners, listener rules, target groups, and target health
CloudWatch Logs with bounded lookback windows, keyword filtering, deduplication, grouping, and redaction
IAM-related access-denied metadata parsed from already-collected failure messages

Installation

python -m venv .venv
. .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install -e ".[dev]"

On PowerShell:

python -m venv .venv
.\.venv\Scripts\Activate.ps1
python -m pip install --upgrade pip
python -m pip install -e ".[dev]"

AWS Authentication

InfraLens MCP uses the standard boto3 credential chain:

AWS_PROFILE
Environment credentials
ECS task role
EC2 instance profile
Web identity or OIDC credentials

Configuration variables:

AWS_PROFILE
AWS_REGION
INFRALENS_LOG_LEVEL
INFRALENS_LOOKBACK_MINUTES
INFRALENS_MAX_LOG_EVENTS
INFRALENS_REDACT_ACCOUNT_IDS
INFRALENS_AWS_API_TIMEOUT_SECONDS

CLI Usage

Primary investigation example:

infralens investigate \
  --cluster demo-platform-cluster \
  --service orders-api-service \
  --region us-east-1

JSON output:

infralens investigate \
  --cluster demo-platform-cluster \
  --service orders-api-service \
  --region us-east-1 \
  --output json

Service events:

infralens service-events \
  --cluster demo-platform-cluster \
  --service orders-api-service \
  --region us-east-1

Target health:

infralens target-health \
  --target-group-arn arn:aws:elasticloadbalancing:us-east-1:111122223333:targetgroup/orders-api-target-group/abcdef1234567890 \
  --region us-east-1

Search logs:

infralens search-logs \
  --log-group /ecs/orders-api-service \
  --region us-east-1 \
  --lookback-minutes 30

InfraLens accepts any valid cluster, service, region, target-group ARN, task-definition ARN, and log-group name through CLI arguments or MCP tool inputs. The fictional resources above are examples only.

MCP Configuration Example

{
  "mcpServers": {
    "infralens": {
      "command": "infralens-mcp",
      "args": [],
      "env": {
        "AWS_REGION": "us-east-1",
        "INFRALENS_LOOKBACK_MINUTES": "30",
        "INFRALENS_MAX_LOG_EVENTS": "200"
      }
    }
  }
}

Available MCP tools:

investigate_ecs_service
inspect_ecs_service_events
inspect_task_definition
inspect_target_health
search_service_logs

Example Investigation

Primary finding:

The ECS target is unhealthy because the application readiness endpoint is not returning a successful response.

Supporting evidence:

The target group reports Target.Timeout.
The ECS task is running.
The container and target-group ports both use port 8080.
Application logs contain PostgreSQL authentication failures.
The readiness endpoint checks PostgreSQL connectivity and returns HTTP 503.

Probable root cause:

An application dependency failure rather than an ECS or target-group port configuration mismatch.

Recommended next steps:

Verify database connectivity using the task's runtime configuration.
Confirm that the task is receiving the expected database username.
Validate network access between the ECS task and database.
Separate liveness and readiness endpoints.

Security Model

InfraLens MCP is read-only. It does not restart ECS services, force deployments, update task definitions, change security groups, modify target groups, update IAM policies, retrieve secret values, or make AWS infrastructure changes.

Runtime output redacts AWS account IDs, passwords, tokens, authorization headers, database connection strings, secret values, and personal data where detected. InfraLens does not call Secrets Manager or SSM Parameter Store to retrieve secret values.

Required IAM Read-Only Permissions

A minimal starter IAM policy is available at docs/iam/read-only-policy.json. Production users should further restrict resources based on their environment.

Optional Demo Stack

An optional Terraform example is available at examples/demo-stack/. It can create a disposable ECS Fargate service behind an ALB for manual collector testing. InfraLens MCP does not apply this stack and remains read-only.

Development

python -m pip install -e ".[dev]"
python scripts/check_repository_hygiene.py
python -m ruff format --check .
python -m ruff check .
python -m mypy src
python -m pytest

Or run all checks:

make check

Testing

The test suite uses mocked AWS responses and botocore Stubber. It covers healthy services, port mismatches, target timeouts, HTTP 503 readiness failures with PostgreSQL evidence, 404 health paths, image-pull failures, resource initialization failures, essential container exits, access-denied parsing, Redis or Valkey failures, repeated rollback, no registered targets, redaction, partial results, and read-only operation contracts.

Roadmap

Broader ECS deployment metadata and deployment history correlation
Optional CloudWatch Metrics read-only summaries
More language-specific log analyzers
Richer MCP resources and prompts
Packaged releases for common MCP hosts

Contributing

Contributions should preserve the read-only safety model, include tests for new diagnosis rules, use fictional examples only, and avoid committing real infrastructure identifiers or secrets.

Available Tools

5 tools

inspect_ecs_service_eventsC

Inspect recent ECS service events.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`region`	Yes
`cluster`	Yes
`service`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description alone must convey behavioral traits. 'Inspect' implies a read-only operation but the description does not explicitly state safety, ordering, pagination, or the meaning of 'recent'.

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 single sentence is concise and front-loaded, containing no filler or redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 4 parameters (3 required) and no annotations, the description is too sparse. Even with an output schema, it omits parameter guidance and usage context, making it insufficient for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description provides zero parameter semantics; all four parameters ('cluster', 'service', 'region', 'limit') are left unexplained, leaving the agent to rely solely on property names. 0% schema description coverage means the description fails to compensate.

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 uses a specific verb ('Inspect') and identifies the exact resource ('recent ECS service events'), clearly distinguishing it from sibling tools like 'investigate_ecs_service' and 'inspect_task_definition'.

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?

No when-to-use guidance or alternatives are provided. It does not explain in which scenarios one would inspect events versus using 'search_service_logs' or 'investigate_ecs_service'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

inspect_target_healthC

Inspect target health for one target group.

ParametersJSON Schema

Name	Required	Description	Default
`region`	Yes
`target_group_arn`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description does not disclose whether the operation is read-only, requires specific AWS permissions, or what output is returned (though an output schema exists). The term 'Inspect' implies a safe read, but this is not explicitly stated, and side effects or rate limits are not addressed.

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, empty-free sentence that directly states the tool's purpose. It could be more informative, but it is appropriately brief for the simple tool.

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?

The tool is simple with two required parameters and an output schema, but the description lacks usage context and behavioral disclosure. Given no annotations and minimal description, it does not fully prepare an agent for when and how to invoke it, though the output schema covers return values.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description does not explain the parameters 'target_group_arn' and 'region'. With 0% schema description coverage, the description needed to compensate, but it only mentions the resource generally. The parameter names are self-explanatory, but no added context (e.g., ARN format or region default) is given.

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 identifies the action ('Inspect') and resource ('target health for one target group'). It distinguishes from sibling tools which focus on ECS services, events, task definitions, and logs, not target health.

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 the sibling inspection tools. It doesn't specify prerequisites (e.g., need a target group ARN) or typical scenarios (e.g., troubleshooting unhealthy instances). No alternatives or exclusions are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

inspect_task_definitionD

Inspect a task definition.

ParametersJSON Schema

Name	Required	Description	Default
`region`	Yes
`task_definition`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1.5/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose safety, side effects, and return behavior. It only says 'Inspect a task definition,' which is a restatement. There is no mention of read-only nature, data volume, or any other behavioral characteristic.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is only four words, which is extremely under-specified. While it is concise, it lacks any useful structure or front-loaded key information that would help an agent. It is a tautology rather than a meaningful description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Although there is an output schema, the description is incomplete for a task that has two required parameters and no annotations. The description fails to explain what the tool does beyond the name, and does not account for the need to specify region and task definition.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 2 parameters (region, task_definition) with zero description coverage. The description does not explain what these parameters mean, their format, or how they relate to the inspection. Since schema coverage is 0%, the description must compensate but does not.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Inspect a task definition' is essentially a tautology of the tool name. It provides no additional detail about what aspects of the task definition are inspected or what the output represents. It does not distinguish from sibling tools like inspect_ecs_service_events or inspect_target_health.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no mention of when to use this tool, what parameters are required, or how it differs from sibling tools like investigate_ecs_service or search_service_logs. The description provides no context for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

investigate_ecs_serviceD

Run a complete ECS service investigation.

ParametersJSON Schema

Name	Required	Description	Default
`region`	Yes
`cluster`	Yes
`service`	Yes
`include_logs`	No
`lookback_minutes`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1.8/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of disclosing behavioral traits. It merely says 'investigation' without revealing whether calls are read-only, what data is gathered, any side effects, or anything about the response size or structure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single short sentence with no wasted words, but it is under-specified to the point of being ineffective. It does not earn its place as a description because it provides minimal actionable information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 5 parameters, an output schema, and no annotations, the description is severely incomplete. It fails to explain what the investigation covers, the role of each parameter, or how the output is structured, making it inadequate for an agent to select and invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has zero description coverage for its 5 parameters, and the description does not compensate by explaining any of them. An agent gets no help in understanding what 'lookback_minutes' means or how 'include_logs' behaves.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Run a complete ECS service investigation' starts with a verb and names a resource, but 'investigation' is too generic to convey the specific scope. It hints at comprehensiveness but doesn't distinguish itself from sibling tools like inspect_ecs_service_events or search_service_logs beyond a vague 'complete'.

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?

No guidance is provided about when to use this tool versus the sibling tools. The description neither states appropriate contexts nor mentions alternatives, leaving the agent to guess.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_service_logsC

Search service logs in CloudWatch Logs.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`query`	No
`region`	Yes
`log_group`	Yes
`lookback_minutes`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It merely states that logs are searched, without revealing that it searches CloudWatch Logs with configurable lookback, query, or limit parameters, or any details about return behavior or access requirements.

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, concise sentence with no wasted words. It is appropriately front-loaded, though it sacrifices needed detail for brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has five parameters, no annotations, and only a one-sentence description, it is incomplete for effective use. The presence of an output schema covers return values, but the description still lacks essential context about how to construct queries, set time windows, or interpret results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description adds no parameter-level context. The five parameters (log_group, region, limit, query, lookback_minutes) are completely undocumented beyond their schema definitions, which is especially problematic for required parameters like log_group and region.

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 identifies the action ('Search') and the resource ('service logs in CloudWatch Logs'). It is distinguishable from the sibling ECS inspection tools, which focus on services, events, task definitions, and target health rather than log contents.

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 the sibling investigation tools. There is no mention of appropriate scenarios, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv0.1.0Jul 31, 2026
- First observedinspect_ecs_service_events
- First observedinspect_target_health
- First observedinspect_task_definition
- First observedinvestigate_ecs_service
- First observedsearch_service_logs

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

C2.7/5.0

Scored 2026-07-31 11:45 across 5 tools

Disambiguation4/5

Most tools have distinct targets: service events, task definitions, target health, and logs are clearly separate. The potential overlap is 'investigate_ecs_service', which appears to be a comprehensive umbrella that may include the others, but the description helps an agent choose it for a full investigation versus specific checks.

Naming Consistency4/5

All names follow a verb_noun snake_case pattern with clear objects. The minor inconsistency is the use of both 'investigate' and 'inspect' as near-synonyms, and 'search' for logs, but the style is predictable and readable.

Tool Count5/5

With 5 tools, this set is well-scoped for a focused ECS investigation server. Each tool addresses a clear aspect without unnecessary bloat.

Completeness4/5

The core investigation workflow covers service-level overview, events, task definitions, target health, and logs. Minor gaps exist such as listing ECS services or metrics, but these can be worked around if the service name is known.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

AIStatusDashboard
io.github.aistatusdashboard
Read-only MCP server for AIStatusDashboard status, incidents, metrics, and fallback recommendations.
Monitoring Observability
2
CostPilot
com.mcpgatepro
Hosted MCP server for AWS cloud spend: service breakdowns, anomalies, savings and forecasts.
Cloud Platforms Finance Monitoring
1
Legal Mcp
io.github.varvararatta
MCP server for Legal
Legal & Compliance Documentation Access
2
readme-canary
io.github.brkd-h1
Security research canary remote MCP server for owned-account testing.
Security Penetration Testing
11

Related MCP Servers

aws-safe-mcp
Cloud Platforms Observability Developer Tools
harryhazza77
A
license
Not graded
quality
C
maintenance
A read-only MCP server for safe, structured investigation of AWS serverless resources, providing curated tools for tracing dependencies, permissions, and failures without exposing raw SDK access.
Updated 4 months ago (2026-05-20 10:03 UTC)
MIT
aws-ecs-mcp
Cloud Platforms Monitoring CI/CD & DevOps
riteshsonawala
F
license
Not graded
quality
D
maintenance
An MCP server for managing AWS ECS clusters, services, tasks, and container logs. Enables AI assistants to perform operations like scaling, deployments, and log retrieval via natural language.
Updated 6 months ago (2026-03-09 21:18 UTC)
-
monitoring-mcp-server
harshsijariya
F
license
Not graded
quality
C
maintenance
A read-only MCP server for AWS observability that provides tools to monitor EC2, EKS, RDS, ElastiCache Redis, and CloudWatch.
Updated a month ago (2026-07-29 15:57 UTC)
-
CloudGuard MCP
Cloud Platforms Security
kishoreqwerty
F
license
Not graded
quality
C
maintenance
A read-only MCP server for inspecting AWS resources, detecting misconfigurations, and estimating costs across EC2, S3, and IAM, enabling agents to safely query and analyze cloud infrastructure.
Updated a month ago (2026-08-07 16:34 UTC)
-