AWS MCP Server Can Now Diagnose Live Lambda — What UK Teams Should Do This Week
On 4 Sep 2026 AWS added a serverless capability to AWS MCP Server so coding agents can inspect live Lambda and connected services in one call. What changed, why it matters for UK AWS estates, and a practical rollout.
On 4 Sep 2026 AWS added a serverless capability to AWS MCP Server so coding agents can inspect live Lambda and connected services in one call. What changed, why it matters for UK AWS estates, and a practical rollout.
- AWS MCP Server can now diagnose live Lambda and connected services in one call.
- Errors are correlated against a 7-day baseline — fewer tokens than many API calls.
- Start read-only on one non-prod function; tighten IAM before production.
- Pair with ServiceNow for tickets and CMDB — do not replace ITOM.
- MCP control plane region is not your Lambda region.
Why this is the trend
Agents are moving from “write a function” to “debug production.” On 4 September 2026, AWS added a serverless capability to AWS MCP Server so coding agents can inspect live Lambda functions and their connected services in a single call.
That is the missing ops layer for teams already experimenting with Bedrock agents and MCP.
What actually shipped
The AWS MCP Server (via the Agent Toolkit for AWS, or as a standalone install) can now:
- Inspect a running Lambda and connected resources across API Gateway, EventBridge, S3, DynamoDB, SNS, SQS, and Step Functions
- Correlate errors against a 7-day baseline to show what changed
- Surface recurring errors, deployed configuration, a change timeline, and latency across the path
- Return that picture in one call, using fewer tokens than stitching many APIs
The diagnostic capability is no extra AWS charge. The MCP control plane runs in US East (N. Virginia) and Europe (Frankfurt); your function data still lives in the commercial regions you already use.
Get started with aws configure agent-toolkit, or enable the AWS MCP Server directly.
Enterprise impact for UK teams
If you already run Bedrock agents — or plan to wire MCP into ServiceNow — this is how those agents stop guessing. The same agent that writes Lambda can now explain last night’s 5xx without a human hopping through CloudWatch.
Frankfurt presence helps the UK conversation on control-plane locality. Still confirm where function logs and payloads remain. Treat this as diagnosis, not a replacement for ServiceNow ITOM / Event Management.
What to do this week
- Enable AWS MCP Server against one non-prod Lambda with a known noisy integration.
- Ask: “What changed in the last 7 days, and which resource is driving latency?”
- Compare the answer to CloudWatch Insights. If it matches, expand to one production function with tight IAM.
- Do not grant
iam:*or production write. Start with read, logs, and config. - If ServiceNow ITOM is in play, feed diagnosis into incidents and the CMDB — do not replace Event Management.
Strategic risks
Over-scoped IAM, agents that “fix” production unattended, and treating MCP output as gospel without a baseline check. Also: MCP server region is not the same as your Lambda region.
Expert commentary
This is the same pattern we already see on ServiceNow (Now Assist / MCP): the platform that holds the work is becoming the platform that explains the work. AWS just did it for serverless. Teams that wire diagnosis → change record → CMDB CI will pull ahead of teams that only prompt.
This is the same pattern we already see on ServiceNow (Now Assist / MCP): the platform that holds the work is becoming the platform that explains the work. AWS just did it for serverless. Teams that wire diagnosis → change record → CMDB CI will pull ahead of teams that only prompt.