Kawa Code MCP

Official

by kawacode-ai

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v6.8.1
Disambiguation4/5
Tools are mostly distinct, with clear descriptions differentiating similar ones like get_session_decisions and get_project_decisions. However, there is some potential confusion between check_active_intent and get_intent_changes, and between pre_edit_decision_check and pre_edit_acknowledge, though descriptions help.
Naming Consistency4/5
All tool names use snake_case, which is consistent. However, the naming pattern varies: some use verb_noun (e.g., check_active_intent), while others use more complex prefixes like pre_edit_ or arbiter_. This minor inconsistency prevents a perfect score.
Tool Count3/5
25 tools is on the higher end, but the scope of the server—managing intents, decisions, and conflicts—justifies the count. Some tools could be merged (e.g., get_session_decisions and get_project_decisions), but overall the number is reasonable for the domain.
Completeness4/5
The tool surface covers the full lifecycle of intents and decisions, including creation, activation, tracking, conflict detection, and resolution. Minor gaps exist, such as no tool to list all active intents (only team intents), and no direct deletion tool for intents, but these are manageable.
Average 4.3/5 across 25 of 25 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 34 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 Inno Setup 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

Behavior3/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 discloses deprecation and planned removal, but does not describe any other behavioral traits (e.g., what happens when called, side effects, or permissions). The deprecation status itself is a key behavioral disclosure.
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 very concise and front-loaded with the critical deprecation note. Every sentence serves a purpose, and there is no wasted text. It efficiently communicates the key message.
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 deprecated tool, the description is sufficiently complete in telling agents to avoid it. However, it lacks information about the original purpose of log_work, which might be relevant for understanding legacy workflows. Given the deprecation, this is a minor gap.
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 coverage is 100%, so the input schema already documents all parameters. The description adds no additional meaning about parameters, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description focuses on deprecation and instructs not to use the tool, but does not clearly state what the tool originally did. It mentions trivial changes should skip the intent workflow, but the tool's function is implied rather than explicitly described.
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 explicitly states 'Do not call this tool' and provides context for when it is unnecessary (trivial changes). It gives clear guidance to avoid using it, but does not explain when alternatives like other tools should be used.
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, the description carries full burden. It explains server-side filtering and pagination (default 50 per page, limit/offset, count meaning). However, it does not state that the operation is read-only or mention auth/rate 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?
The description is well-structured: a short introductory sentence, bullet points for use cases, then a concise paragraph on filtering/pagination. It is front-loaded and avoids fluff.
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 10 parameters and no output schema, the description covers basic behavior and pagination but lacks details on return format or how to interpret results. Parameters like forkAuthor and workspaceId are mentioned but not fully explained.
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 coverage is 100%, so baseline is 3. The description adds context about server-side filtering and pagination behavior for limit/offset/count, but does not significantly enhance individual parameter meanings 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 'List intents from team members for this repository' with a specific verb and resource. It distinguishes from siblings by focusing on team-wide listing, while other tools deal with creation, activation, or file-specific intents.
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 explicitly lists use cases: 'See what your team is working on', 'Check for potential overlapping work', 'Review the status'. It provides clear context but does not explicitly mention when not to use it or alternatives.
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?
No annotations are provided, so the description carries the full burden. It discloses that decisions are summary-only and mentions related files and constraint violations. However, it does not address performance, authentication, or whether the operation is read-only. This is adequate but not comprehensive.
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 well-structured with bullet points and clear sections. It is front-loaded with the main purpose. While it includes details on return structure, this is helpful given the lack of an output schema. Slightly verbose but efficient.
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 tool with no output schema and 4 parameters, the description covers the return format well, detailing each decision field. It also notes the need for get_decision_detail for full information. Adequately complete.
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. The description adds minimal extra meaning beyond stating that some parameters are auto-resolved. Baseline 3 is appropriate.
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 'Get all decisions recorded for a project across all intents.' It uses a specific verb ('get') and resource ('decisions') with a clear scope, distinguishing it from siblings like get_session_decisions and get_decision_detail.
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 scenarios ('Use this to review the project's decision history') and lists concrete use cases. While it does not explicitly state when not to use or name direct alternatives, the sibling tool names imply differentiation.
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?
No annotations are provided, so the description carries the full burden. It discloses the return values (title, counts, warnings) but does not explicitly state that the tool is read-only or has no side effects—it's implied by 'get'.
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 concise: two paragraphs, no wasted words. The first sentence states the purpose, and the rest provides usage context with an example.
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 4 parameters (1 required, 1 nested) and no output schema, the description covers the return value components well. It could mention that forkAuthor and workspaceId are auto-resolved, but the schema descriptions already hint at that.
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 baseline is 3. The description does not add extra meaning beyond the schema; it only summarizes what the tool returns.
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 uses a specific verb ('Get') and resource ('uncommitted changes... along with active intent info'), clearly distinguishing it from sibling tools like 'check_active_intent' or 'get_intents_for_file'.
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 explicitly states to use this tool 'before prompting the user about committing' and explains the output components, but does not mention when not to use it or alternatives.
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?
No annotations provided, so description carries the burden. It discloses conflict-checking behavior and return of overlap details, but does not explicitly state the tool is read-only or describe side effects like rate limits or permissions.
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?
Concise: two sentences with bullet points. Front-loaded with purpose, then usage guidance. No superfluous words.
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?
No output schema, but description mentions return of overlap details. Explains core use case and behavior well. Lacks detail on output format and edge cases, but sufficient for selective 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?
Schema coverage is 100% with descriptions for all parameters. The description does not add further detail about parameter semantics beyond the schema, meeting the baseline but not exceeding it.
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 retrieves intents for a specific line range, and implies differentiation from sibling tool 'get_intents_for_file' which operates on entire files.
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?
Explicitly states when to use: before modifying lines to check for conflicts. Lists benefits (warns about overlaps, avoids merge conflicts) but does not mention when not to use or compare with alternative conflict-detection tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure. It explains the tool returns peerSnippet, decisions, and a guardrail policy, and explicitly states it is 'advisory and proactive (no lock)' and does not modify state. This provides strong transparency, though it could mention potential side effects or resource usage.
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 front-loaded with purpose and usage, and each sentence contributes meaning. However, it is somewhat lengthy with a bullet list and repeated emphasis on policy; a slightly tighter structure would improve conciseness.
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?
Given the complexity (8 params, nested objects, no output schema), the description covers the tool's trigger, return values, and behavioral policy thoroughly. It lacks explicit output format details but compensates with detailed guardrail instructions and context for agent decision-making.
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% coverage with descriptions for all 8 parameters. The tool description adds context for how the returned guardrail guides parameter usage, but does not significantly enhance individual parameter meanings beyond the schema. Baseline 3 is appropriate.
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 resolves live code collisions with a peer, specifying the verb 'resolve' and the resource 'code collision with a peer'. It contrasts with sibling tools like 'detect_intent_conflicts' and 'arbiter_resolve', making its unique role evident.
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 explicitly tells when to call the tool (when a Stop hook collision report surfaces a live peer) and advises it's proactive and advisory. While it doesn't list alternatives or when not to use, the context is sufficiently clear for an agent to select this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses return value details (author, status, line ranges) and implies read-only behavior. No side effects or contradictions noted. Could mention if the operation is expensive, but adequate for a read 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?
Two paragraphs: first line is the core action, then bullet points for usage. Every sentence adds value—no fluff. Front-loaded with the verb and resource.
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 5-parameter tool with no output schema and no annotations, the description covers the tool's purpose, usage context, and return value. It could add more detail about corner cases, but it's complete for typical 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?
Schema description coverage is 100%, so all parameters are already documented in the schema. The description adds no additional parameter-level semantics beyond the tool's overall purpose. Baseline 3 is appropriate.
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 starts with a clear verb+resource: 'Get all intents that have code blocks in this file.' It distinguishes from sibling 'get_intents_for_lines' by specifying file-level scope. The addition of usage context further clarifies its purpose.
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?
Explicitly says 'Use this before modifying a file' and lists specific scenarios (see work in progress, identify conflicts, understand context). While it does not mention when not to use or compare to alternatives, the guidance is clear and actionable.
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, the description carries full burden for behavioral transparency. It explains that intents are living documents and gives common triggers, but does not disclose side effects, authorization needs, or whether the update is atomic. The description is adequate but lacks depth about error states or confirmation.
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 concise, well-structured, and front-loaded with the core purpose. It includes a brief intro, a paragraph with usage triggers, and a note about intentId. No unnecessary words or redundancy.
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?
Given the tool's straightforward nature (updating fields) and high schema coverage, the description covers the main purpose and usage context. It lacks detail about return values or error handling, but since there is no output schema, and the action is simple, it is reasonably complete.
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 100%, so baseline is 3. The description adds value by explaining that intentId defaults to the active intent and provides rationale for updating intents. However, for most parameters, the schema already describes them well; the description does not add significant new semantics beyond the schema except for the default behavior.
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 verb (update) and resource (intent), lists the updatable fields (title, description, scope, constraints), and distinguishes its purpose as reformulating intents as understanding evolves. This is specific and differentiates it from creation or completion tools.
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 context on when to use the tool: when understanding evolves, with common triggers listed. It also clarifies the behavior when intentId is omitted. However, it does not explicitly mention when not to use it or compare with sibling tools like create_and_activate_intent or complete_intent, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 discloses key behaviors: runs asynchronously, returns immediately with a started/pending status, progress reported separately, and optional persistence via `repoPath`. This adds significant context about the tool's operation beyond a simple function call.
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 well-structured with sections (When to use, Inputs, Behavior) and uses concise bullet-style prose. Every sentence adds value, with no redundancy. It is front-loaded with the key purpose and usage, making it easy to scan.
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 complexity (6 parameters, nested objects, async behavior, no output schema), the description covers purpose, usage, parameters, and behavior well. However, it lacks specification of the output or return value structure. It mentions 'started/pending status' but does not describe what the final result looks like, which is a gap since there is no output schema to compensate.
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 baseline is 3. The description adds meaning beyond the schema: explains that `stories` come from a previous `infer_history` run, `repoPath` triggers persistence, `model` specifies an Anthropic model, and that `forkAuthor`, `repoOrigin`, `workspaceId` are usually auto-resolved. This enriches parameter understanding.
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 starts with a clear verb+resource: 'Curate a set of previously extracted stories so that only the decisions still worth keeping are persisted.' It distinguishes from the sibling tool `infer_history` by noting that it is rarely needed standalone because `infer_history` already chains this step. This makes the tool's purpose specific and differentiated.
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 explicitly states when to use: after `infer_history` in story-only mode or when re-curating pre-existing stories. It mentions that `infer_history` already chains this step automatically, implying the rare case. However, it does not explicitly list when not to use or compare to other sibling tools beyond `infer_history`.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits itself. It explains what the tool surfaces (Tier 1a, Tier 1b), that overridden decisions are filtered out, the recommendation mapping, and the return of the smallest enclosing function symbol (with language limitations). It does not detail side effects or performance, but the read-only nature is implied. Sufficient transparency for an agent.
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 well-structured with front-loaded purpose and separate paragraphs for tiers, filtering, recommendation mapping, and extra return value. While somewhat verbose, each sentence adds necessary detail. Minor room for tightening, but overall efficient for the complexity.
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?
Despite lacking an output schema, the description adequately conveys the return value (recommendation with actions and a function symbol). It covers when to use, what data is surfaced, and filtering logic. For a 9-parameter tool with nested objects, this is sufficient for an agent to invoke and interpret results.
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 100%, so baseline is 3. The description adds value by explaining that intentId is auto-detected, and that forkAuthor, workspaceId, and sessionToken are usually auto-resolved. It also clarifies that repoPath is used to read the file for AST symbol detection. This goes beyond the schema descriptions.
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 what the tool does: 'Check whether the line range about to be edited has prior recorded reasoning attached.' It details two tiers of surfaced context (Tier 1a and Tier 1b), explains what is no longer reported, and maps recommendations to actions. This is highly specific and distinguishes it from sibling tools like pre_edit_acknowledge or get_resolution_context.
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 explicitly says 'Call this BEFORE editing code in a kawa-indexed repo,' providing clear usage context. It also notes that live-collaborator awareness is handled elsewhere, implicitly guiding when not to rely on this tool for collisions. However, it does not explicitly list alternative tools for other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description covers key behavioral traits: additive only, skips already assigned intents, runs in Kawa Code desktop app, returns feature count. Could mention reversibility or permissions but sufficient.
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?
Description is concise and well-structured: purpose first, then usage, then behavior bullets. No wasted words, every sentence adds value.
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?
Given one parameter and no output schema, description provides all needed information: what it does, when to use, behavioral details, and return value. Complete.
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?
Only parameter repoPath has full schema coverage. Description does not add extra meaning beyond schema's 'Local path to the repository root'. Baseline of 3 is appropriate.
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?
Description clearly states it updates the project's feature catalog from recorded intents. It specifies the additive nature and contrasts with other tools by focusing on feature catalog updates.
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?
Provides explicit 'When to use' section with two specific scenarios. Lacks explicit when-not-to-use or alternative tools, but context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that only ephemeral session decisions are editable and that synced decisions are immutable. Notes that forkAuthor and workspaceId are auto-resolved. Could add more on side effects or reversibility, but given no annotations, it's strong.
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?
Very concise: a one-line summary, bulleted actions, a constraint sentence, and a purpose sentence. No wasted words, well organized.
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 mutation tool with no output schema, the description adequately covers purpose, usage constraints, and parameter context. Slightly incomplete in not describing return values, but overall sufficient for correct invocation.
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 baseline is 3. Description adds value by noting auto-resolution for forkAuthor and workspaceId and clarifying actions, but doesn't elaborate on updates fields beyond 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 'Edit or delete a decision in the current session.' It distinguishes from sibling tools like record_decision (create) and get_session_decisions (read) by specifying this is for reviewing before commit.
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?
Explicitly states when to use ('when reviewing decisions before commit'), provides the two actions (update/delete), and explicitly warns that synced decisions are immutable, directing to use record_decision with supersedes instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that decisions are 'summary-only' and that they can be edited or removed via other tools (implying mutability). It does not mention side effects or permissions, but for a read-only retrieval tool, the disclosure is sufficient.
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 very concise: three clear sections (purpose, usage, return format). Bullet points are used for returns. Every sentence adds value with no redundancy.
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?
Given 5 parameters, 2 required, no output schema, the description covers the return structure (intentId, decisions, count) and notes that decisions are summary-only. It provides enough context for correct invocation and interpretation of results, though a note on optional parameters like forkAuthor would be nice but not essential.
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 coverage is 100% (all 5 parameters have descriptions in the schema). The tool description does not add any additional parameter meaning beyond the schema. Baseline is 3, and no extra value is provided.
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 starts with a clear verb-resource pair: 'Get all decisions recorded in the current session for an intent.' This distinguishes it from siblings like get_decision_detail (full decision) and record_decision (create). It precisely identifies what is retrieved and the scope.
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?
Explicitly states when to use: 'Use this before committing to review what decisions were captured during development.' Also tells when not to use alternatives: for full rationale, call get_decision_detail. This provides clear decision-making guidance for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses silent recording, accumulation behavior, and constraintViolations requirement. Does not cover auth, rate limits, or detailed side effects.
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?
Well-structured with bullet points and sections. Front-loaded purpose. Slightly verbose but every sentence adds value; could be tightened.
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?
Given 21 parameters and no output schema, description fully explains workflow, decision types, scoping, and important usage notes. Feels complete for the tool's purpose.
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?
100% schema coverage so baseline 3. Description adds value by highlighting key param guidance (omit intentId for repo-scoped, include constraintViolations) beyond schema descriptions.
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?
Clearly states 'Silently record a decision point during development' with specific verb and resource. Lists exact decision types and distinguishes from read/edit siblings like get_session_decisions.
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?
Explicit conditions for calling (fork, abandoned, discovery, etc.) and scoping rules (intent-scoped vs repo-scoped). Lacks explicit when-not-to-use or comparisons to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavior: returns intent/hasActiveIntent and activeIntents, explains status semantics (active vs terminal states), and describes the multi-active model. It implies no side effects (read-only check) and details response composition.
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 well-structured with a bolded requirement, bullet points, and sections. It is informative but slightly lengthy; however, every sentence contributes value. Some minor redundancy could be trimmed, but overall efficient.
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?
Given no output schema, the description covers the return shape (intent, hasActiveIntent, activeIntents) and status semantics. It could be more explicit about the full structure of the intent object, but provides enough for an agent to use effectively.
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 coverage is 100% with adequate descriptions for each parameter. The tool description itself does not add further parameter semantics beyond the schema, so baseline 3 is appropriate. Nested object forkAuthor is described sufficiently in 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 tool returns the current session's active intent, with explicit verb 'Returns' and resource 'session's current intent'. It distinguishes from siblings by mentioning 'PER SESSION' and referencing create_and_activate_intent for when no intent exists.
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?
Starts with 'REQUIRED: Call this tool BEFORE writing any code', providing a clear when-to-use directive. It also instructs to call create_and_activate_intent if no active intent, explicitly guiding the agent on next steps. The multi-active model explanation further clarifies context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It explains the tool finds and returns scored conflict candidates with specific fields, and notes the list is informational. This sets appropriate expectations. It does not explicitly state whether it modifies data, but given the purpose, it is clearly read-only. Minor improvement could be an explicit read-only hint.
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 well-organized with a clear summary, 'When to use' section, 'Inputs of note', 'Returns' section with bulleted fields, and a closing note. Every sentence adds value with no redundancy. It is concise yet comprehensive.
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?
Given the complexity (6 parameters, no output schema, nested objects), the description covers all essential aspects: tool purpose, appropriate usage scenario, key inputs with rationale, and the structure of the return value. It fits well among sibling tools without gaps. No further detail is needed for typical use.
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 baseline is 3. The description adds value by highlighting intentId and minScore with contextual explanations beyond the schema ('the active intent to check against', 'minimum match score to include in results'). For other parameters (repoPath, forkAuthor, etc.), the schema descriptions suffice. This extra context for key parameters justifies a 4.
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 uses specific verb 'find' and resource 'conflicting intents' from other team members against the active intent. It clearly distinguishes from sibling tools like list_team_intents (which lists all team intents) and get_intents_for_file (by file), making the tool's unique purpose immediately clear.
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 explicitly states 'When to use: Before committing, to surface overlapping team work so the user can coordinate before merging.' This provides clear situational guidance. While it doesn't list explicit alternatives or exclusions, the use case is well-defined and implies when not to use (e.g., when only listing intents). Could include more explicit 'when not to use' but still strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses return types (relevantIntents, relevantDecisions), notes that decisions are summary-only, and suggests get_decision_detail for full rationale. It does not mention auth or read-only nature, but the tool is clearly non-destructive.
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 well-structured with sections: main purpose, when to use, inputs of note, returns, recommended sequence. It is front-loaded with the core purpose, and every sentence adds value without redundancy.
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?
Given 9 parameters, 100% schema coverage, no output schema, the description explains return values and usage sequence. It provides enough context for an agent to decide when and how to use the tool, including prerequisites and follow-up steps.
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 100%, baseline 3. The description adds value by explaining the purpose of key parameters: prompt (paraphrase allowed), activeFiles (improves relevance), maxIntents/maxDecisions/minRelevance (result-shaping), and forkAuthor/workspaceId (auto-resolved). This helps the agent use parameters correctly.
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 'Find past intents and decisions relevant to the current user request.' It uses specific verb-resource, and distinguishes from sibling tools like get_intents_for_file by returning both intents and decisions, and by being task-specific.
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 explicitly provides 'When to use' conditions, advising against vague prompts and recommending use after initial exploration. It also gives a preferred use case for large projects. However, it does not explicitly name sibling tools as alternatives or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses in-memory cache, reset on server exit, silent dedup, and return values (acknowledged count, cacheSize). Could mention error cases or side effects more explicitly.
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?
Description is front-loaded with purpose, then usage, then behavior, then returns. Some redundancy (e.g., 'the rest of this session' appears twice), but overall each section serves a purpose. Could be slightly shortened.
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?
Given no output schema, description explains return values. Covers lifecycle, dedup behavior, and session scoping. Missing details on error handling (e.g., invalid decision IDs) and if there are any side effects.
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 100%, baseline 3. Description adds context: repoPath enables repo attribution, forkAuthor and workspaceId auto-resolved, sessionToken defaults to SESSION_ID. This adds value 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 tool's purpose: 'Mark decisions as consciously overridden for the rest of this session.' It specifies the context (Phase 3 PreToolUse hook) and differentiates from sibling tools like pre_edit_decision_check and record_decision.
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?
Explicitly says when to use: 'when the agent passes force: true on an Edit tool call to bypass a pre_edit_decision_check block.' Also provides an alternative: 'For persistent override across sessions, record a fork decision via record_decision(type: "fork", supersedes: [<id>]) instead.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully explains the conditional write behavior (trivial tier, agent-owned worktree), records decisions, and warns about file changes. It could add authorization or rate-limit details, but current coverage is strong.
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 front-loaded with the key action and uses bullet-like structure for outcomes. It is slightly lengthy but each sentence adds value, so it remains clear and efficient.
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?
Given the complexity (6 params, nested objects, no output schema), the description covers conditional behavior, return format, and post-invocation steps. It is comprehensive for an AI agent to select and use the tool correctly.
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 100%, but the description adds meaning: it explains that overlaps come from the Stop collision report, and that forkAuthor and workspaceId are usually auto-resolved. This supplements the schema effectively.
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 verb 'Resolve' and resource 'live code overlaps', specifies the auto-apply behavior for the trivial tier, and distinguishes it from arbiter_resolve by detailing when it writes vs. suggests.
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 gives explicit guidance: 'Call it when you are ready to incorporate the result' and instructs to re-read applied files. It also directs users to get_resolution_context for unapplied overlaps, providing clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 thoroughly explains the tool's actions: updating status, storing commit SHA, clearing the active intent. It details three possible response outcomes (success, transient failure, deferred conflicts) and instructs the agent on how to respond to each. This is exemplary transparency.
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 lengthy but well-structured with clear sections, bullet points for outcomes, and front-loaded purpose. While it could be more concise, every sentence adds necessary detail for correct tool invocation. The organization aids readability despite the length.
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?
Given the complexity (9 parameters, nested objects, no output schema), the description is remarkably complete. It covers all aspects: tool action, parameter usage, response handling, edge cases (transient failures, deferred conflicts), and even provides scripts for the agent to follow. This fully compensates for the lack of output schema and ensures the agent can use the tool correctly.
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?
All parameters are described in the schema (100% coverage), so the description's added value is in explaining parameter interactions and conditional usage (e.g., 'supersededBy' required when status is 'superseded', 'humanApproved' only for cross-author intents). This enhances understanding beyond schema definitions, justifying a score above baseline 3.
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: 'Mark the active intent as completed and clear it.' It specifies the verb ('complete') and resource ('active intent'), and distinguishes from sibling tools like 'update_intent' by focusing on completion and clearing. The description also provides concrete use cases (after git commit) and lists status values, making it highly specific.
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 extensive usage context, including when to call (after successful git commit) and detailed response handling for different outcomes. It also explains status values and when to use parameters like 'humanApproved'. However, it does not explicitly state when NOT to use this tool or name direct alternatives, which is a minor gap. Still, the guidance is thorough and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses key behaviors: accepts cloud IDs and local UUIDs, multi-active model (no blocking), and transparent restoration of soft-deleted decisions for abandoned intents. This exceeds typical description detail and prevents misuse.
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?
Description is well-structured with section headers (Use this to, Accepts both, Multi-active, Resuming abandoned) and front-loaded main sentence. While slightly long, each section adds essential information without redundancy. Could be slightly more concise, but structure compensates.
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?
Given 5 parameters (2 required, nested objects) and no output schema, the description adequately covers activation behavior, multi-active semantics, and abandoned intent handling. It does not describe the return value, but for a mutation tool this is acceptable. The explanation of edge cases (abandoned intents) adds completeness.
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 100%, but description adds value beyond schema by explaining the dual ID acceptance and auto-resolution behavior for forkAuthor and workspaceId ('usually resolved by Muninn automatically'). This context helps agents decide when to provide overrides.
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?
Description clearly states 'Activate an existing intent by ID — sets it as THIS session's current focus.' It specifies the verb (activate), resource (intent), and scope (existing, by ID, session-specific). It distinguishes from siblings like create_and_activate_intent and check_active_intent, making the purpose unambiguous.
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?
Provides explicit use cases: switch focus, re-activate deactivated, resume work, resume abandoned. Also explains the multi-active model (no locks, only session pointer moves) and when to use alternative tools (e.g., list_team_intents to find intents). This gives clear when-to and when-not-to guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses safety (SUGGEST-ONLY, never writes), zero-knowledge decryption, and output details (compatible/auto_resolvable/conflict, confidence, perf/security risk, tier). No annotations exist, so description carries full burden. Minor gap: no mention of auth or rate limits, but detailed enough.
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 dense but well-structured, front-loading the key purpose and safety guarantee. It efficiently explains input, output, and usage flow without wasted words.
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?
Given 6 parameters, nested objects, and no output schema, the description comprehensively explains inputs, output fields, and workflow integration. Slightly missing explicit response format, but output details are described inline.
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 100% with descriptions for all 6 parameters. The description adds context beyond schema: intentId is advisory/auto-detected, overlaps format from Stop report, forkAuthor and workspaceId typically auto-resolved. This significantly aids parameter understanding.
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 'Get Kawa Code's AI verdict for live code overlaps with peers — SUGGEST-ONLY, never writes.' It identifies the specific verb (get verdict) and resource (overlaps), and distinguishes from sibling tools like arbiter_apply and get_resolution_context.
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 says 'Use it to understand a forming conflict before acting.' and directs when to use alternatives: 'For a surfaced tier-2/3 overlap, call get_resolution_context... To actually apply the safe tier, use arbiter_apply.' This provides clear when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the return fields (rationale, context, etc.) and the 'found: false' case. It implies higher cost than recall surfaces, adding valuable behavioral context. Lacks explicit read-only statement but 'get' implies it.
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?
Description is concise, well-structured, and front-loaded. First sentence states purpose, followed by usage guidance, input list, and return details. No waste—every sentence earns its place.
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?
Given no output schema, description fully explains return values. It covers purpose, usage, parameters (key one detailed), return fields, and error case. For a simple read tool with moderate complexity, it is complete.
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 has 100% description coverage, baseline 3. Description adds important context for decisionId (source from recall result), which surpasses baseline. Other params are not elaborated in description but are clear in 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 explicitly states 'Expand one decision to its full detail' with a specific verb and resource. It distinguishes from sibling tools by contrasting with recall surfaces that return summaries only.
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 clearly states when to use this tool (after getting summaries from recall surfaces) and when not to (when summary suffices). It names specific alternative tools (get_relevant_context, get_project_decisions, get_session_decisions).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully discloses async behavior, persistence, resume logic, re-run guard with force, and forge detection. Covers edge cases like non-default branches.
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?
Well-structured with sections, but somewhat lengthy. Every sentence earns its place, but could be tightened.
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?
Given 9 parameters and no output schema, description comprehensively covers interactions, async behavior, error states, and re-run logic. Highly complete.
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?
Adds significant value beyond 100% schema coverage—explains mutual exclusivity of commits/commitRange, defaults, and usage context for each parameter.
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?
Clearly states it analyzes git commit history to produce structured intents/decisions. Distinguishes from sibling tools that manage intents/decisions but don't infer them from history.
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?
Explicitly states when to use: bootstrap repos or extend coverage. Provides context on default branch and force flag, but could mention alternative tools more directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description thoroughly explains the multi-active model, no lock conflicts, conflict detection behavior, and the effect of force parameter. No contradictions.
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?
Well-structured and concise. Front-loaded with purpose and when-to-use, then details on multi-active model and conflict handling. Each sentence is informative.
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 main workflow, conflict handling, and parameter explanations. No output schema, so return info is not expected. Some minor details like the exact return behavior on success could be added, but overall complete for a tool with 9 params.
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 100% so baseline is 3. Description adds context for force (after conflict review), auto-detection for repoOrigin and workspaceId, and explains forkAuthor and workspaceId as override/testing. Adds significant value beyond 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?
Clearly states the tool creates an intent and activates it for the current session. Distinguishes from sibling tools like check_active_intent and activate_intent by describing the workflow.
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?
Explicitly states when to call (after check_active_intent returns none), prerequisite steps (summarize, get user confirmation), and how to handle conflicts (present to user, retry with force). Also addresses multi-active model.
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:

[![kawa.mcp MCP server](https://glama.ai/mcp/servers/kawacode-ai/kawa.mcp/badges/card.svg)](https://glama.ai/mcp/servers/kawacode-ai/kawa.mcp)

Score Badge

Copy to your README.md:

[![kawa.mcp MCP server](https://glama.ai/mcp/servers/kawacode-ai/kawa.mcp/badges/score.svg)](https://glama.ai/mcp/servers/kawacode-ai/kawa.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/kawacode-ai/kawa.mcp'

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