Kiro MCP Server

Configure a Kiro session

kiro_session_configure

Idempotent

Configure an attached Kiro session by switching its agent mode, model, effort level, or other advertised options, validating every value before applying changes and returning the updated settings.

Instructions

Switch an attached session's agent mode (session/set_mode: vibe, plan, spec, quick-spec, bug-fix, autonomous, or a custom agent), model and effort (session/set_config_option model and effortLevel), or any other advertised option such as autopilot or memoryReflection, like /model, /effort, /agent, and /plan. Every value is checked against what Kiro last advertised for the session; on VALUE_NOT_ADVERTISED nothing changes. Returns the options as Kiro reports them after the change. title renames the session. For /spec run, select mode spec and prompt the agent to run the named 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": {
      "session_id": "<session_id>"
    },
    "name": "kiro_session_configure"
  }
}

Input Schema

Name	Required	Description
`mode`	No	Agent mode id.
`model`	No	Model id.
`title`	No
`effort`	No	Effort level.
`options`	No	Config option id to value.
`session_id`	Yes	Kiro session id (sess_<uuid>).

Output Schema

Name	Required	Description	Default
`title`	Yes
`changed`	Yes
`session_id`	Yes
`current_mode`	Yes
`config_options`	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 declare this a non-destructive, idempotent, open-world mutation, and the description adds real behavioral value on top: every value is validated against what Kiro last advertised, and on VALUE_NOT_ADVERTISED nothing is applied. It also discloses the return payload (post-change options as Kiro reports them) and that title performs a rename. It stops short of noting any permission or auth requirements, or whether a rename affects the existing session handle.

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?

A single front-loaded paragraph that leads with the switchable targets and puts the validation/failure contract and the /spec recipe afterward in priority order. It is dense but largely earns its length; the parenthetical protocol method names add minor noise for an agent that will never call them directly.

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?

Covers the mutation contract, validation and no-op failure behavior, the value space for modes, and a workflow for /spec, which is a lot for a 6-parameter tool with a nested options map. Since an output schema exists, the brief note about the returned options is sufficient; only the interaction between top-level model/effort and the options map remains unstated.

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?

With 83% schema coverage the baseline is 3, but the description goes further: it spells out the mode value space, ties `model` and `effort` to the `model`/`effortLevel` config options, and clarifies that `options` accepts 'any other advertised option such as autopilot or memoryReflection', which explains the free-form map that the schema leaves generic. It does not clarify whether model/effort can equivalently be passed through `options`, leaving that overlap ambiguous.

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?

States a specific verb and resource ('Switch an attached session's agent mode / model and effort / any other advertised option') and enumerates the exact mode ids (vibe, plan, spec, quick-spec, bug-fix, autonomous). It also names the underlying protocol methods (session/set_mode, session/set_config_option) and the slash commands it mirrors, so an agent can immediately separate it from siblings like kiro_session_state or kiro_session_new.

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 clear usage context by mapping the tool to /model, /effort, /agent, and /plan, plus an explicit recipe for the /spec case ('select mode `spec` and prompt the agent to run the named spec'). It does not, however, state when NOT to use it — e.g. that read-only inspection belongs to kiro_session_state and session creation to kiro_session_new — so routing away from alternatives is left implicit.

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