Kiro MCP Server

Kiro tangents

kiro_tangent

Forks a Kiro session at its latest message into a named tangent, displays the tangent tree, and merges a tangent's findings summary into a parent, root, or other tangent as a new turn.

Instructions

Tangents, like /tangent: branch forks the session at its latest message into a named side conversation (default tangent-N) and attaches it; tree shows the recorded tangent tree; merge prompts the tangent once for a short findings summary, then sends that summary to the destination (parent by default, root, or a tangent name) as a new turn. The tangent itself is left unchanged. The tangent tree is held in this server's memory and does not survive a restart; the forked sessions stay in Kiro's store.

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>",
      "session_id": "<session_id>"
    },
    "name": "kiro_tangent"
  }
}

Input Schema

Name	Required	Description
`name`	No
`action`	Yes
`wait_s`	No	Seconds to wait for the summary turn and the destination turn (default 50, max 55).
`session_id`	Yes	Kiro session id (sess_<uuid>).
`destination`	No

Output Schema

Name	Required	Description	Default
`name`	Yes
`note`	Yes
`tree`	Yes
`merge`	Yes
`action`	Yes
`tangent_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 give a safety profile (not read-only, not destructive, non-idempotent, open-world), and the description adds genuinely new behavior: the tangent tree lives only in server memory and is lost on restart, while the forked sessions persist in Kiro's store, and `merge` leaves the tangent unchanged. That statefulness caveat is exactly the kind of context annotations cannot convey. It does not mention that `merge` spends model turns on two sessions or what happens on timeout.

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?

The description is dense but front-loaded with the concept, then walks branch/tree/merge in one semicolon-linked sentence, closing with the persistence caveat. Every clause carries information; the only cost is the run-on structure, which makes it slightly harder to scan than a per-action list would be.

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?

With an output schema present, return values need not be explained, and the description covers the stateful caveat, merge semantics, and destination defaults. What remains thin is failure behavior — partial failure when the summary turn succeeds but the destination turn does not, and what `merge` returns — for a tool whose annotations flag it as non-idempotent and open-world.

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 coverage is only 40%, so the description has to compensate, and it does: it documents the default tangent name (`tangent-N`) and the `destination` resolution order (`parent` by default, `root`, or a tangent name). `wait_s` and `session_id` are covered by schema descriptions instead. The `action` enum values are explained with real semantics rather than just listed.

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 the resource (tangents) and spells out each of the three verbs — `branch` forks at the latest message into a named side conversation, `tree` shows the recorded tangent tree, `merge` summarizes and sends findings to a destination. This is far more specific than the title. It stops short of differentiating from the sibling `kiro_session_fork`, which an agent could easily confuse with `branch`.

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?

Per-action semantics imply usage: use `branch` to create a side conversation, `tree` to inspect, `merge` to fold findings back. However, there is no explicit guidance on which action to pick versus the sibling `kiro_session_fork`, no stated prerequisites (e.g., the session must exist and have at least one message), and no when-not conditions.

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