AWS gave coding agents a read-only Lambda incident lane

On September 4, 2026, AWS added a serverless diagnostic capability to AWS MCP Server. A coding or operations agent can now gather health signals, recent logs, deployed configuration, change history, and trace summaries for an AWS Lambda function and several connected services through one managed Model Context Protocol endpoint.

The immediate value is faster evidence gathering during an incident. The important limit is just as useful: AWS documents the capability as read-only. It can support a diagnosis, but it cannot prove the diagnosis or make the repair. This article explains what the endpoint can see, what “read-only” does and does not protect, and how to test it against a known incident before putting it in an on-call workflow.

What does the serverless capability gather?

The AWS MCP Server gives compatible agents one managed endpoint for AWS information and tools. AWS says agents use the caller’s existing IAM credentials for authenticated API access. CloudTrail records API calls, while CloudWatch provides service metrics for the MCP endpoint.

The new capability is scoped to the caller’s AWS account. It starts from a Lambda function and can inspect connected Amazon SQS, Amazon SNS, Amazon DynamoDB, Amazon API Gateway, Amazon EventBridge, and AWS Step Functions resources. That supported list matters: the agent receives a structured view of those relationships, not a universal map of every dependency in a production system.

AWS exposes five helper functions for the investigation:

• diagnose combines current health, connected-resource discovery, rule-based diagnosis, and metrics compared with a seven-day baseline;
• search_logs groups recent CloudWatch log evidence into common exception types and representative lines;
• get_live_config returns deployed settings for Lambda and supported connected resources;
• get_recent_changes builds a timeline from CloudTrail, Lambda APIs, and CloudFormation, including who changed a setting and its previous and new values; and
• get_trace_summary summarizes recent AWS X-Ray traces, using the last 30 minutes by default.

This packaging changes the mechanics of triage. An agent does not need to assemble the same initial picture through a long sequence of generic API calls. AWS says the combined response can reduce tool calls and token use, but it has not published an independent benchmark for that claim.

Why can one structured call improve incident triage?

A Lambda failure often sits at a boundary. The function may be healthy while a DynamoDB index is throttled, an SQS visibility timeout conflicts with the function timeout, reserved concurrency is exhausted, or an API Gateway path changed. Looking only at the Lambda log can hide that relationship.

The structured helpers bring several useful comparisons into the same investigation. Current metrics can be compared with a seven-day baseline. Live configuration can be checked against likely drift. A recent-change timeline can put a deployment or setting change beside the first error. X-Ray can show whether latency accumulated inside the function or in a downstream call.

That is enough to produce a better first hypothesis. It is not enough to declare a root cause. A seven-day baseline can normalize a recurring defect. CloudTrail can show that a setting changed before an outage without proving the change caused it. Grouped logs can omit an unusual line, and X-Ray returns no useful trace summary if tracing was not enabled before the incident.

The operational gain is therefore narrower and more defensible: reduce time spent locating initial evidence, then give the responder a concrete hypothesis and source path to verify.

What does read-only protect?

AWS documents the serverless capability itself as read-only. An agent using these helpers can inspect supported evidence but cannot update a function, change concurrency, purge a queue, roll back a stack, or restart a workflow through this capability. That creates a clean place to begin an operations pilot because evidence gathering and production mutation remain separate.

Read-only is not the same as low sensitivity. Logs may contain request data, exception payloads, identifiers, or secrets that an application wrote by mistake. Configuration can reveal environment variables, network design, resource names, and operational limits. Change history can expose actor identities and deployment details. The IAM principal should receive only the read actions and resource scope required for the pilot.

Read-only also describes effect, not completeness. If the incident depends on an unsupported service, an external API, application state outside AWS, missing logs, or disabled tracing, the agent’s view can be coherent and incomplete. Record those blind spots before anyone treats “no anomaly found” as evidence that the system was healthy.

How should a team test the diagnosis path?

Use a synthetic or sanitized incident with a reviewed explanation. Choose one Lambda function and one supported connected resource. Preserve the relevant time window, configuration change, log signature, and expected service behavior so the agent’s account can be compared with known evidence.

Run the investigation with the exact IAM role, coding client, MCP configuration, and region intended for the pilot. Ask the agent to explain which helper supplied each claim. Save the tool calls and identifiers needed for a person to reopen the source evidence.

Check five things:

1. Coverage: Does the connected-resource view include the dependency that actually failed? Record every important system that remains outside the supported graph.
2. Time alignment: Do metrics, logs, changes, and traces use a compatible incident window? A correct signal from the wrong period can support a persuasive but false sequence.
3. Source recovery: Can a responder reproduce each material claim in CloudWatch, CloudTrail, CloudFormation, Lambda configuration, or X-Ray without relying on the agent’s prose?
4. IAM scope: Can the test identity read only the functions, logs, traces, and connected resources required for its job? Inspect denied calls as well as successful ones.
5. Repair handoff: Does the agent stop after presenting evidence and a proposed action? The runbook should name the person or separately controlled system that approves and performs a change.

Compare the same incident with the team’s existing console or command-line process. Measure time to the first relevant source, unsupported claims, missed evidence, IAM denials, and time to a reviewed repair decision. Do not use model eloquence or the length of the diagnosis as a success measure.

When should the pilot stop?

Stop if the agent cannot expose the source, time range, resource identifier, or API evidence behind a material claim. A diagnosis that cannot be reopened is not a useful incident record.

Stop if the required IAM role can read materially more production data than the responder’s job requires. Also stop if absent telemetry becomes an unqualified “healthy” result, if unsupported dependencies disappear from the explanation, or if the workflow silently switches from diagnosis to a tool with write authority.

The last condition deserves an explicit control. AWS MCP Server supports broader authenticated AWS API access outside this specialized capability. The fact that the serverless helpers are read-only does not prove that every tool exposed to the same agent session is read-only. Inventory the whole endpoint and client configuration, not just the helper selected for the demo.

What decision can the pilot support?

A successful pilot shows that the agent reaches the right logs, configuration, change events, metrics, and traces faster; keeps each claim tied to inspectable evidence; stays inside a limited IAM role; and hands a proposed repair to the existing approval path. It does not show that the agent can independently determine root cause across every serverless incident.

AWS says the serverless capability is available at no additional cost. That statement applies to the capability, not the underlying AWS telemetry and service usage. Cost is unlikely to be the hardest adoption question. Evidence coverage and authority are.

The practical use is a read-only front end to an existing incident process. Adopt it when it shortens evidence gathering without hiding blind spots or blending diagnosis with remediation. Keep the current triage path when the supported graph, telemetry, IAM design, or repair handoff is not ready.

BaristaLabs can help test one Lambda triage path with a known incident, limited identity, reproducible evidence, and a separate repair decision.

Sources

• AWS: AWS MCP Server adds a serverless capability for AWS Lambda functions, September 4, 2026.
• AWS Agent Toolkit: AWS MCP Server, accessed September 8, 2026.
• AWS Agent Toolkit: Serverless capability, accessed September 8, 2026.