Kiro MCP Server

Kiro session state

kiro_session_state

Read-onlyIdempotent

Retrieve a Kiro session's state, including MCP servers, tools, steering, skills, config, context, and models, to verify what the session will use and diagnose configuration errors.

Instructions

Snapshots of what a session will use: MCP servers (status, failed authorization, tool names), tool tags, steering documents, skills, powers, governance flags, agent config errors, the command catalog, modes, config options, context usage (plus _kiro/session/context), and the /config panel including hooks (_kiro/configuration/getState). A snapshot that has not arrived yet comes back with received: false. Large fields (tool schemas, steering content, skill descriptions) are left out unless verbose. models works without a session (kiro-cli chat --list-models).

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": {
      "include": "<include>"
    },
    "name": "kiro_session_state"
  }
}

Input Schema

Name	Required	Description
`include`	Yes
`verbose`	No
`session_id`	No	Kiro session id (sess_<uuid>).

Output Schema

Name	Required	Description	Default
`state`	Yes
`session_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.1Nov 5, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive, open-world, so the description's marginal value is in traits annotations cannot express: pending snapshots return 'received: false', and large fields (tool schemas, steering content, skill descriptions) are elided unless verbose. It also cross-references alternate paths (_kiro/session/context, _kiro/configuration/getState). It does not state authorization or rate-limit behavior, so this is strong but not exhaustive.

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

Conciseness3/5

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

The purpose is front-loaded in the first clause, which is good, but the body is a long comma-spliced inventory of categories that reads as a run-on rather than structured guidance. Most items earn their place via the enum mapping, yet the density makes it harder to scan than a short tiered structure would.

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

Completeness5/5

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

An output schema exists, so return shape need not be described; the description instead spends its budget on the non-obvious edges: the not-yet-arrived 'received: false' case, verbose-driven field omission, and session-free `models`. For a read-only snapshot tool with three parameters, this covers what an agent needs to call it correctly.

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 33% (just session_id), so the description has to compensate, and largely does: the enumerated categories map onto the `include` enum values, `verbose` is explained as the switch that includes large fields, and the `models` note implies session_id is otherwise required. It never states whether `include` can combine values, though the schema's array/minItems/maxItems implies it.

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

Purpose4/5

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

The description names a specific resource ('Snapshots of what a session will use') and enumerates exactly what is captured: MCP servers, steering documents, skills, governance flags, config options, context usage. An agent can distinguish it from siblings like kiro_status or kiro_session_list. It stops short of naming those siblings explicitly, so cross-tool differentiation rests on inference.

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

Usage Guidelines3/5

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

Usage is only implied: the tool is for inspecting a session's resolved configuration. There is no explicit 'use this when...' and no exclusion or pointer to kiro_status, kiro_usage, or kiro_session_export for overlapping data. The one genuine routing hint is '`models` works without a session', which tells the agent a session-scoped call is not always mandatory.

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