Wiring MCP and Kiro Into Triage for Event-Driven Bounded-Context Systems

If your platform runs as a set of bounded contexts talking over EventBridge, you already know the worst part of an incident isn't finding the failing service — it's figuring out which context actually owns the problem. A TicketEscalated event fires, a downstream consumer chokes, and the on-call engineer is left tabbing between five log groups trying to reconstruct a domain story that no single service can tell on its own.

This is the specific gap that Model Context Protocol (MCP) and Kiro, AWS's agentic IDE, are useful for closing — not as a generic "AI does ops" pitch, but as a concrete way to give an agent the same domain vocabulary your team already uses, scoped to the same boundaries your architecture already has.

Most AI-assisted troubleshooting tools are built around a single surface: metrics, logs, or traces, queried with whatever vocabulary the underlying API exposes. That works fine when a system is one deployable unit. It breaks down once you have multiple bounded contexts — Ticketing, SLA, Escalation, say — each with its own data model, publishing and consuming domain events through EventBridge.

An agent that only knows how to grep CloudWatch Logs will hand you a wall of stack traces. It won't tell you that the failure is actually a violation of an invariant between the SLA context and the Escalation context, because it has no concept of what those contexts are, or which team owns which event type. Closing that gap means giving the agent two things: read access to the right telemetry, and a map of your domain that tells it how to interpret what it reads.

MCP is the right tool for the first half of that problem because of what it deliberately doesn't do: it doesn't ship you a monolithic "AWS agent" with blanket access. AWS's own managed MCP Server, generally available since May 2026, exposes a single call_aws tool that can reach any of AWS's 15,000+ API operations — but it does so through your existing IAM credentials, with IAM context keys that let you scope exactly what an agent session is allowed to touch, and CloudTrail logging so every call is auditable. AWS Labs also publishes purpose-built servers for this use case specifically — the CloudWatch MCP Server and the Application Signals MCP Server — which let an agent query alarms, metric anomalies, log patterns, and OpenTelemetry-based service health without you writing custom query code.

For a bounded-context system, the practical pattern is to go one step further than "connect the AWS MCP server" and stand up a thin MCP server per bounded context — or per aggregate root, if a context is large — exposing a handful of read-only tools in your ubiquitous language rather than raw table or API access:

That's the difference between an agent that can run arbitrary log queries and one that can answer "did the SLA context see this ticket before Escalation did?" in one call. It's a small amount of glue code — a Lambda-backed MCP server per context, using the same IAM-scoped access pattern as AWS's managed server — but it's what turns MCP from a generic connector into a domain-aware triage tool.

Kiro is where this becomes something a platform team actually runs, rather than a one-off script. Two Kiro-native mechanisms map directly onto DDD concepts:

Steering files are markdown documents that give Kiro persistent, project-wide context — the kind of thing you'd otherwise have to re-explain in every session. This is where your bounded-context map belongs: which context owns which event types, the ubiquitous language for each, and which MCP tools correspond to which context. Instead of an agent reasoning about your system from log strings, it reasons from the same context map your team designed.

Agent hooks are triggers that fire predefined agent actions on IDE or pipeline events — file saves, before/after tool execution, before/after a spec task runs. Wired to an EventBridge rule (for example, one that fires when a message lands in a dead-letter queue, or when a CloudWatch alarm tied to a specific bounded context goes into ALARM), a hook can kick off a Kiro triage session automatically: pull the failing event's correlation ID, query the CloudWatch MCP server for the surrounding metrics and logs, query your context-specific MCP servers for the domain state on both sides of the boundary, and produce a structured summary before a human opens a single dashboard.

The rough wiring looks like this:

EventBridge rule (DLQ message / alarm state change)

A few things to plan around rather than discover mid-incident:

Kiro's MCP support is available on the free tier and all paid plans, but the MCP ecosystem itself is more mature around Claude Code than Kiro today — if a third-party server you're evaluating advertises Claude Code first, test it against Kiro directly before depending on it.

None of this works without correlation IDs propagated consistently through your EventBridge event envelopes. If a context publishes an event without carrying forward the correlation and causation IDs from the event that triggered it, no amount of MCP tooling will let an agent reconstruct the cross-context story — that discipline has to be enforced at the domain-event schema level, not bolted on afterward.

Scope each context's MCP server to read-only tools. The value here is investigation and summarization, not letting an agent take remediation actions across a context boundary it doesn't own — keep that decision with the team that owns the context.

Finally, the MCP specification itself is still moving: the 2026-07-28 release candidate is the largest revision since launch, reworking authorization to align more closely with OAuth/OIDC and introducing a Tasks extension for long-running work. If you're standing up custom per-context servers now, build the auth layer expecting it to need an update, and treat long-running investigations as a near-term candidate for the Tasks extension once it's stable rather than something to hack around today.

You don't need to wire every bounded context into this at once. Pick the one that generates the most cross-context confusion during incidents — usually the one other teams page for events they didn't publish — stand up a single read-only MCP server for it, write the steering file describing its ubiquitous language, and wire one hook to one EventBridge rule. The value of this pattern shows up the first time an agent tells your on-call engineer which context actually owns the invariant that broke, instead of a log line to interpret alone.