Kawa Code MCP

Server Quality Checklist

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

Latest release: v6.9.0
Disambiguation3/5
Several tools have overlapping purposes, such as get_intents_for_file and get_intents_for_lines, get_session_decisions and get_project_decisions, and detect_intent_conflicts and pre_edit_decision_check. However, the descriptions generally clarify the specific use cases, reducing ambiguity.
Naming Consistency4/5
Tool names follow a consistent snake_case convention with verb prefixes (get_, check_, create_, etc.), but there are some inconsistencies like 'check_active_intent' vs 'get_intents_for_file' and 'list_team_intents' vs 'get_intent_changes'. Overall pattern is predictable.
Tool Count3/5
With 25 tools, the set is on the higher end but still appropriate for the server's broad scope covering intent management, decision recording, conflict detection, history inference, and collaboration. Each tool serves a distinct purpose, though some could be consolidated.
Completeness4/5
The tool set covers the full lifecycle of intents (create, activate, update, complete), decision recording and retrieval, conflict detection, history inference, and feature updates. Minor gaps (e.g., no explicit delete intent tool) but overall comprehensive.
Average 4.4/5 across 25 of 25 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 56 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?
With no annotations, the description discloses behavioral traits such as warning about overlaps and returning details. However, it does not state that the tool is read-only or describe other behavioral aspects like authentication needs or 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at 5 sentences and front-loaded with the purpose. However, it contains some redundancy (e.g., overlap warnings repeated) and could be more terse.
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?
No output schema, but description explains the tool checks conflicts and returns overlap details. It does not cover behaviors like empty results, permissions, or error scenarios, leaving some gaps.
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 no additional meaning beyond what the schema provides, so baseline 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 'Get intents covering a specific line range', which is a specific verb+resource. It differentiates from the sibling tool 'get_intents_for_file' by focusing on a line range, though not explicitly naming the alternative.
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 advises 'Use this before modifying specific lines to check for conflicts', providing clear context and recommended usage. However, it does not specify when not to use or mention alternative tools explicitly.
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, the description should disclose behavioral traits like mutation, merging behavior, return value, and permissions. It only states 'update' without detailing whether fields are overwritten or merged, or what the response looks like.
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 with two front-loaded paragraphs. The first sentence captures the action and fields, and the examples are relevant. No redundant text.
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 9 parameters, nested objects, and no output schema, the description lacks details on return values, error handling, and update semantics. It does not fully compensate for the missing output schema.
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 3. The description adds minimal extra semantics beyond the schema, mainly repeating the fields and the default behavior for intentId. The rationale for updating is helpful but not parameter-specific.
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 updates an active intent's title, description, scope, or constraints. It distinguishes itself from sibling tools like create_and_activate_intent and activate_intent by emphasizing reformulation of existing 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 provides explicit triggers for reformulation and notes that omitting intentId updates the active intent. However, it does not explicitly state when not to use this tool, such as for creating or activating intents.
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 burden. It states the function is to 'Get' intents, implying a read-only operation, but doesn't explicitly declare it as non-destructive or disclose any side effects, auth needs, or rate limits. The description adds moderate value beyond the tool name.
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 with a clear front-loaded purpose statement, followed by a bullet list of use cases. Every sentence adds value with no redundancy or fluff.
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 5 parameters and no output schema, the description adequately covers purpose and use cases. It partially compensates for lack of output schema by listing return fields (author, status, line ranges). However, it could be more complete about which parameters are required vs. optional, but schema covers 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 input schema already documents all five parameters. The description does not add any additional explanation or context for individual parameters, leaving it at baseline.
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 intents that have code blocks in this file,' using a specific verb and resource. This distinguishes it from siblings like 'get_intents_for_lines' which targets specific lines, not the whole 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 advises to use before modifying a file, listing three specific use cases (see progress, identify conflicts, understand context). While it doesn't cover when to avoid or mention alternative tools, the context 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description provides key behavioral details: it runs asynchronously, returns immediately with a started/pending status, and optionally persists results when repoPath is provided. This adds significant context beyond the schema.
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 clear sections for usage, inputs, and behavior. It is concise without being overly terse, though the first sentence could be slightly more direct.
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 complexity (6 params, nested objects, async behavior, no output schema), the description covers the essential context: when to use, inputs, and asynchronous nature. It could elaborate on how progress is reported, but overall it is sufficiently 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 baseline is 3. The description repeats the purpose of stories and optional parameters but does not add new meaning beyond what's in the schema. The information about auto-persist with repoPath is already present in the schema's description.
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+resource: 'curate a set of previously extracted stories so that only the decisions still worth keeping are persisted.' It clearly distinguishes itself from sibling tools like infer_history and record_decision by focusing on re-curation after initial extraction.
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 'When to use' section explicitly states scenarios: after infer_history in story-only mode or when re-curating existing stories without re-running history extraction. It lacks explicit 'when not to use' or alternatives, but the 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?
With no annotations, the description covers session cache behavior, reset on server exit, dedup behavior, and return values. It could be more explicit about idempotency but is sufficiently transparent.
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: purpose, context, behavior, returns. It is slightly longer than necessary but each sentence adds value.
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 adequately explains return values. It covers session token defaults and nested parameter (forkAuthor). Could mention that decisionIds is required, but context is clear.
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 minimal parameter semantics beyond the schema, though it explains return values which are not in the input 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 the tool 'marks decisions as consciously overridden for the rest of this session' and differentiates from sibling tools like 'pre_edit_decision_check' and 'record_decision' by explaining the session cache and persistent alternatives.
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?
It explains when the tool is used (when force:true bypasses a block) and provides an alternative for persistent override (record_decision), but does not explicitly state when not to use it.
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 that decisions are summary-only and can be edited/removed before persistence. Implies read-only operation (get), but could be more explicit about side-effects (none).
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: one sentence for purpose, one for usage context, then bullet-like return format. Every sentence adds value. No fluff.
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 no output schema, description fully specifies return fields (intentId, decisions summary, count). Points to get_decision_detail for full details. Adequate for the tool's complexity, though decisions array structure could be described slightly more.
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. Description does not add meaning beyond the input schema for parameters; focuses on output structure and relationships to other tools. No extra parameter guidance 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?
Clearly states 'Get all decisions recorded in the current session for an intent.' Distinguishes from siblings like get_project_decisions (broader scope) and get_decision_detail (single decision details) by specifying session and summary nature.
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 committing to review what decisions were captured during development.' This gives clear context. Could further contrast with alternatives like get_project_decisions or log_work, but current guidance is sufficient.
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 explains that the tool returns scored conflict candidates with specific fields, that the list is informational, and that review is needed. This gives a good understanding of the tool's read-only nature and expected 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 well-structured with clear sections: main purpose, when to use, inputs of note, and returns. Each sentence contributes meaning, and the key information is front-loaded. No unnecessary 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 the tool has 6 parameters, no output schema, and no annotations, the description provides a solid overview. It explains the most important parameters and the output format. It could be more complete by mentioning all parameters, but the essential information is covered.
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 baseline is 3. The description adds value by explaining the intentId and minScore parameters with additional context, as well as describing the return fields. Although not all parameters are detailed, the description enhances understanding 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 finds intents from other team members that potentially conflict with the active intent. It uses specific verbs and resources (find, conflicting intents), and distinguishes itself from siblings like list_team_intents or check_active_intent by focusing on conflict detection.
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 the tool: 'Before committing, to surface overlapping team work so the user can coordinate before merging.' While it doesn't mention when not to use or provide alternatives, the context is clear and sufficient 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?
With no annotations, the description carries full burden. It discloses the output fields, that `found: false` occurs when unknown, and that some parameters are auto-resolved. 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?
The description is well-structured: purpose sentence, usage context, input explanation, output explanation. Every sentence is necessary and no 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?
Covers inputs, outputs, and usage context. Missing potential error conditions but sufficient for a detail retrieval tool. No output schema, so description explains return fields adequately.
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 specifying that `decisionId` comes from a recall result and that `forkAuthor`, `repoOrigin`, `workspaceId` are usually auto-resolved, going 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: 'Expand one decision to its full detail.' It uses a specific verb (expand) and resource (decision), and distinguishes from sibling tools that return summaries.
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 explains when to use: after getting a summary from recall surfaces, and to 'pay for detail only where you ask for it.' It contrasts with recall tools that return summaries-only, providing clear usage 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 provided, so description bears full responsibility. It discloses output details (active intent title/description, file counts, warnings) and implies a read-only operation ('get'). It does not discuss permissions or side effects, but the verb 'get' and the output description make the behavior clear. A minor gap is the lack of explicit read-only declaration.
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: a single-sentence purpose, followed by a structured list of what to expect, and a concrete example. Every sentence adds value, and the structure is front-loaded.
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, so description must explain return values. It does so adequately by listing active intent info, file counts, and warnings. It also provides usage context. However, it omits potential error conditions (e.g., if repoPath is invalid) and assumes git availability. Given the tool's simplicity, 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 description coverage is 100% (all 4 parameters have descriptions). The description adds value by explaining the purpose of the tool (retrieving uncommitted changes and intent info) but does not enhance parameter semantics 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 'Get uncommitted changes in the repository along with the active intent info', specifying the verb (get) and resource (uncommitted changes + intent info). This distinguishes it from siblings like check_active_intent (which only checks active intent) and get_intents_for_file (which focuses on 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this tool before prompting the user about committing' and provides a concrete example of how to construct a commit prompt. This gives clear when-to-use guidance and hints at alternatives (e.g., not for other contexts).
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 carries full behavioral disclosure. It explains server-side filtering and pagination (default 50 per page), the meaning of the 'count' field, and that parameters like forkAuthor are auto-resolved. While it doesn't describe all behaviors (e.g., ordering), it adds significant context beyond the schema.
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 and front-loaded with the main purpose, followed by bullet points for use cases and key behavioral details. 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 the complexity (10 parameters, no output schema), the description adequately covers the tool's functionality, filtering, pagination, and the meaning of the count field. It does not describe the full output structure but is sufficient for an AI agent to use the tool 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?
Schema coverage is 100% with good parameter descriptions. The description adds extra value by specifying the default limit value (50), the ISO8601 format for date filters, and noting that forkAuthor and workspaceId are auto-resolved. This goes beyond the schema's information.
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 specific use cases like checking overlapping work and reviewing status. It distinguishes itself from siblings by focusing on team-wide intents, not file-specific or intent-specific actions.
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 the tool with three bullet-point scenarios. However, it does not mention when not to use it or direct users to alternative sibling tools like get_intents_for_file or get_intents_for_lines, which would be helpful.
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 details the return values (peerSnippet, decisions, guardrail) and lists behavioral policies (advisory, no lock). While it doesn't explicitly state side effects or idempotency, the description is sufficiently transparent about the tool's non-mutating, advisory nature.
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: it starts with a one-line purpose, then a usage condition, followed by bullet points for return values and guardrail rules. Although some redundancy exists (e.g., repeating 'advisory'), it is organized and front-loaded.
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 complexity (8 parameters, nested objects, no output schema) and rich context of sibling tools, the description covers the essential aspects: when to call, what it returns, and behavioral policies. It lacks an explicit return type description, but the narrative explains the return fields. Overall, it is sufficiently complete for an AI agent to 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 have descriptions in the input schema (100% coverage). The tool description adds contextual meaning beyond the schema, e.g., explaining that peerUid comes from a collision report, and that ranges are overlapping line ranges. It also clarifies optional parameters like forkAuthor and workspaceId, stating they are usually auto-detected.
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: to resolve a live code collision with a peer before writing. It specifies the triggering condition (Stop hook collision report) and the outcome (peer snippet, decisions, guardrail). This distinguishes it from sibling tools like arbiter_resolve or 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?
The description explicitly states when to call the tool: when a collision report surfaces a live peer. It also provides clear prohibitions (never overwrite committed work, stay in own working tree) and references related tools (record_decision). This gives unambiguous guidance on usage and alternatives.
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?
While annotations are absent, the description transparently communicates the tool's deprecated status and that it will be removed. It does not detail behavioral traits like side effects, but for a deprecated tool, the clear warning and backwards-compatibility note are 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 concise with just three short sentences. It is front-loaded with the deprecation warning and clear instructions, making it easy to parse.
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?
For a deprecated tool, the description covers everything needed: it states deprecation, provides examples of trivial changes, instructs to not use it, and mentions backwards compatibility and future removal. No output schema exists, but the explanation is self-contained.
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 does not add any parameter-specific meaning beyond what the input schema already provides. Since schema coverage is 100%, the 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?
The description explicitly states the tool is deprecated for logging work in an intent workflow, and it clearly defines its purpose by indicating what trivial changes should do instead. The 'DEPRECATED' label and the instruction to skip the intent workflow make the purpose unmistakable.
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 provides explicit guidance: 'Do not call this tool.' It explains when not to use it—for trivial changes—and offers an alternative workflow (make and commit without intent). This is exceptionally clear.
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 behavior: surfaces Tier 1a and 1b, filters overridden decisions, returns recommendation, and provides enclosing function symbol (with language limitations). All key traits are transparent.
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?
Front-loaded with main purpose, uses bullet points for clarity. Slightly verbose but every sentence adds value. Could be tightened slightly without losing meaning.
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 complexity (9 params, nested objects, no output schema), description adequately covers return behavior and recommendations. Missing structured output schema is partially mitigated by textual description. Good overall 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%, so baseline is 3. Description adds value by noting auto-detection for intentId, repoOrigin, forkAuthor, workspaceId, and sessionToken defaults. This context aids correct usage beyond schema definitions.
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 verb ('Check whether... has prior recorded reasoning attached') and specific resource ('line range about to be edited'). Differentiates from siblings by specifying it's a pre-edit semantic decision check, not a generic intent query.
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 'Call this BEFORE editing code' and mentions what is no longer covered (live-collaborator collisions). Provides recommendation mapping for actions. However, does not explicitly contrast with alternatives like get_intents_for_lines or when to skip this tool.
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, the description fully discloses behavior: additive only, no deletions, skips assigned intents, runs in desktop app, and returns feature count.
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 and well-structured with clear sections (main purpose, When to use, Behavior). 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?
For a single-parameter tool with no output schema, the description adequately explains the function, behavior, and return value (feature count), making it 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 coverage is 100% so schema fully defines the parameter; description adds no extra semantic detail about the path parameter beyond what's in 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 it updates the feature catalog from intents in an additive manner, and explicitly distinguishes it from sibling tools like update_intent by focusing on features rather than 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?
Provides explicit 'When to use' scenarios (after recording/completing intents or on demand), but does not explicitly state when not to use or suggest alternatives, 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 provided, so description carries burden. States read-only ('never writes'), zero-knowledge decryption, output categories (compatible/auto_resolvable/conflict) with confidence, risk read, and tier. Does not cover error handling or authentication, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph, front-loaded with purpose. All sentences add information, though slightly verbose. Good structure overall.
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?
No output schema, but description explains return categories and tier system. Covers prerequisites and relationships to sibling tools. Complete for understanding the tool's role.
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 100% gives baseline 3. Description adds value by explaining overlaps come from Stop collision report, details each field, and notes that forkAuthor and workspaceId are auto-detected unless overridden.
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 verb 'Get' and resource 'AI verdict for live code overlaps', specifies it is SUGGEST-ONLY, never writes. Differentiates from sibling tools like get_resolution_context and arbiter_apply.
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: 'Use it to understand a forming conflict before acting.' Also provides when to use alternatives: for tier-2/3 overlaps, use get_resolution_context; to apply, use arbiter_apply.
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 are provided, so the description carries full responsibility. It fully discloses the per-session model, the multi-active support, and the status semantics. It explains the difference between 'hasActiveIntent' (session-specific) and 'activeIntents' (repo-wide). This level of detail compensates for the lack of annotations.
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 logical sections (requirement, return value, model explanation, status semantics). It front-loads the critical call-to-action. However, it is somewhat lengthy for a read-only check tool; some detail about status semantics could be omitted or moved. Still, every sentence serves a purpose.
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 absence of an output schema and the complexity of the multi-active model, the description thoroughly covers the return values ('intent', 'activeIntents'), the status lifecycle, and behavioral nuances. It leaves no obvious gaps for an agent to misunderstand how to use the tool or interpret its results.
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 adds minimal extra value for parameters: it clarifies that 'forkAuthor' and 'workspaceId' are automatically resolved and need override only for testing. This is helpful but not essential, keeping the score at baseline.
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 primary function: 'Returns THIS session's current intent'. It uses specific verbs ('check', 'returns') and distinguishes itself from siblings like 'create_and_activate_intent' by specifying the prerequisite nature. The tool's role in the intent life cycle is explicit.
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 starts with 'REQUIRED: Call this tool BEFORE writing any code.' It provides explicit guidance on when to use it (before all coding) and when to fall back to 'create_and_activate_intent'. This leaves no ambiguity about the tool's invocation context and 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?
No annotations provided, so description carries full burden. It details outcomes (success, transient failure, deferred conflicts, collisions) and how to handle each. Highly transparent.
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?
Long but well-structured with numbered outcomes and status list. Front-loaded with core purpose. Could be slightly more concise but still effective.
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, no output schema, and complex error handling, the description covers all major behaviors, error states, and response processing. Describes response fields adequately.
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 meaning by explaining status usage, intentId cross-author behavior, and humanApproved policy.
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 marks an intent as completed and clears it. It specifies the verb, resource, and context ('after successful git commit'), distinguishing it from siblings like update_intent or create_and_activate_intent.
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 (after git commit) and lists status values with meanings. Does not explicitly compare to alternatives 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?
With no annotations, the description fully discloses that only ephemeral decisions are editable and synced ones are immutable. It describes the two actions (update/delete) but lacks details on side effects like confirmations or reversibility. Nonetheless, it provides sufficient behavioral context for an AI agent.
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 with only three short paragraphs and bullet points. No unnecessary sentences; each part adds meaning. Structure is front-loaded with the core purpose, followed by usage details and constraints.
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 8 parameters, 4 required, and no output schema, the description covers the primary purpose, action semantics, and parameter usage hints. It could mention what the tool returns or any side effects, but overall it provides sufficient context for an agent to use it 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 value by explaining that 'forkAuthor' and 'workspaceId' are usually auto-resolved and only needed for override/testing. The 'action' parameter's enum values are contextualized with 'update' and 'delete' descriptions. This enriches understanding 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 'Edit or delete a decision in the current session', using specific verbs and resources. It distinguishes from related siblings like 'record_decision' by emphasizing pre-commit review and immutability of synced decisions.
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 'Use this when reviewing decisions before commit' and describes when to use each action. Provides clear exclusion criteria: once synced, decisions are immutable and should be refined via new decisions with 'supersedes'. This differentiates from siblings effectively.
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, the description fully discloses behavior: it returns summary-only decisions, lists included fields, explains that decisions can span multiple intents, and enumerates decision types. No contradiction or omission noted.
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 clear opening, bullet points for usage, and a detailed return value summary. While comprehensive, it is slightly verbose in the usage bullet list but remains front-loaded and contains no wasted sentences.
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?
Despite no output schema, the description thoroughly explains the return structure (decisions array with fields, count) and nested object details. It references sibling tool get_decision_detail for deeper context, making it complete for the tool's 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 coverage is 100% with adequate descriptions for each parameter. The description adds no additional information beyond what the schema provides, so a baseline score 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?
The description clearly states 'Get all decisions recorded for a project across all intents,' providing a specific verb and resource. It distinguishes itself from sibling tools like get_decision_detail (for full details) and get_session_decisions (session-level).
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 lists use cases under 'Use this to review the project's decision history' and advises to call get_decision_detail for full rationale, providing explicit when-to-use and when-not-to-use guidance.
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. Thoroughly explains the multi-active model (no lock, per-session pointer), restoration of soft-deleted decisions for abandoned intents, and acceptance of both cloud IDs and local UUIDs. Also notes automatic resolution of certain parameters.
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 sections and bullet points, front-loaded with main purpose. Every sentence adds value, though slightly longer than necessary. Still 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?
For a tool with 5 parameters, nested objects, and no output schema, the description covers behavior comprehensively: multi-active model, decision restoration, accepted IDs. Missing output behavior, but overall complete enough for effective 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 coverage is 100%, baseline 3. Description adds value by explaining the difference between cloud ID and local UUID for intentId, and that forkAuthor and workspaceId are usually auto-resolved. Provides context on repoOrigin auto-detection, going 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 verb 'Activate' and the resource 'existing intent by ID', specifying it sets the intent as the current session's focus. Distinguishes from sibling tools like 'create_and_activate_intent' and 'list_team_intents' by listing specific use cases.
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 lists when to use the tool: switching focus, re-activating deactivated intents, resuming work, and resuming abandoned intents. Implicitly excludes creation (handled by sibling) and provides context for when not to use.
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 thoroughly describes async execution, automatic resume on interruption, the re-run guard (needsDecision scenario), forced run behavior on non-default branches, and supported forges. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (When to use, Inputs, Behavior) and front-loaded purpose. While long, each sentence adds necessary detail for a complex tool. Slightly verbose but justified.
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 tool's complexity (9 params, no output schema, no annotations), the description is remarkably complete. It covers parameter interactions, edge cases (resume, force), async nature, and prerequisites (gh/glab). Leaves no major gaps for an agent to infer.
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%, but the description adds significant meaning beyond schema: default values (estimateOnly, force), mutual exclusivity of commits and commitRange, resume logic for commits, conditional contextIssues availability, and detailed force behavior including duplicate-intent risks.
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: 'Analyze a repository's git commit history and produce structured development knowledge (intents and decisions).' Immediately distinguishes from sibling tools that manage existing intents/decisions rather than generating them.
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 'When to use' section explicitly states bootstrap and new-commit scenarios. It explains the re-run guard and force flag for special cases. However, it does not explicitly say when to avoid this tool in favor of alternatives, missing a perfect score.
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?
Without annotations, the description fully discloses behavioral aspects: automated verification, writing conditions, return format, and side effects (files changed on disk).
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 and front-loaded, but slightly verbose with detailed internal process steps. Every sentence earns its place, but could be trimmed.
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?
Very complete for a complex tool with no output schema, describing behavior, conditions, and post-actions. Minor gap: return structure is vague (only names, no types).
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%, and description adds context beyond schema: e.g., intentId is advisory, overlaps from Stop report, forkAuthor/workspaceId auto-resolved.
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 it resolves live code overlaps and auto-applies the safe tier, specifying conditions (trivial tier only) and actions. It distinguishes from sibling arbiter_resolve.
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 ('when ready to incorporate result'), warns to re-read files, and explains when it behaves like arbiter_resolve (human checkout or peer lock).
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 are provided, so the description fully carries the burden. It discloses that decisions are recorded silently, accumulated during the session, and presented before commit. It also notes behavioral traits like constraintViolations handling.
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 structured with clear bullet points and sections. It is concise yet thorough, front-loaded with the purpose, and each sentence adds meaningful information 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 the high parameter count, no output schema, and no annotations, the description is complete in explaining the recording process, scoping, and key fields. It adequately prepares the agent for correct usage.
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 input schema already has 100% coverage with detailed parameter descriptions. The description adds value by explaining scoping rules (e.g., omitting intentId for repo-scoped) and emphasizing the constraintViolations parameter, providing 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 'Silently record a decision point during development.' It lists specific scenarios (fork, abandoned, discovery, constraint, tradeoff, dependency) which precisely differentiates it from sibling tools used for retrieval or other actions.
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 provides explicit guidance on when to call the tool for each decision type, explains intent-scoped vs repo-scoped usage, and highlights important actions like including constraintViolations. It effectively informs the agent of appropriate usage contexts.
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, the description fully carries the burden. It explains the multi-active model (no lock conflicts), creation+activation scoped to session, conflict detection behavior, and the effect of the 'force' parameter. Transparent about auto-detection of repoOrigin and automatic resolution of forkAuthor/workspaceId.
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 and front-loaded with purpose and key steps. Every sentence adds value, no redundancy. Clear separation of usage, multi-active model, and conflict handling.
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?
Despite no output schema, the description covers return behavior (action=conflict) and all usage scenarios. Given the tool's complexity (9 params, nested objects), it provides complete guidance for selection and correct invocation.
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%, but the description adds significant meaning: explains 'force' bypasses conflict detection after user review, 'repoOrigin' auto-detected, 'forkAuthor' and 'workspaceId' typically auto-resolved. Provides context for 'constraints' and 'templateType' 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 the tool creates a new intent and marks it as active for the current session. It uses a specific verb-resource pair ('create' and 'activate') and distinguishes itself from siblings like 'check_active_intent' and 'activate_intent'.
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 guidance on when to call this tool ('when check_active_intent returns no active intent'), prerequisites (summarize and get user confirmation), and handling of conflicts (present to user, retry with force=true). Includes step-by-step instructions.
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, the description fully bears the burden of transparency. It discloses that results include relevantIntents and relevantDecisions, that decisions are summary-only, and that full details require calling get_decision_detail. It also notes that forkAuthor and workspaceId are usually auto-resolved, and that calling early with vague prompts yields weak results. No contradictions with annotations (none exist).
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 clear sections: purpose, when to use, inputs of note, returns, and recommended sequence. Every sentence adds necessary information without redundancy. It is front-loaded with the core purpose and efficiently expands on usage and details. No wasted words.
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?
The description is comprehensive for a tool with 9 parameters and no output schema. It covers the tool's purpose, usage context, key inputs (especially activeFiles), return fields with guidance on how to use them (e.g., calling get_decision_detail for full rationale), and a recommended sequence linking to sibling tools. It provides enough context for an agent to correctly select and invoke the tool.
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?
Despite 100% schema coverage, the description adds significant value beyond the schema: it explains that activeFiles is recommended and improves relevance, that forkAuthor and workspaceId are for override/testing only, and it describes the return fields and their nature (summary-only decisions). It also provides a recommended sequence that clarifies parameter usage context.
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: 'Find past intents and decisions relevant to the current user request.' It uses a specific verb ('Find') and identifies the resources ('past intents and decisions'). It distinguishes itself from sibling tools like get_intents_for_file by focusing on task-specific context and recommending use after initial exploration.
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 details when to use the tool: after initial exploration when files are known, and for task-specific context in large projects. It provides a recommended sequence involving check_active_intent and exploration first. It also advises against calling too early with a vague prompt, effectively telling when not to use it, and contrasts with other tools by stating its preference for large projects.
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/CodeAwareness/kawa.mcp/badges/card.svg)](https://glama.ai/mcp/servers/CodeAwareness/kawa.mcp)

Score Badge

Copy to your README.md:

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

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