Kiro MCP Server

Prompt a Kiro session

kiro_prompt

Send a prompt to an attached Kiro session and wait for the turn to finish, returning final text, tool calls, or a running status with a cursor for polling events.

Instructions

Send a prompt to an attached session (session/prompt) and wait up to wait_s for the turn to finish. Returns the finished turn (final text, tool calls, credits) or status running with a turn_id and cursor: then poll kiro_events with that cursor until the status is completed, cancelled, or failed, answering any pending_permissions with kiro_permission_respond. A turn finishes only when Kiro answers the prompt. Add files as links (or embedded UTF-8 text with embed: true) and images from a path or base64. command runs an advertised skill, MCP prompt, or sub-agent as /<name> <input>; text starting with @name runs a saved prompt. when_busy queue waits behind the running turn.

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_prompt"
  }
}

Input Schema

Name	Required	Description
`text`	No
`files`	No
`images`	No
`wait_s`	No	Seconds to wait (default 20, max 55).
`command`	No
`when_busy`	No
`session_id`	Yes	Kiro session id (sess_<uuid>).

Output Schema

Name	Required	Description	Default
`turn`	Yes
`cursor`	Yes
`queued`	Yes
`status`	Yes
`turn_id`	Yes
`session_id`	Yes
`pending_permissions`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.1Nov 5, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations only mark this as a non-readonly, open-world, non-idempotent write. The description adds real behaviour: a bounded blocking wait (wait_s), the two possible outcomes (finished turn vs `running` plus turn_id/cursor), and the fact that a turn only finishes when Kiro answers. It mentions credits as a returned field but says nothing about cost accrual or turn limits.

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?

Front-loaded with the core action and tightly written; every clause carries information about return status, poll continuation, or parameter encoding. It is dense to the point of being a single run-on paragraph, so scanning for the `when_busy` detail takes effort, but there is no filler.

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?

For a tool with nested objects, an async continuation protocol, and a permission loop, the description covers invocation, failure/timeout continuation, and the escalation path. An output schema exists, yet the brief return summary is still a useful addition rather than redundancy.

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

Parameters5/5

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

Schema coverage is only 29%, but the description compensates heavily: files as links or embedded UTF-8 via `embed`, images by path or base64, `command` running an advertised skill/MCP prompt/sub-agent as `/<name> <input>`, `@name` shorthand for saved prompts, and `when_busy: queue`. That covers nearly every undocumented parameter of the seven.

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?

Opens with a specific verb and resource ("Send a prompt to an attached session (session/prompt)") and states the blocking semantics. It is clearly separable from siblings like kiro_events (polling), kiro_permission_respond (approvals), and kiro_steer without opening any schema.

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?

Gives explicit follow-up paths: if status is `running`, poll kiro_events with the cursor until completed/cancelled/failed, and answer pending_permissions with kiro_permission_respond. It also explains `when_busy` queue behaviour. It stops short of telling the agent when to prefer kiro_steer, kiro_tangent, or kiro_run_headless instead, which would have made routing fully unambiguous.

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