Kiro MCP Server

Kiro spec documents

kiro_specs

Read-onlyIdempotent

Inspect Kiro spec-driven development output: list spec folders with document availability, modification times, and task progress, or read a selected spec document with parsed task status.

Instructions

Read Kiro spec-driven development output under /.kiro/specs, like /spec and /spec view. list shows each spec folder, which of requirements.md, bugfix.md, design.md, and tasks.md exist, their modification times, and checked versus unchecked task counts. read returns one document (truncated at 200 KiB), with parsed tasks for tasks.md. To create or run a spec, select mode spec (or quick-spec, bug-fix) with kiro_session_configure and prompt the agent, for example "run the tasks in the spec".

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": {
      "action": "<action>",
      "cwd": "<cwd>"
    },
    "name": "kiro_specs"
  }
}

Input Schema

Name	Required	Description
`cwd`	Yes	Workspace directory inside KIRO_MCP_ROOTS.
`spec`	No
`action`	Yes
`document`	No

Output Schema

Name	Required	Description	Default
`cwd`	Yes
`specs`	Yes
`document`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.1Nov 5, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already establish readOnly, idempotent, non-destructive, closed-world behavior, so the bar is lower, and the description still adds real traits: the storage location under <cwd>/.kiro/specs, the 200 KiB truncation limit on `read`, and that tasks.md comes back with parsed task structures. It does not discuss behavior for missing documents or spec folders, which is the only notable omission given the safety profile is already covered.

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?

Content is front-loaded: location and purpose first, then per-action behavior, then the escape hatch to kiro_session_configure. The `/spec` and `/spec view` analogy is a small amount of extra framing, but the three sentences are dense and each carries information.

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?

An output schema exists, so return formatting need not be spelled out, yet the description still characterizes the list payload (file presence, mtimes, checked/unchecked counts) and the read payload (truncation, parsed tasks). What keeps it from a 5 is the unstated action-to-parameter dependency and unstated failure behavior for nonexistent specs.

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

Parameters3/5

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

Schema description coverage is only 25% (only `cwd` is documented), so the description must carry more weight — and it does explain the meaning of the `action` values and effectively enumerates the four `document` filenames. However, it never states that `spec` and `document` are required for `read` and unused for `list`, leaving the conditional parameter contract to inference.

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?

Description opens with a specific verb and resource ("Read Kiro spec-driven development output under <cwd>/.kiro/specs") and then decomposes both actions: `list` enumerates spec folders, present files, mtimes and task counts; `read` returns a single document with parsed tasks. This is far more precise than the title and makes the tool trivially distinguishable from siblings like kiro_session_configure or kiro_memory.

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

Usage Guidelines5/5

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

It explicitly routes the agent away to an alternative: creating or running a spec requires kiro_session_configure with mode spec/quick-spec/bug-fix plus a prompt, with a concrete prompt example. That is a genuine when-to-use-this vs when-to-use-something-else statement, not just implied context.

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