Kiro CLI MCP Server

by vanphappi

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, but there is some overlap between kiro_chat and kiro_command, as both involve sending messages or commands to kiro-cli, which could cause confusion. However, descriptions clarify that kiro_chat is for AI responses and kiro_command for CLI commands, mitigating ambiguity.
Naming Consistency5/5
All tool names follow a consistent kiro_ prefix with snake_case and clear verb_noun patterns (e.g., kiro_agents_list, kiro_session_create). This uniformity makes the tool set predictable and easy to navigate.
Tool Count4/5
With 16 tools, the count is slightly high but reasonable for a CLI server covering agents, chat, sessions, and tasks. It feels comprehensive without being overwhelming, though some tools like kiro_session_clear and kiro_history_clear might be redundant.
Completeness4/5
The tool set provides good coverage for managing kiro-cli sessions, agents, chat, and async tasks, with clear CRUD-like operations (e.g., create, list, end, clear). Minor gaps exist, such as no direct tool for updating sessions or agents, but agents can work around this using chat or commands.
Average 3.1/5 across 16 of 16 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('switch') but doesn't explain what switching does (e.g., changes active context, loads session state), potential side effects, permissions needed, or error conditions. This leaves significant gaps for a mutation-like tool.
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 a single, efficient sentence with no wasted words, making it appropriately sized and front-loaded. However, it's so brief that it under-specifies the tool's behavior, slightly reducing its effectiveness despite good structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (implied mutation with no annotations), 100% schema coverage, and no output schema, the description is incomplete. It doesn't explain what 'switch' means operationally, what happens after switching, or how it interacts with siblings, leaving the agent with insufficient context for safe use.
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?
The description doesn't add meaning beyond the input schema, which has 100% coverage and fully documents the single parameter 'session_id.' Since schema_description_coverage is high, the baseline is 3, and the description doesn't compensate with extra details like format examples or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Switch to a specific session' clearly states the action (switch) and target (session), but it's vague about what 'switch' entails (e.g., context change, activation) and doesn't differentiate from siblings like kiro_session_create or kiro_session_end. It avoids tautology by not just restating the name, but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing session), exclusions, or comparisons to siblings like kiro_session_list or kiro_session_clear. Usage is implied only by the verb 'switch,' but no explicit context or alternatives are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions sending a message and getting an AI response, but it doesn't cover critical aspects like authentication needs, rate limits, error handling, or what the response format looks like (especially since there's no output schema). This leaves significant gaps for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It is appropriately sized and front-loaded, making it easy for an agent to quickly grasp the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a chat tool with AI interaction, no annotations, and no output schema, the description is incomplete. It lacks details on response format, error conditions, or behavioral traits like streaming implications. This makes it inadequate for an agent to fully understand how to invoke and interpret results from this tool.
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 100%, so the schema already documents all parameters (message, session_id, stream) with their types and descriptions. The description adds no additional meaning beyond what the schema provides, such as examples or usage context for parameters. Baseline 3 is appropriate when the schema does the heavy lifting.
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 clearly states the tool's purpose with a specific verb ('send') and resource ('chat message to kiro-cli'), and it includes the outcome ('get AI response'). It distinguishes from some siblings like kiro_history (history-related) and kiro_session_* (session management), but it doesn't explicitly differentiate from kiro_chat_async (which likely handles asynchronous chat).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention kiro_chat_async (a likely sibling for async operations) or other chat-related tools, nor does it specify any prerequisites, contexts, or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool executes commands but doesn't describe what that entails—whether it's read-only or mutative, what permissions are needed, how errors are handled, or what the output looks like. This is inadequate for a command execution tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence with parenthetical examples—and front-loaded with the core purpose. Every word earns its place, making it easy to parse without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a command execution tool with no annotations, no output schema, and many siblings, the description is incomplete. It doesn't address behavioral traits, usage context, or output expectations, leaving significant gaps for the agent to navigate.
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?
The schema description coverage is 100%, so the schema already documents both parameters fully. The description adds no additional meaning beyond what's in the schema, such as command syntax examples or session ID context. Baseline 3 is appropriate when the schema does the heavy lifting.
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 clearly states the verb 'execute' and the resource 'kiro-cli command', with examples like '/mcp' and '/help' that help illustrate the tool's function. However, it doesn't explicitly differentiate this general command execution tool from its more specific siblings like kiro_chat or kiro_task_list, which might handle particular command types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus its siblings. It doesn't mention alternatives, prerequisites, or exclusions, leaving the agent to infer usage from context alone. This is a significant gap given the many specialized sibling tools available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but lacks critical behavioral details: it doesn't specify if this is a read-only operation (implied by 'Get' but not explicit), what the return format looks like (e.g., structured messages, timestamps), whether it requires authentication, or if there are rate limits. For a history retrieval tool, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the core purpose without unnecessary words. It efficiently communicates the essential function, making it easy for an agent to parse quickly. Every word earns its place, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of retrieving conversation history and the absence of both annotations and an output schema, the description is incomplete. It doesn't explain what 'conversation history' entails (e.g., message content, metadata, ordering), how results are structured, or potential errors. For a tool with no structured behavioral hints, this leaves the agent under-informed about critical operational aspects.
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 100%, with both parameters (session_id and limit) well-documented in the schema. The description adds no additional parameter semantics beyond implying the tool operates on sessions. This meets the baseline of 3 since the schema does the heavy lifting, but the description doesn't compensate with extra context like parameter interactions or examples.
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 clearly states the action ('Get') and resource ('conversation history for a session'), making the purpose immediately understandable. It distinguishes from siblings like kiro_chat (which appears to send messages) and kiro_history_clear (which clears history), though it doesn't explicitly contrast them. The description avoids tautology by specifying what type of history is retrieved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an active session), when not to use it, or how it differs from related tools like kiro_session_list or kiro_task_list. The agent must infer usage from the tool name and context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Clear') but doesn't explain what 'Clear' entails—e.g., whether it's irreversible, requires specific permissions, affects other data, or has side effects. This leaves critical behavioral traits unspecified for a potentially destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it efficient and easy to parse, which is ideal for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a 'clear' operation with no annotations or output schema, the description is insufficient. It doesn't cover behavioral aspects like destructiveness, authorization needs, or what 'Clear' means in practice. For a tool that likely modifies or deletes data, this lack of context makes it incomplete for safe and effective use.
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?
The input schema has 100% description coverage, with the parameter 'session_id' documented as 'Optional session ID'. The description adds no additional meaning beyond this, such as explaining what happens if 'session_id' is omitted or providing context for its use. With high schema coverage, the baseline score of 3 is appropriate.
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 clearly states the action ('Clear') and resource ('conversation history for a session'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'kiro_session_clear' or 'kiro_history', which might have overlapping or related functionality, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'kiro_session_clear' and 'kiro_history', there's no indication of differences, prerequisites, or exclusions, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('End') but doesn't explain what 'ending' entails—whether it terminates processes, frees resources, or has irreversible effects. This lack of detail makes it difficult for an agent to assess the tool's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words, making it easy to parse and understand immediately. It is appropriately sized for a simple tool with one parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain the outcome of ending a session (e.g., whether it returns confirmation, frees resources, or affects other tools), leaving gaps in understanding the tool's full behavior and implications.
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?
The input schema has 100% description coverage, with the single parameter 'session_id' clearly documented. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline for adequate but not exceptional coverage.
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 clearly states the action ('End') and the resource ('a kiro-cli session'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'kiro_session_clear', which might have overlapping functionality, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'kiro_session_clear' or 'kiro_session_switch', nor does it mention prerequisites such as needing an active session. This leaves the agent with insufficient context for optimal tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool saves a session to a file, implying a write operation, but doesn't disclose behavioral traits such as whether it overwrites existing files, requires specific permissions, or what happens on failure. The mention of '/save command' adds some context but lacks details on side effects or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse. Every word earns its place by conveying essential information without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations and no output schema, the description is incomplete. It lacks information on what the saved file contains, the format, success/failure responses, or error handling. For a write operation tool with 2 parameters, more context is needed to guide effective use, making it inadequate for the complexity.
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 100%, so the schema fully documents both parameters (session_id and path). The description doesn't add any meaning beyond the schema, such as explaining parameter interactions or usage examples. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.
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 clearly states the action ('Save') and resource ('current kiro-cli session to a file'), making the purpose understandable. It distinguishes from siblings like kiro_session_clear or kiro_session_end by specifying saving rather than clearing or ending. However, it doesn't explicitly differentiate from kiro_session_create or kiro_session_switch, which slightly reduces specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions using '/save command' but doesn't explain when saving is appropriate compared to other session tools like kiro_session_list or kiro_session_clear. There are no explicit when/when-not statements or prerequisites, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Cancel') but doesn't describe what cancellation entails (e.g., whether it's immediate, reversible, affects other tasks, or requires specific permissions). This is a significant gap for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of canceling a running task (a mutation operation) with no annotations and no output schema, the description is incomplete. It lacks details on behavior, side effects, error conditions, or what happens post-cancellation, which are critical for safe and effective use.
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?
The schema description coverage is 100%, with the single parameter 'task_id' clearly documented in the schema. The description doesn't add any meaning beyond what the schema provides (e.g., format examples or sources for task IDs), so it meets the baseline of 3 when the schema does the heavy lifting.
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 clearly states the action ('Cancel') and the target ('a running async task'), which is specific and unambiguous. However, it doesn't explicitly differentiate this tool from its sibling 'kiro_task_list' or 'kiro_task_status', which are related to task management but serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., that the task must be running), exclusions (e.g., tasks that cannot be canceled), or refer to sibling tools like 'kiro_task_status' for checking task state before cancellation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'List active async tasks' implies a read-only operation but doesn't disclose behavioral traits like whether it's safe, if it requires authentication, rate limits, or what 'active' means (e.g., pending vs. running). This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase ('List active async tasks') that is front-loaded and wastes no words. Every element contributes directly to understanding the tool's purpose, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what 'active' entails, how tasks are returned (e.g., format, pagination), or error handling. For a tool with siblings and potential complexity, this leaves significant gaps for an AI agent.
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?
The description adds no parameter semantics beyond what's in the input schema, which has 100% coverage. It doesn't explain the meaning of 'active' in relation to 'include_done' or provide usage examples. With high schema coverage, the baseline is 3, as the schema already documents parameters adequately.
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 'List active async tasks' clearly states the verb ('List') and resource ('active async tasks'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'kiro_task_status' or 'kiro_task_cancel', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'kiro_task_status' and 'kiro_task_cancel' available, there's no indication of whether this is for bulk listing versus specific task operations, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'List' implies a read-only operation, the description doesn't specify what 'available' means (e.g., active vs. all, filtered by permissions), whether results are paginated, what format they return, or any rate limits. For a tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the essential information ('List available custom agents') and doesn't include any unnecessary elaboration. This is an excellent example of concise, effective documentation for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with no output schema, the description provides the minimum viable information about what it does. However, without annotations or output schema, it doesn't address what the return format looks like (e.g., array of agent objects with what properties) or behavioral constraints. It's adequate but leaves gaps that would help an agent use it effectively.
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?
The tool has 0 parameters, and schema description coverage is 100% (though empty). The description appropriately doesn't discuss parameters since none exist. It correctly focuses on the tool's purpose rather than trying to document non-existent inputs, earning a high score for parameter relevance.
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 clearly states the action ('List') and the resource ('available custom agents'), making the purpose immediately understandable. It doesn't explicitly distinguish from siblings like 'kiro_session_list' or 'kiro_task_list', but the specificity of 'custom agents' provides some differentiation. This is a clear, functional description that tells the agent exactly what to expect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'kiro_session_list' and 'kiro_task_list' that also list resources, there's no indication of when 'custom agents' listing is appropriate versus session or task listing. No prerequisites, exclusions, or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a 'Get' operation (implying read-only) and mentions 'performance monitoring' purpose, but doesn't disclose important behavioral traits like whether this requires special permissions, what format the statistics are returned in, if there are rate limits, or if the data is real-time vs cached.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple read operation and front-loads the essential information ('Get process pool statistics').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read operation with no output schema, the description provides basic purpose but lacks important context. It doesn't explain what 'process pool statistics' includes, the return format, or whether this is for system-wide or specific pool monitoring. Given the complexity is low (no parameters) but no output schema exists, more detail about what information is returned would be helpful.
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?
The tool has 0 parameters with 100% schema description coverage. The description appropriately doesn't discuss parameters since none exist. It focuses on what the tool retrieves ('process pool statistics') rather than parameter details, which is correct for a parameterless tool.
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 clearly states the tool's purpose as 'Get process pool statistics for performance monitoring' with a specific verb ('Get') and resource ('process pool statistics'). It distinguishes from siblings by focusing on pool statistics rather than agents, sessions, tasks, or chat functions. However, it doesn't explicitly differentiate from all possible sibling tools in the list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. While 'for performance monitoring' gives some context, it doesn't specify prerequisites, timing considerations, or when to choose this over other monitoring-related tools (though none are explicitly listed in siblings).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions the default directory behavior, it doesn't cover critical aspects like whether this requires specific permissions, what a 'session' entails (e.g., resource usage, persistence), error handling, or what the tool returns. For a creation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, consisting of two concise sentences that directly address the tool's purpose and key parameter behavior. There is no wasted text, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a session creation tool (which likely involves state management and resource allocation), the description is insufficient. With no annotations, no output schema, and minimal behavioral details, it fails to provide complete context for an agent to understand the full implications of invoking this tool, such as what is returned or how sessions interact with other tools.
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 100%, meaning the input schema already documents both parameters ('agent' and 'working_directory') with their descriptions. The description adds marginal value by reinforcing the default behavior for 'working_directory', but doesn't provide additional semantic context beyond what the schema offers, such as examples or edge cases.
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 clearly states the action ('Create') and resource ('new kiro-cli session'), making the purpose understandable. However, it doesn't explicitly differentiate this from sibling tools like 'kiro_session_switch' or 'kiro_session_list', which would require more specific context about what distinguishes session creation from other session operations.
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?
The description provides implied usage context by mentioning the default behavior for 'working_directory' (defaults to current directory if not provided or invalid). However, it lacks explicit guidance on when to use this tool versus alternatives like 'kiro_session_switch' or prerequisites, leaving some ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool lists active sessions but doesn't describe what constitutes an 'active' session, how the list is formatted, whether it includes metadata, or if there are limitations like pagination or rate constraints. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core purpose ('List all active kiro-cli sessions'), making it highly efficient and easy to parse, which is ideal for a tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks details on behavior, output format, or usage context. Without annotations or output schema, more context on what 'active' means or the list structure would improve completeness, but it meets the basic threshold for a simple list tool.
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?
The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it correctly avoids mentioning any inputs, aligning with the empty schema. A baseline of 4 is appropriate as no compensation is needed for missing parameter info.
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 clearly states the action ('List') and resource ('all active kiro-cli sessions'), providing a specific verb+resource combination. It distinguishes from some siblings like 'kiro_session_clear' or 'kiro_session_create' by focusing on listing rather than modifying sessions, though it doesn't explicitly differentiate from 'kiro_session_switch' or 'kiro_session_end' in terms of purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites, timing considerations, or how it differs from sibling tools like 'kiro_task_list' or 'kiro_agents_list', leaving the agent to infer usage context without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the async nature and need for polling, which adds some context, but fails to cover critical aspects: it doesn't specify if this is a read-only or mutating operation, what permissions are required, potential rate limits, error handling, or what the initial response looks like. For an async tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured: two sentences that efficiently convey the tool's purpose and usage. The first sentence explains what it does, and the second provides essential guidance. There is no wasted language, and it's front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (async operation with polling), no annotations, and no output schema, the description is moderately complete. It covers the async nature and polling requirement but lacks details on behavioral traits, error handling, and output expectations. It's adequate as a starting point but has clear gaps for effective agent use.
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?
The input schema has 100% description coverage, with clear documentation for both parameters ('message' and 'session_id'). The description adds no additional parameter semantics beyond what's in the schema. According to the rules, with high schema coverage (>80%), the baseline is 3 even without extra param info in the description.
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 clearly states the tool's purpose: 'Start an async chat task for streaming-like experience.' It specifies the verb ('Start'), resource ('async chat task'), and distinguishes it from the synchronous 'kiro_chat' sibling by emphasizing the async nature. However, it doesn't explicitly contrast with other async-related tools like 'kiro_task_status' beyond mentioning it for polling.
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?
The description provides clear usage guidance: 'Use kiro_task_status to poll for results,' which explicitly directs users to a sibling tool for follow-up actions. It implies this tool initiates a task that requires polling, but it doesn't specify when to use this versus the synchronous 'kiro_chat' or other task-related tools like 'kiro_task_list', leaving some context gaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the destructive behavior ('deletes .kiro/session.json'), which is crucial, but lacks details on permissions needed, error handling, or what happens if the file doesn't exist. It's adequate but leaves gaps in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and resource. Every word earns its place, with no redundant or vague phrasing, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive operation with no annotations and no output schema), the description is minimally complete. It covers the purpose and destructive nature but lacks details on outcomes, errors, or usage context, leaving room for improvement in guiding the agent.
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 description coverage is 100%, so the schema already documents the optional 'session_id' parameter. The description adds no parameter-specific information, but with only one optional parameter, the baseline is high. It implies the tool operates on the working directory, which provides some context beyond the schema.
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?
The description clearly states the specific action ('Clear') and target resource ('kiro-cli session history in working directory'), with explicit mention of the file being deleted ('.kiro/session.json'). It distinguishes from sibling tools like 'kiro_history_clear' by focusing on session history rather than general history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'kiro_history_clear' or 'kiro_session_end', nor does it mention prerequisites or exclusions. It states what the tool does but not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'polling streaming results' and 'incremental updates' (via parameter context), which adds useful context about its iterative nature. However, it doesn't specify rate limits, error handling, or what 'partial results' entail, leaving gaps for a polling tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two short sentences) and front-loaded with the core purpose. Every word earns its place, with no redundant or vague phrasing, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (polling with incremental updates), no annotations, and no output schema, the description is minimally adequate. It covers the purpose and usage but lacks details on return values, error conditions, or completion states, which are important for a polling operation.
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 100%, so the schema fully documents both parameters. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain task ID format or chunk indexing details). This meets the baseline of 3 when the schema handles parameter documentation.
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?
The description clearly states the tool's purpose with specific verbs ('Get status and partial results') and identifies the resource ('async task'). It distinguishes itself from siblings like kiro_chat_async (which creates tasks) and kiro_task_list (which lists tasks) by focusing on polling for ongoing task results.
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?
The description explicitly states when to use this tool ('Use for polling streaming results') and references a specific alternative ('task ID returned by kiro_chat_async'), providing clear context for its application versus other task-related tools like kiro_task_cancel or kiro_task_list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![kiro-cli-mcp MCP server](https://glama.ai/mcp/servers/vanphappi/kiro-cli-mcp/badges/card.svg)](https://glama.ai/mcp/servers/vanphappi/kiro-cli-mcp)

Score Badge

Copy to your README.md:

[![kiro-cli-mcp MCP server](https://glama.ai/mcp/servers/vanphappi/kiro-cli-mcp/badges/score.svg)](https://glama.ai/mcp/servers/vanphappi/kiro-cli-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/vanphappi/kiro-cli-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server