kanban-mcp

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, but a few convenience functions overlap with general ones (e.g., get_todos vs list_items with status filter, close_item vs set_status). The descriptions clarify intent, but the large number of get_* tools could cause initial confusion.
Naming Consistency3/5
Most tools follow a verb_noun pattern, but there are inconsistencies: 'new_item' vs 'add_*' verbs, 'edit_item' vs 'update_tag', 'remove_tag' vs 'delete_item', and 'project_summary' lacks a verb. The mixed conventions are still readable but not uniform.
Tool Count2/5
With 45 tools, the server is heavily over-scoped for a Kanban board. Many tools are specialized (metrics, decisions, embeddings) and could be combined or removed. The sheer number overwhelms an agent's tool selection.
Completeness4/5
The tool surface covers the full lifecycle of items (CRUD, status, relationships, tags, decisions, updates, search, export) with few gaps. Minor missing features include no edit for decisions and no item type change, but these are workable.
Average 3.6/5 across 43 of 45 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 2 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the state change (done/closed) but does not disclose permissions, reversibility, side effects on related items, or whether it is distinct from other status updates. This is minimal 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 a single, front-loaded sentence with no wasted words. It is appropriately concise for a simple tool, though its brevity contributes to gaps in other dimensions.
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?
With no annotations, no output schema, and a very brief description, the tool lacks context for correct invocation. The ambiguity with sibling tools like set_status and advance_status is unresolved, and the exact meaning of 'done/closed' is not expanded. The description is not complete enough for an agent to reliably choose this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only 'item_id' with the description 'item_id parameter', which is tautological. The tool description does not explain the parameter meaning, how to obtain it, or any constraints. Despite high schema coverage, the descriptions add no real semantic value.
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 'Mark item as done/closed' clearly states the action (mark) and resource (item), and clarifies the meaning of 'close' as done/closed. However, it does not differentiate from sibling tools like set_status, advance_status, or revert_status, which also modify status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool compared to alternatives such as set_status or advance_status. The description only states what it does, not when to choose it.
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 carries the full burden of behavioral disclosure. It only states the action without mentioning side effects (e.g., whether the tag itself is deleted if no items remain), permissions, idempotency, or error behavior. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that is front-loaded and easy to parse. It avoids fluff, but could be slightly more structured by including edge-case behavior or parameter hints. It earns its place but is at the minimal end of acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two integer parameters and no output schema, this description is adequate but leaves gaps. It does not explain what happens if the association does not exist, whether the operation is reversible, or if special permissions are required. These gaps are more impactful because no annotations are provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema descriptions are tautological ('tag_id parameter', 'item_id parameter'), providing no real semantic value. The description itself does not explain the parameters or their roles. Although the parameter names are self-explanatory, neither the schema nor the description adds meaning beyond the names.
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 'Remove a tag from an item' clearly states the action (remove) and the resource (tag-item association). It is specific enough to distinguish from sibling tools like delete_tag (which removes the tag entirely) or add_tag (which adds the association), though it does not explicitly mention these alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as add_tag, delete_tag, or get_item_tags. The description implies its use for untagging an item, but does not provide context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It merely says 'delete' without disclosing whether the action is permanent, whether it cascades, or any permission requirements. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, making it concise and easy to parse. However, it is so minimal that it borders on under-specification, though it still communicates the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter) and the lack of annotations and output schema, the description is too sparse. It does not mention return value, error conditions, or side effects, leaving the agent with an incomplete picture of the tool's behavior.
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% for the single parameter decision_id, so the baseline is 3. The description adds no extra meaning beyond the schema; the parameter description itself is a placeholder ('decision_id parameter'), but the description still does not clarify semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete) and the resource (decision record), which is specific enough to distinguish from siblings like delete_item. However, it relies on the tool name itself and does not explicitly contrast with alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as add_decision or delete_item. The description lacks any context or exclusions, leaving the agent without criteria for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. The word 'Get' implies read-only, but it does not clarify the return shape, error behavior, or the exact scope of 'full details'. It also leaves unclear whether related data is included.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of seven words, front-loaded with the action. There is no filler, repetition, or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description leaves ambiguity about what 'full details' includes and how this tool differs from the many item-related sibling getters. It does not mention return structure, error handling, or what is excluded.
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. However, the schema's description of item_id is tautological ('item_id parameter'), and the tool description adds no additional meaning about the parameter's role or format.
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 identifies a get operation for a specific item's full details, using a specific verb and resource. However, it does not differentiate from sibling getters like get_item_metrics or get_item_timeline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as list_items, get_item_metrics, or get_item_timeline. The description only states what the tool does, not when to prefer it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. It indicates a read operation ('get') but does not mention whether a current project must be set, how updates are ordered or paginated, or what the return format looks like. This lack of detail leaves significant transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. It front-loads the verb and resource, making it easily scannable and appropriate for the tool's simplicity.
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?
The description is too brief to cover the tool's context given the absence of annotations and output schema. It does not clarify what constitutes an 'update', how 'recent' is defined, or how this tool differs from closely related tools like get_latest_update and get_project_timeline, making it incomplete.
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 only parameter 'limit' has a schema description that is tautological ('limit parameter'), and the tool description adds no further meaning. Since schema description coverage is 100%, the baseline is 3, even though the parameter description itself is poor.
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 uses a clear verb ('get') and resource ('recent updates for current project'), making its basic purpose understandable. However, it does not differentiate from similar sibling tools like get_latest_update or get_project_timeline, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_latest_update or get_project_timeline. The description implies a use case but does not state exclusions, prerequisites, or scenarios where other tools would be more appropriate.
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 carries the full burden of behavioral disclosure. It states the basic action but does not disclose potential errors (e.g., when no previous status exists), whether the change is reversible, or what the response contains. As a mutation tool, these omissions are significant.
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 one short, front-loaded sentence that directly states the action without filler. It earns its place but could be slightly more informative; still, it is appropriately concise for its simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It omits edge cases such as 'no previous status' behavior, does not specify the return value, and offers no context about the workflow or prerequisites. This leaves critical gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'item_id' has a schema description of 'item_id parameter', which is tautological and unhelpful. The tool description does not explain what item_id refers to or any constraints beyond being required, forcing the agent to infer from the tool's purpose.
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 and resource: 'Move item to previous status in its workflow.' It clearly distinguishes from sibling tools like 'advance_status' (which moves forward) and 'set_status' (which sets an arbitrary status), making 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that this is for undoing a status change, nor does it reference 'advance_status' or 'set_status' as alternatives. An agent would have to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions only that the status must be valid for the item type, but does not disclose side effects, return values, error handling, or permission requirements. This is insufficient for a mutation 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?
One concise sentence containing the essential information: the action, the target resource, and a key constraint. No redundant words or filler.
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?
For a simple two-parameter tool, the description is minimal but still leaves significant gaps. It does not explain how status validity is determined, where to find valid statuses, or how this tool relates to sibling status-change tools. This lack of contextual detail makes it hard for an agent to use the tool correctly without additional knowledge.
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%, but the parameter descriptions are generic placeholders ('status parameter', 'item_id parameter'). The description adds semantic meaning by noting that the status must be valid for the item type, which goes beyond the schema. However, it does not provide allowed values or further syntax details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set item to a specific status') and includes a relevant constraint ('must be valid for item type'). It distinguishes from workflow-specific siblings like advance_status/revert_status by indicating direct status assignment, though it does not explicitly name these alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use set_status versus sibling tools such as advance_status or revert_status. The description only states the core function and a validity constraint, without explaining context or exclusions.
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 carries full behavioral burden. It merely says 'Get', implying a read-only operation, but does not disclose what 'context' includes, whether a current project must exist, or any side effects. This minimal disclosure is insufficient for a tool with no structured 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 a single, direct sentence with no filler words. It is concise and front-loaded, though it borders on under-specification due to its brevity. Still, it is appropriately sized for a zero-parameter tool.
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?
For a tool with no parameters and no output schema, the description should clarify what 'project context' includes or how it differs from project_summary. It does neither, and with many sibling tools, the agent may be uncertain which tool to invoke. The description is too skeletal for complete decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty schema, so the baseline is 4. The description need not explain parameters; it appropriately relies on the implicit 'current project' session state. It adds no parameter-specific info because there are none to add.
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 uses a specific verb ('Get') and resource ('current project context'), clearly indicating a retrieval operation. However, 'context' is somewhat vague and does not differentiate it from siblings like project_summary or get_project_timeline, though the core purpose is understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as project_summary or set_current_project. There are no explicit conditions, exclusions, or alternative names, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses irreversibility through 'permanently', which is important, but it omits other critical behavioral traits such as cascading deletion of relationships, files, or updates, permission requirements, or any confirmation step. This is minimal disclosure for a destructive action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is concise and to the point, stating the action and its permanence without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature, the context is incomplete. It does not explain what happens to child items, associated files, or relationships after deletion, and there is no output schema to clarify the result. The description is minimal and lacks necessary warnings.
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%, and the baseline is 3 even without extra parameter info in the description. The description adds no additional meaning to the item_id parameter beyond its generic name.
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 states a specific action ('Permanently delete') and a specific resource ('an item'), with the word 'permanently' distinguishing it from sibling tools like close_item that may imply a softer closure. This is a clear verb+resource+scope definition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided for when to use this tool versus alternatives. It does not mention that close_item is for soft closing, nor does it note prerequisites or use cases. The 'permanently' keyword hints at context, but this is not explicit enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose all behavioral traits. While 'get' implies a read operation, the description does not clarify the return format (e.g., counts, lists), whether it includes all items or only active ones, or any other side effects or permissions. The full burden of transparency is unmet.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the verb and conveys the essential information. There is no wasted text, making it highly efficient.
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 that there is no output schema, the description should explain what the summary contains. It mentions 'by type and status' but does not specify whether the output is a count, list, or other aggregation. It also does not differentiate from similar tools, but for a simple zero-parameter tool, this is minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty. With a schema description coverage of 100% and no parameters, the baseline is 4. The description does not need to explain parameters, so it scores at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get summary of items by type and status for current project.' It names a specific verb ('get'), resource ('summary of items'), and scope ('current project'). However, it does not explicitly distinguish this from similar sibling tools like get_item_metrics, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as list_items or get_item_metrics. It simply states what the tool does without any contextual cues about when it is the preferred choice.
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 carries the full burden but only states the action. It does not disclose side effects, whether removal is permanent, or how errors are handled (e.g., if the relationship doesn't exist). This is a significant gap for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded and free of fluff. It efficiently communicates the core purpose.
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?
For a simple removal tool with no annotations or output schema, the description is minimal but leaves out important operational details, such as whether the operation is idempotent, the direction of the relationship, and any dependencies. It feels under-specified for an agent needing to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all three parameters, but their descriptions are tautological. The tool description adds minimal context by mentioning 'two items' but does not clarify the roles of source_id and target_id or the format of relationship_type. Baseline 3 applies due to high schema coverage.
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 ('remove') and identifies the resource ('relationship between two items'), clearly distinguishing it from sibling tools like add_relationship. It unambiguously states the core action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as add_relationship, nor any prerequisites like the relationship needing to exist. The description offers no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full responsibility for disclosing behavioral traits. It does not mention whether the update is partial or complete, what happens to items associated with the tag, error conditions, or permissions. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded, with no filler. It conveys the essential action and scope efficiently, earning a high score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters and no output schema, the description is minimal and lacks important details such as update semantics (partial vs full replacement), whether name/color are optional, and potential side effects on associated items. Given its low complexity, the gap is noticeable but not catastrophic.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions are tautological ('name parameter', 'color parameter'), offering no meaning. The description adds some value by clarifying that 'name' and 'color' are the updatable attributes and that 'and/or' implies partial updates. However, it does not explain whether at least one of name/color is required or provide any constraints like color format.
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 uses the specific verb 'update' and resource 'tag', and specifies the modifiable fields ('name and/or color'), clearly distinguishing it from siblings like add_tag, remove_tag, and delete_tag. It is unambiguous about what the tool does, though it could be more explicit that it targets an existing tag via tag_id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: change a tag's name or color. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. The purpose is self-evident from the name and description, but no explicit guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosure. It only states the action ('move to next status') without revealing behavior such as errors when no next status exists, whether the operation is reversible, or any required permissions. This is minimal for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently communicates the core action. Every word contributes, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), and the purpose is clear. However, the description omits usage context and behavioral nuance, such as what happens if the item is already in the final status or how this relates to set_status/revert_status. It is minimally viable but leaves 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?
The schema provides 100% coverage for the single required parameter item_id. The description adds little beyond the schema—only identifying the item as the target of the move. Since the schema already documents the parameter, a 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 uses a specific verb ('Move') and resource ('item') with a clear destination ('next status in its workflow'). It clearly distinguishes from sibling tools like revert_status and set_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With siblings such as set_status (arbitrary status) and revert_status (previous status), the description does not mention when advance_status is the appropriate choice or when to prefer others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only restates that it gets decisions, but does not describe return format, sorting, pagination, error handling for missing items, or permission requirements. The phrase 'Get all' implies a read operation but adds no additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that is directly on point. No unnecessary words or redundant details. It is appropriately sized for the tool's simplicity.
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?
The tool is simple with one parameter and no output schema or annotations. The description explains the core purpose but does not mention what items are returned, whether an empty list is returned when no decisions exist, or any pagination limits. However, for a straightforward getter, this is minimally acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for item_id is merely 'item_id parameter', which is tautological and provides no real meaning beyond the parameter name. The tool description does imply that item_id identifies the item whose decisions are fetched, but this is minimal. Since the parameter is self-explanatory and only one exists, a 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 clearly states the verb 'Get' and the resource 'all decisions for an item'. It distinguishes from sibling tools like add_decision/delete_decision (which are mutations) and get_item (which returns the item itself). The scope is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions or alternatives, nor does it specify contexts (e.g., when you need a historical record of decisions vs. just current status). It is a bare statement with no practical usage notes.
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 must bear the full burden. It adds 'both directions' as a behavioral nuance, but it does not disclose return format, pagination, ordering, or what constitutes a 'relationship'. For a getter, this is minimal coverage and leaves ambiguity about the response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It states the verb, resource, and scope efficiently.
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?
The tool is simple (one param, no output schema), but the description still has gaps. It does not clarify what relationship types are included, the nature of 'both directions', or the response shape. It is adequate for a basic getter but leaves room for confusion given the variety of relationship-related sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers item_id with 100% coverage but the description 'item_id parameter' is tautological. The tool description clarifies that item_id identifies the item whose relationships are retrieved, adding a bit of meaning. Since schema coverage is high, the baseline of 3 applies, and the description does not significantly exceed 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 uses a specific verb ('Get'), a clear resource ('relationships for an item'), and defines scope ('both directions'). This clearly distinguishes the tool from siblings like get_blocking_items (specific relationship type) and add_relationship/remove_relationship (write operations).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It implies this is the general-purpose relationship getter, but it does not explicitly mention sibling tools like get_blocking_items or set_parent, nor does it state exclusions.
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 must disclose behavior. It only restates the tool name and does not mention read-only safety, return format, error behavior, or how tags are presented, leaving the agent to assume.
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?
A single 7-word sentence with zero filler. It is front-loaded with the action and object, achieving maximum conciseness.
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?
With no output schema, the description should clarify the return structure. It states 'tags' but not whether they are IDs, names, or objects. The one-parameter tool is simple, so this is a modest 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 baseline 3. The parameter item_id has a placeholder description, but the tool description's 'assigned to an item' adds minor context. No additional parameter semantics are 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 uses the specific verb 'Get' with resource 'tags' and scope 'assigned to an item', clearly distinguishing it from list_tags (all tags) and get_item (item details).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to choose this tool over siblings like list_tags or get_item, nor any exclusions or prerequisites beyond the required item_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only adds that results are ordered chronologically, but does not explicitly state the tool is read-only, describe pagination, or mention any side effects or limitations. Compared to the update_drive example, this is a read operation, but the lack of explicit safety or scope details keeps the score low.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action, target, and ordering. Every word earns its place, with no unnecessary filler or repetition.
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 there is no output schema, the description should ideally clarify what the returned history contains (e.g., timestamps, statuses). It only says 'status change history' and 'ordered chronologically,' which is minimal but adequate for a simple tool. However, the lack of return format details or disambiguation from overlapping siblings leaves 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?
The schema has 100% coverage for the single parameter, but the description 'item_id parameter' adds no real meaning beyond the name. The tool description does not elaborate on item_id semantics, but the baseline is 3 due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets status change history for an item and is ordered chronologically. It uses a specific verb and resource, distinguishing it from broad timeline tools, but does not explicitly differentiate from siblings like get_item_timeline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when status history is needed, but provides no explicit guidance on when to prefer this tool over alternatives such as get_item_timeline or get_updates. No alternative tools or exclusion criteria are mentioned.
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 the burden of disclosing behavior. It explains the status filter and implies a read-only operation via 'Get', but does not detail side effects, permissions, pagination, or return format. This is minimal but not misleading.
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?
A single, front-loaded sentence that wastes no words. It states the action, the resource, and the context succinctly.
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 zero parameters and no output schema, the description is reasonably complete for a simple query tool. However, it does not clarify whether it applies to the current project or all projects, and lacks any return-value details, leaving some ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is fully covered and no parameter explanation is needed. Baseline 4 is appropriate due to the absence of parameters.
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 a specific verb ('Get') and resource ('items in 'in_progress' status'), which distinguishes it from more general sibling tools like list_items or get_item. However, it does not explicitly contrast it with siblings or clarify scope beyond the status filter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like list_items or get_todos. The phrase 'for context during work' vaguely implies a use case but offers no exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the basic action and filters, with no information about pagination, ordering, inclusion of closed/deleted items, or response format. The tool's behavior beyond the obvious 'returns a list' is unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the core purpose and key filter options without any fluff. Every word earns its place, and it is appropriately sized for a simple list operation.
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?
The tool has 5 optional parameters and no output schema, yet the description only covers three of them. It does not explain what 'items' includes relative to sibling tools, how 'current project' is determined, or what happens with limit/tag_mode. Given the tool's moderate complexity and the presence of many similar list tools, the description leaves significant 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 coverage is 100% (every parameter has a description), but those descriptions are tautological ('tags parameter', etc.). The tool description adds meaningful mapping for item_type, status, and tags by mentioning them as filters, but tag_mode and limit are left unexplained. This partially compensates for the generic schema descriptions, so a 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 clearly states the verb 'List', the resource 'items', and the scope 'for current project'. It also enumerates the specific filter dimensions ('type/status/tag'), making the tool's function unambiguous and distinct from broader list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to list items in the current project with optional filters) but provides no explicit guidance on alternatives or exclusions. It does not mention sibling tools like get_todos or get_active_items, so usage context is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It discloses the comma-separated format for item_ids but omits any information about authentication, side effects, error handling, or what the response will be, which is important for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately states the action and optional parameter format; every word is necessary.
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 two-parameter schema and no output schema, the description covers the tool's purpose and parameter meaning, but it fails to mention return behavior or prerequisites such as an active project, leaving some gaps for a create-oriented tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions are tautological ('content parameter', 'item_ids parameter'), so the description's mention that content is the progress update text and item_ids are comma-separated item IDs provides essential meaning for both parameters, exceeding the negligible schema value.
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 the specific verb 'Add' with the resource 'progress update' and notes optional linking to items, clearly distinguishing this from read tools like get_updates and mutation tools like advance_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to choose this tool over alternatives like get_updates or add_decision; it simply states what the tool does without any contextual cues.
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 the transparency burden. The word 'Get' implies read-only behavior and the listed output fields provide some clarity, but it does not mention error handling, whether item_id must refer to an epic, or any other behavioral caveats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that includes the action, resource, and key output fields. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter, the description plus schema is minimally viable. It lists the return fields but leaves ambiguities like whether item_id must be an epic ID, what 'percent' represents, and how incomplete_items is structured. Without an output schema, these caveats matter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for item_id is generic ('item_id parameter'), so the tool description's mention of 'epic' gives some semantic hint that item_id identifies the epic. However, it does not explicitly connect item_id to the epic or explain any value constraints, so it adds only marginal value beyond the schema.
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 uses a specific verb ('Get') and resource ('epic') and enumerates the returned stats (total, completed, percent, incomplete_items). It clearly states what the tool does, though it does not explicitly differentiate from sibling tools like get_item_metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when wanting progress stats for an epic, but it provides no explicit when-to-use/when-not-to-use guidance and names no alternatives. This is adequate but not clearly differentiated.
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 the burden of behavioral disclosure. It lists the computed metrics and their unit (hours), which adds useful context. However, it does not describe the response format, error behavior, or any requirements like item existence.
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. It starts with the action and resource, then lists the metrics in a clear list. Every sentence adds value, with no redundant phrasing.
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?
The tool has a single parameter and no output schema, so the description should explain return values. It lists the metrics and their unit, but does not specify the data structure (e.g., object keys, types). This is adequate but leaves ambiguity about the response format.
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% for the sole parameter (item_id), but the schema description 'item_id parameter' is tautological. The tool description clarifies that metrics are for an item but does not elaborate on the parameter semantics beyond the schema. Baseline 3 applies due to high schema coverage.
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: retrieving calculated metrics for an item, listing specific metric names (lead_time, cycle_time, etc.). This distinguishes it from sibling tools like get_item or get_item_timeline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or explicit alternative tools to consider. The usage context must be inferred entirely from the tool name and metric list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose whether the operation is idempotent, whether it validates the directory, or what side effects occur (e.g., changing session state). The only additional behavioral note is the timing 'at session start', but that is more usage context than 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 extremely concise: two sentences, front-loaded with the action, and no extraneous detail. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-parameter setter with no output schema, the description is mostly sufficient. It tells when to use it but leaves gaps about the effect of setting the context, error handling, or whether the tool is idempotent. Given the lack of annotations, a bit more explanation would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, but the parameter description 'project_dir parameter' is tautological and adds no meaning. The tool description does not elaborate on the parameter either. The parameter name 'project_dir' and type 'string' provide basic semantics, so this meets the baseline but adds little value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action with a specific verb 'Set' and a resource 'current project context'. It is distinguishable from sibling get_current_project, which retrieves the context. However, 'project context' is somewhat vague and could be more explicit (e.g., 'Set the active project directory').
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 a clear usage directive: 'Called at session start with $PWD.' This tells the agent when to use the tool, but it does not mention alternatives or explicitly exclude other scenarios. Still, the context is clear and practical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Add' which implies mutation, but does not disclose any side effects, permission requirements, or behavior on failure. The max character limits are helpful but not behavioral traits.
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 concise, front-loaded with the primary action, and uses an organized args list. Some redundancy exists with the schema's parameter descriptions, but the added constraints keep it efficient and readable.
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?
The tool is a simple mutation with no output schema and no annotations. The description covers the purpose and parameters adequately for a basic add operation, but it omits details about the return value or success/failure behavior, which leaves some gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the schema covers all parameters at 100%, the descriptions in the schema are generic ('choice parameter'). The tool description adds real meaning: it explains what each parameter represents (e.g., 'What was decided', 'What was rejected') and provides max length constraints, exceeding the schema's value.
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 action ('Add a decision record') and the target ('to an item'), distinguishing it from sibling tools like delete_decision and get_item_decisions. The verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly mention when to use this tool versus alternatives, but the unique purpose among siblings makes the usage context implied. There is no exclusion or alternative mentioned, so it sits at the 'implied usage' level.
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 carries the full burden of behavioral disclosure. It does not explicitly state whether the operation is read-only, non-destructive, or requires specific permissions. It also does not mention return format, pagination, or potential errors. The only behavioral nuance provided is the recursive flag, which is insufficient for a tool with zero annotation support.
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 short, informative sentences. Every word earns its place, and the description is front-loaded with the core action. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation, the description conveys the core functionality but leaves out return format, ordering, or what constitutes a 'child'. Without an output schema or annotations, the description should ideally mention the shape of the response or any limitations, making it minimally adequate but not fully 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?
While the schema covers both parameters, the schema descriptions ('item_id parameter', 'recursive parameter') are tautological. The tool description adds meaningful semantics: it identifies item_id as the parent item and clarifies that recursive=True fetches all descendants, providing value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves children of an item, using a specific verb and resource. It distinguishes itself from sibling tools like 'get_item' or 'list_items' by focusing on the hierarchy relationship, though it does not explicitly differentiate itself from similar getters.
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 a clear usage guideline: setting recursive=True returns all descendants. It implies the default behavior returns immediate children, which tells when to use the parameter. However, it stops short of naming alternative tools or conditions when this tool should be preferred over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Create', which implies mutation, but lacks details about side effects, required permissions, idempotency, or what happens on success/failure. The 'for current project' scoping adds some context but is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action, and contains no filler or redundant information. It efficiently conveys the tool's core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no output schema, and no annotations, a one-sentence description is insufficient. It does not explain the return value, how required fields are used, or the meaning/side effects of parameters like priority and parent_id. The description is adequate for a basic understanding but far from complete for safe 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% per the metric, so the baseline is 3. The description adds value by enumerating possible values for item_type (issue, todo, feature, epic, diary entry), but other parameters like priority, complexity, and parent_id remain only minimally described by their names.
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 action ('Create') and the resource ('a new issue, todo, feature, epic, or diary entry'), and scopes it to the current project. This distinguishes it from siblings like edit_item and delete_item.
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 clearly indicates this tool is for creating new items in the current project, which provides clear context. However, it does not explicitly mention when not to use it or name alternatives, but the creation purpose is evident.
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 the full burden. It discloses one behavioral trait ('creates tag if it doesn't exist'), which is helpful, but it does not address what happens if the tag already exists on the item, whether the item must exist, or permissions. This is a minimal but useful 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?
Single sentence, front-loaded with the action, and includes a relevant parenthetical without any 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?
The description covers the core action and one side effect, but for a mutation with no annotations and no output schema, it could also mention failure modes or return behavior. It is adequate for a simple tool but incomplete for a fully self-sufficient description.
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 placeholder descriptions ('item_id parameter'), and the tool description doesn't add meaningful clarification beyond the parameter names. Since schema coverage is 100% (even if weak), the baseline is 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 uses a specific verb ('add') and resource ('tag to an item'), clearly defining the operation. It distinguishes from sibling tools like remove_tag, update_tag, and delete_tag, and the parenthetical adds a useful detail about tag creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when adding a tag to an item) but does not explicitly state alternatives or exclusions. There is no mention of when not to use it or how it differs from other tag-related tools.
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 the tool returns a dict with success status and a list, and the verb 'Get' implies a read-only operation. However, it does not detail possible failure modes, error handling, or the structure of the file objects, which could be important 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 concise and well-structured, with a clear one-line purpose followed by Args and Returns sections. Every sentence is useful, and the length is appropriate for the tool's simplicity, though the 'Args' section slightly duplicates the schema.
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 low complexity (one parameter, no output schema), the description is reasonably complete. It states the purpose, parameter, and return shape. However, it could be more complete by describing the format of the files in the list, but for this simple get operation, it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents item_id with 100% coverage, so the baseline is 3. The description adds a bit of meaning ('The item ID to get files for') that clarifies the parameter's purpose, but it is only a slight enhancement over the schema's minimal 'item_id 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?
The description clearly states a specific action ('Get all files linked to an item') that identifies both the resource (files) and the relation (linked to an item). It is easily distinguished from sibling tools like link_file or get_item, so no ambiguity exists about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates when to use this tool (when you need to retrieve files attached to an item) but provides no explicit guidance about alternatives or exclusions. Sibling tools like link_file and unlink_file exist for modifying file associations, yet the description does not contrast with them.
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 carries full burden. It only mentions the return format (success status and link_id) but does not disclose side effects, failure behavior, idempotency, permissions, or what happens when linking a file region that is already linked. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with Args and Returns sections. Every sentence adds value, and the main purpose is front-loaded. There is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with no output schema and no annotations, the description provides the essentials (action, parameters, return value). However, it omits failure responses, edge cases, and any constraints on file links, leaving some critical usage questions unanswered.
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 schema descriptions are trivial ('item_id parameter'), but the description's Args section adds real meaning: 'The item to link the file to', 'Relative path to the file', and optional line numbers. It clarifies purpose and optionality, compensating for the low-quality 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 states a specific verb+resource: 'Link a file (or file region) to an item.' This clearly distinguishes it from sibling tools like unlink_file and get_item_files, which reverse or query the linking operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied by the purpose: use when you want to associate a file with an item. However, there is no explicit when/when-not guidance or mention of alternatives, such as when to prefer unlink_file or how this relates to get_item_files.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavioral traits. While 'Remove a file link' clearly implies a mutating operation, the description does not mention prerequisites (e.g., the link must already exist), side effects, reversibility, or error behavior. Only the return value ('Dict with success status') is mentioned, which is minimal.
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 Args and Returns sections. It is concise, with no unnecessary words, and every sentence/field provides meaningful information. The format aids quick comprehension.
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 simplicity and the presence of a complete parameter description, the description covers the essential operational details. It does not include usage context or edge cases, but these are partially covered in other dimensions. The lack of an output schema is compensated by the stated return type ('Dict with success status'). Overall, it is reasonably complete for a straightforward unlink action.
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?
The description significantly enhances the schema by explaining each parameter's purpose and constraints. For example, item_id is 'The item to unlink the file from,' file_path is 'Relative path to the file,' and line_start/line_end are described as optional and 'must match to unlink.' This goes far beyond the schema's trivial descriptions like 'item_id 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?
The description clearly states the action: 'Remove a file link from an item.' This is a specific verb (Remove) and resource (file link from an item), and it distinguishes itself from the sibling tool link_file, which would perform the opposite action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention that it should be used only when a file link exists, nor does it reference the sibling tool link_file or other related tools. Usage context is only implied by the action itself.
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 the burden. It clarifies the semantic of 'blocking' (related to completion), but does not disclose whether the result is recursive, what item properties are returned, or any permissions/guarantees. This is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that states exactly what the tool does with no filler or redundancy. It is efficiently 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 simplicity (one parameter, no output schema), the description adequately conveys core behavior. It lacks detail on the shape of returned items or edge cases, but these are likely obvious from context. Slight gap due to no 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 description coverage is 100% (every parameter has a description), so baseline is 3. However, the parameter description 'item_id parameter' is purely tautological and adds no meaningful semantics beyond the schema field name.
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 uses a specific verb 'Get' and identifies the exact resource: items that block this item from being completed. It clearly distinguishes from siblings like get_item_relationships or get_active_items by focusing on blocking behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose implies when to use it (when needing blockers), but there is no explicit guidance on when not to use it or alternatives. It lacks comparative context against related sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the transparency burden. It discloses the dependency on the current project but does not mention return behavior in edge cases (e.g., no updates) or explicitly confirm that it is read-only beyond the verb '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?
A single sentence directly states the action and object, with zero unnecessary words. The structure is front-loaded and 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 zero-parameter tool, the description is adequate for selection and invocation. It does not describe the return structure or edge cases, but the simple purpose and absence of parameters make this a minor gap.
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 has no parameters, so the baseline is 4. The description adds no parameter details because none exist; the reference to 'current project' is implicit context, not a 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?
The description clearly states the tool retrieves the most recent update for the current project. The verb 'get' and the singular 'most recent update' distinguish it from the sibling tool get_updates, which likely returns all updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives like get_updates. The description implies it is for fetching the latest singular update, but does not mention exclusions or provide context for choosing between the tools.
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 the burden of behavioral disclosure. It discloses the return format ('Dict with success, results list') and notes that the source itself is excluded, which is useful. However, it does not describe error handling, ordering, or side effects—though the read-only nature is apparent from the verb 'find'.
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 well-structured, with a clear one-line summary followed by Args and Returns sections. It avoids unnecessary prose and front-loads the primary purpose. Every 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 the tool's moderate complexity (four parameters, no output schema), the description adequately covers purpose, parameters, defaults, and return structure. It lacks explicit guidance on when to use versus semantic_search, but is otherwise complete for a similarity lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all parameters, but the description adds significant semantics: it enumerates valid values for source_type ('item', 'decision', 'update'), documents defaults for limit (5) and threshold (0.0), and explains the threshold range (0.0-1.0). This exceeds the schema's minimal 'parameter' 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's purpose: 'Find items similar to a given item, decision, or update.' It identifies a specific verb ('find') and resource (similar items) with explicit source types, which distinguishes it from generic search tools like 'search' and 'semantic_search'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by defining the tool's action, but it does not explicitly state when to use this tool over alternatives like 'search' or 'semantic_search'. No exclusions or alternative recommendations are provided, leaving usage guidance minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly signals a read-only operation ('Get') and explains the backlog semantics, but it does not disclose how 'current project' is determined, whether any setup is required, or what the return value 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 a single, front-loaded sentence that communicates the action and scope with no redundant information. Every word contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description covers the core behavior but omits important context such as the dependency on a current project (set via set_current_project) and any details about return ordering or item fields. This makes it adequate but not fully 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?
The tool has zero parameters, and the description adds meaningful context by explaining the implicit filters: status = 'backlog' and project = 'current'. This goes beyond what the empty input schema can convey.
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 ('items in backlog status') with a clear scope ('for current project'), distinguishing it from sibling tools like list_items or get_active_items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies the primary use case—retrieving the backlog/todo queue for the current project—but does not explicitly mention when not to use it or suggest alternatives such as get_active_items or list_items. No exclusions are stated.
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 the burden of behavioral disclosure. It explains the semantics of each relationship type, which is useful behavioral context. However, it does not disclose operational details such as whether the operation is idempotent, what happens if the relationship already exists, or any prerequisites (e.g., items must exist). This is adequate for a simple create operation but lacks full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the primary purpose. The list of relationship types is structured and each line provides distinct value. No unnecessary words or repetition.
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?
The description adequately covers the core purpose and relationship types, but it lacks information about return values, error behaviors, or prerequisites. Since there is no output schema and no annotations, some of this context would be helpful. For a relatively simple create tool, this is a minimal viable description but leaves some gaps.
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 schema descriptions are generic ('source_id parameter'), but the description adds meaning by defining the allowed values for relationship_type and their semantics. It also implies that source_id and target_id are item identifiers. Although schema coverage is 100%, the description significantly enriches the parameter meanings, especially for relationship_type.
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: 'Add a relationship between two items.' It also lists the four relationship types, which further clarifies what the tool does. This distinguishes it from sibling tools like remove_relationship and get_item_relationships.
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 about when to use this tool by enumerating the relationship types and their meanings. It implies this is the tool for creating relationships, though it does not explicitly mention alternatives or exclusion scenarios. The context is sufficient for an agent to choose this tool over related ones like remove_relationship.
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 the burden of behavioral disclosure. It clearly states the destructive cascade ("removes from all items") and project scope, which is valuable. It does not mention permanence or permissions, but the core behavior is adequately disclosed for a simple delete tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb, and contains no unnecessary words. It is appropriately sized for the tool's simplicity.
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 simple 1-parameter delete tool with no output schema, the description covers the essential action and its global effect. It could add a note about irreversibility or error handling, but the current description is sufficient for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (tag_id) with only the trivial description 'tag_id parameter'. The tool description does not add meaning beyond the schema; it is obvious that tag_id identifies the tag to delete. With 100% schema coverage (even if minimal), the baseline is 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 uses a specific verb "Delete" with a clear resource "a tag from current project" and adds the scope "removes from all items". This distinguishes it from siblings like remove_tag (which likely removes a tag from a single item) and update_tag.
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 that this tool operates on the current project and has a global effect (removes from all items), implying it is for project-level tag deletion rather than item-level removal. However, it does not explicitly name alternative tools like remove_tag or specify 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It reveals the special mechanism for removal (parent_id=0), but doesn't discuss side effects like replacing an existing parent, error conditions, or response format. Minimal but not completely absent.
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 short sentences with no wasted words. The primary purpose is stated first, and the removal idiom follows as a necessary clarification.
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 simple two-parameter setter with no output schema, the description adequately covers the core operation and the non-obvious removal idiom. It lacks details on return value or errors, but the tool's simplicity doesn't demand more.
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 schema descriptions are tautological ('item_id parameter'), so the description adds critical meaning by explaining that parent_id=0 removes the parent. This goes beyond the schema and clarifies the special semantics of parent_id. item_id remains self-evident.
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 function with a specific verb ('set' or 'remove') and resource ('parent relationship'). It distinguishes itself from sibling tools like add_relationship/remove_relationship by focusing specifically on the parent relationship.
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 gives clear context for when to use the tool (to set or remove a parent relationship) and provides a specific usage rule ('Use parent_id=0 to remove parent'). It doesn't explicitly mention alternatives, but the sibling names make the differentiation apparent.
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 of behavioral disclosure. It explains the return structure (Dict with success, format, content, item_count) and parameter overrides (item_ids overrides type/status filters), but it does not explicitly state whether the operation has side effects, although exporting implies read-only behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a structured list of parameters and a Returns line, containing no filler or redundant information. It is appropriately sized for 11 parameters and clearly front-loads the tool's purpose.
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?
The description covers all 11 parameters with meaningful semantics and explains the return dict, compensating for the lack of an output schema. It does not discuss error cases or edge behaviors, but for an export operation that is likely acceptable.
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?
The schema descriptions are minimal placeholders (e.g., 'limit parameter'), so the description adds essential meaning for every parameter, including format options, filter semantics, overrides, and defaults (e.g., limit default 500). This goes well beyond the schema and is vital for correct invocation.
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 the specific verb 'Export' with a clear resource ('project data') and output formats ('JSON, YAML, or Markdown'). This clearly distinguishes it from sibling tools that retrieve or modify individual items, making the function immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does but provides no explicit guidance on when to use it over alternatives or when not to use it. No exclusions or references to sibling tools like project_summary or get_updates are given, so usage context is only implied by the export action.
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 full burden. It discloses the return format (Dict with items, updates, total_count) and search scope, but does not mention read-only behavior, pagination, case sensitivity, or rate limits. Some useful context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with a one-sentence purpose, an Args block, and a Returns block. No wasted words or redundant information.
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 and no annotations, the description covers the operation, parameters, and return shape sufficiently. It could be more complete by mentioning result ordering or total_count semantics, but it is adequate for basic 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?
The schema descriptions are generic placeholders ('query parameter', 'limit parameter'), while the description provides meaningful semantics: query is a search query string, limit is maximum results per category with default 20. This adds significant 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 it performs 'full-text search across items and updates in current project', specifying the verb, resource, and scope. This distinguishes it from semantic_search and find_similar, which rely on different search mechanisms.
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 provides clear context that search is scoped to the current project, but does not explicitly mention when to use this over alternatives like semantic_search or find_similar. No exclusions or alternative recommendations are given.
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 the full burden. It discloses defaults (limit=10, threshold=0.0), the meaning of empty source_types, and the return structure, providing strong behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args and Returns sections, front-loaded with purpose, and every sentence contributes. No fluff 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?
The description covers purpose, all parameters with defaults, and return format. Without an output schema, the return details are necessary and provided. Minor gap: no mention of search scope or project context, but this is sufficient for a simple search 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?
The schema descriptions are tautological ('limit parameter', etc.), while the tool description gives meaningful semantics: query is a natural language string, limit controls result count, source_types supports comma-separated values, and threshold sets similarity floor.
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 ('Search') with clear resources ('items, decisions, and updates') and method ('by semantic similarity'), which distinguishes it from the sibling 'search' tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for semantic similarity searches but does not explicitly state when to prefer this tool over alternatives like 'search' or 'find_similar', nor does it provide exclusions.
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 of behavioral disclosure. It does an above-average job by revealing non-obvious sentinel behaviors (empty string/zero skipping updates, single space to clear description, -1 to skip parent, 0 to remove parent). It stops short of mentioning side effects, permissions, or error handling, but the critical edge cases 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. The first sentence states the purpose concisely; the second delivers critical usage details in a structured note. Every word earns its place.
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 moderate complexity (6 params, no output schema, no annotations), the description covers the primary purpose and the trickiest behavioral nuances. It doesn't mention the return value or error conditions, but the essential information for calling correctly is mostly present. A slight gap is the lack of guidance on how to use parent_id in conjunction with set_parent at the system level.
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?
Although schema property descriptions are tautological ('title parameter', etc.), the tool description adds real semantic value by explaining how to use sentinel values for each field, especially for parent_id and complexity. It clarifies that zero means 'no update', which is not inferable from the schema. However, it does not provide ranges or constraints for priority/complexity beyond the sentinel.
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 the specific verb 'Edit' and clearly lists the resource ('an existing item') plus the editable fields ('title, description, priority, complexity, and/or parent'). This distinctly differentiates it from siblings like new_item (create), delete_item (destroy), and set_parent (parent-only update).
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 that this tool is for editing existing items, implying it is not for creation. The note about sentinel values ('Empty string/zero means don't update', 'To clear description, use a single space') offers practical usage guidance. However, it does not explicitly contrast with alternatives such as set_parent, which could also handle parent updates.
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 'Rebuild all' behavior, the 'Empty = all' default, and the return dict with errors. However, it does not mention potential side effects (e.g., overwriting existing embeddings), required permissions, or performance impact, which is a gap for a mutation-like tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an Args section and Returns section. It is compact, with every line adding value. No redundancy or filler.
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 tool with one optional parameter and no output schema, the description fully covers invocation (parameter format, defaults) and expected result (success, processed count, errors). It is complete given the tool's simplicity and the available sibling context.
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?
The input schema only describes 'source_types' as 'source_types parameter'. The description adds critical semantics: 'Comma-separated types to rebuild (item,decision,update). Empty = all'. This provides format, allowed values, and default behavior, exceeding what the schema offers.
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 states 'Rebuild all embeddings for the current project' with a specific verb (rebuild) and resource (embeddings). It clearly distinguishes this tool from all siblings, none of which deal with rebuilding embeddings or similar maintenance operations.
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: it applies to the current project and accepts optional source_types. While it does not explicitly state when to use it vs alternatives, the unique purpose (rebuilding embeddings) makes the usage context obvious and no exclusions are needed.
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 takes full responsibility for behavioral disclosure. It specifies the return structure (Dict with success, entries list, entry_count), the ordering (timestamp desc), and the default limit. Although it doesn't explicitly state read-only semantics, 'Get' and the return description make it clear this is a non-mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and functional: a one-sentence purpose, a one-sentence composition overview, then clearly formatted Args and Returns sections. No filler or repetition; every line 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?
For a low-complexity read tool with two parameters and no output schema, the description fully covers the input semantics, default behavior, output shape, and ordering. It's sufficiently complete for an agent to invoke and interpret results without further context.
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 schema covers 100% of parameters, but the description adds value by clarifying limit's default (100) and restating item_id's role. The addition of default behavior goes beyond the schema's simple 'limit parameter' description, justifying above 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 opens with 'Get activity timeline for a specific item,' which clearly identifies the verb, resource, and scope. It further distinguishes itself by listing the unified content (status changes, decisions, updates, git commits), contrasting with sibling tools that focus on single aspects like get_status_history or get_project_timeline.
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 establishes clear context: this is for a specific item's combined timeline, implying it's the go-to for an aggregate view. However, it doesn't explicitly state when not to use it or name alternatives, so it falls short of a 5.
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 the return structure (Dict with success, entries list, entry_count), sorting order (timestamp desc), and the limit parameter's default. It does not explicitly state that it is read-only, but the verb 'Get' implies a safe read operation. This is reasonably transparent for a read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the main purpose, followed by clearly labeled Args and Returns sections. Every sentence provides essential information without 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?
Despite no output schema or annotations, the description covers the return structure and content categories. It does not explicitly mention that it uses the current project context, but the tool name and sibling set imply that. Overall, it is complete enough 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes the limit parameter only as 'limit parameter', while the description adds meaning: 'Maximum entries to return (default: 100)'. This fully explains the parameter's purpose and default value, exceeding the schema's minimal descriptor.
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 action ('Get activity timeline'), the scope ('entire project'), and the content types ('status changes, decisions, updates, and git commits'). It distinguishes from sibling tools like get_item_timeline and get_status_history by specifying project-wide scope.
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 implies usage for project-level activity overview, but does not explicitly name alternative tools or provide exclusions. It gives clear context that this is not item-specific, but doesn't mention when to use get_item_timeline instead. This meets the 'clear context, no exclusions' level.
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 the operation is a read-only listing (by using 'List'), defines the scope as the current project, and specifies that usage counts are included. It does not discuss edge cases like a missing project, but for a parameterless list operation this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no wasted words. It front-loads the action and resource, then adds the key detail about usage counts.
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 simple, parameterless listing tool, this description is complete: it states what is listed, the scope (current project), and the information returned (usage counts). No output schema is needed, and the lack of parameters makes the tool straightforward to invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no parameter semantics to clarify. The description adds no parameter detail because none is needed; the baseline of 4 applies for a parameterless tool.
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 lists all tags in the current project with usage counts, using a specific verb ('List') and resource ('tags'). It distinguishes itself from sibling tools like get_item_tags by focusing on project-wide tags rather than tags on a specific item.
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: use this to fetch all project-level tags and their usage counts. It does not explicitly name alternatives or exclusions, but the scope ('current project') and output ('usage counts') make the intended use obvious relative to sibling tag tools.
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:

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

Score Badge

Copy to your README.md:

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

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