Kiro MCP Server

Kiro powers

kiro_powers

Manage Kiro session powers: list a session snapshot, or install and uninstall catalog names or local paths when config writes are allowed.

Instructions

Kiro powers: list returns a session's powers snapshot (like /powers). install (a catalog name, or a local path inside KIRO_MCP_ROOTS) and uninstall run kiro-cli powers and need KIRO_MCP_ALLOW_CONFIG_WRITES.

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

Input Schema

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

Output Schema

Name	Required	Description	Default
`note`	Yes
`action`	Yes
`output`	Yes
`powers`	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 declare readOnlyHint=false, openWorldHint=true and destructiveHint=false, so the safety baseline is covered. The description adds genuinely new behavioral context: install/uninstall shell out to `kiro-cli powers` and require KIRO_MCP_ALLOW_CONFIG_WRITES, and install paths are restricted to inside KIRO_MCP_ROOTS. It stops short of saying whether uninstall is reversible or what state a failed install leaves behind.

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?

Two dense sentences with zero filler, and the `list` behavior is front-loaded before the mutating actions. The telegraphic style with backticks and nested parentheticals is efficient but slightly harder to parse than plain prose.

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?

For a three-action tool with an output schema (so return values need no explanation), the description covers action semantics, the external CLI dependency, the write-permission prerequisite, and the path constraint. The main omission is per-action parameter applicability, which an agent must infer from the schema.

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 33% and `name_or_path` has no schema description at all, but the description compensates by defining it as a catalog name or a local path inside KIRO_MCP_ROOTS. The `action` enum values are also given meaning beyond the bare enum. It does not say which actions consume `session_id` versus `name_or_path`, which is the remaining gap.

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 (powers) and spells out what each of the three actions does: `list` returns a session's powers snapshot, `install`/`uninstall` run `kiro-cli powers`. That is a specific verb+resource statement per action. It does not differentiate the tool from siblings like kiro_mcp_config or kiro_settings, which keeps it from a 5.

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 implied by the per-action gloss (use `list` to inspect, `install` to add), and the description notes the env-var precondition for install/uninstall. There is no explicit when-to-use vs alternatives guidance and no statement of when not to use it, so it lands at implied usage rather than clear guidance.

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