Kiro MCP Server

Stream a Kiro session transcript

kiro_stream_session

Read-onlyIdempotent

Stream a Kiro session transcript live: fetch events after a cursor plus the next cursor, optionally waiting for new events, and replay history for sessions this server did not start.

Instructions

Follow a session's transcript live: returns events after cursor (agent text, tool calls and results, plan updates, permission requests, turn events) and the next cursor, waiting up to wait_s (default 1 s) when nothing is newer. Works for sessions this server did not start: they are loaded first, so their history comes first (replay: true), then live events. Re-reading a cursor returns the same events; gap: true means older events were dropped. types filters (skipped events still advance the cursor); max_chars caps the page and sets truncated: true. Also available as the subscribable resource kiro-session://<session_id>/transcript (notifications/resources/updated within a second of new events).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "session_id": "<session_id>"
    },
    "name": "kiro_stream_session"
  }
}

Input Schema

Name	Required	Description
`limit`	No
`types`	No
`cursor`	No
`wait_s`	No	Seconds to wait for a new event (default 1).
`max_chars`	No
`session_id`	Yes	Kiro session id (sess_<uuid>).
`include_thoughts`	No

Output Schema

Name	Required	Description	Default
`gap`	Yes
`uri`	Yes
`events`	Yes
`turn_id`	Yes
`truncated`	Yes
`session_id`	Yes
`next_cursor`	Yes
`turn_status`	Yes
`lowest_cursor`	Yes
`session_state`	Yes
`omitted_thoughts`	Yes
`pending_permissions`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.1Nov 5, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive), and the description adds substantial behavior beyond them: blocking wait semantics with a default, replay-then-live ordering for externally started sessions, idempotent cursor re-reads, a gap:true signal for dropped events, cursor advancement under type filtering, and truncation via max_chars. It even documents the notification latency of the resource equivalent.

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?

It is front-loaded with the core behavior and every clause carries information (cursors, replay, gap, filters, truncation, resource alternative). It is a dense single block with heavy backticked field names, which is efficient but slightly hard to scan compared with a short structured breakdown.

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

Completeness4/5

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

For a streaming tool with an output schema, it covers the return-signal semantics an agent must interpret (replay, gap, truncated, next cursor) plus the resource alternative. The only missing pieces are the meaning of `limit` and `include_thoughts`, which neither schema nor description explains.

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

Parameters4/5

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

Schema description coverage is only 29% (just session_id and wait_s), so the description must compensate, and it does for cursor, types, max_chars, and wait_s with semantics the schema cannot express. However, `limit` and `include_thoughts` are left entirely undefined in both schema and description, which is a real gap for a 7-parameter tool.

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 opens with a specific verb and resource ('Follow a session's transcript live') and immediately enumerates the event kinds returned (agent text, tool calls and results, plan updates, permission requests, turn events). This clearly separates it from one-shot siblings like kiro_session_history or kiro_session_export without needing to open their schemas.

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

Usage Guidelines4/5

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

It gives concrete usage context: wait up to wait_s when nothing is newer, works for sessions the server did not start, re-reading a cursor is safe, and a subscribable resource exists as an alternative transport. It never explicitly names kiro_session_history or kiro_events as the non-live alternatives, so the routing guidance is strong but not fully explicit.

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