codecks-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation3/5
Most tools have distinct purposes, but some overlap exists. For example, 'list_cards' and 'list_hand' both list cards, with the latter being a filtered subset, which could cause confusion. Similarly, 'mark_done' and 'mark_started' are clear, but 'archive_card' and 'delete_card' are distinguished by reversibility, which might not be immediately obvious. Overall, descriptions help clarify, but there is moderate overlap in card-related operations.
Naming Consistency4/5
Tool names follow a consistent verb_noun pattern throughout, such as 'create_card', 'list_cards', and 'update_cards'. Minor deviations include 'scaffold_feature' and 'split_features', which use slightly different verbs but maintain readability. The naming is largely predictable, with only a few tools breaking the pattern without causing significant confusion.
Tool Count2/5
With 38 tools, the count is excessive for a project management server, making it feel heavy and potentially overwhelming. While the domain is broad, many tools could be consolidated or omitted without losing functionality. This high number increases complexity and reduces usability for agents, indicating poor scoping.
Completeness5/5
The tool set provides comprehensive coverage for project management tasks, including CRUD operations for cards, comments, and planning, along with workflow utilities and reporting. It supports full lifecycle management from creation to archiving, with no apparent gaps. The inclusion of planning, feedback, and preference tools ensures agents can handle all core workflows without dead ends.
Average 3.1/5 across 38 of 38 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral information. It mentions 'Filters combine with AND' which is useful, but doesn't address pagination behavior (despite limit/offset parameters), authentication requirements, rate limits, or what happens when no filters are applied. For a tool with 19 parameters and no annotation coverage, this is inadequate.
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 extremely concise - just two short sentences. While this could be seen as efficient, it borders on under-specification given the tool's complexity. Every word earns its place, but more words might be needed for adequate documentation.
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 19 parameters, no annotations, no output schema, and moderate schema coverage (63%), the description is severely incomplete. It doesn't explain what 'cards' represent in this system, what the return format looks like, or provide essential context for proper usage. The complexity demands more comprehensive documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal value beyond the schema. Schema description coverage is 63%, and the description only clarifies that 'Filters combine with AND' - which helps understand how multiple parameters interact but doesn't explain individual parameters. With 19 parameters, the description should do more to compensate for the 37% coverage gap, but it doesn't.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List cards. Filters combine with AND.' is tautological - it restates the name/title without adding meaningful specificity. It doesn't clarify what 'cards' are in this context or distinguish this from other list operations like 'list_hand' or 'list_activity' among the sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'list_hand', 'get_card', and 'list_activity', there's no indication of when this general listing tool is appropriate versus more specific retrieval operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 only states 'Show recent activity feed,' which doesn't reveal any behavioral traits such as permissions needed, rate limits, pagination, or what 'recent' means. This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence ('Show recent activity feed.') with no wasted words. It's appropriately sized and front-loaded, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a list operation with one parameter), no annotations, no output schema, and low schema coverage, the description is incomplete. It lacks details on behavior, return values, and usage context, making it insufficient for effective tool selection.
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 one parameter (limit) with 0% description coverage, and the tool description doesn't mention any parameters. Since there's only one parameter and schema coverage is low, the baseline is 3, as the description doesn't add value beyond the schema but also doesn't mislead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Show recent activity feed' states the tool's purpose with a verb ('Show') and resource ('recent activity feed'), but it's vague about what 'activity' entails and doesn't distinguish it from sibling tools like list_cards or list_conversations. It provides a basic function but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools for listing items (e.g., list_cards, list_conversations), the description doesn't clarify the context or exclusions for selecting this tool, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions a 'dashboard' but doesn't specify if this is a read-only operation, what permissions are needed, how data is formatted, or any rate limits. For a tool with 4 parameters and no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that lists the dashboard categories. It's front-loaded with the tool's purpose, though it could be slightly more structured by including a verb. There's no wasted text, making it appropriately concise.
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 4 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain the return format, how categories are prioritized, or any behavioral nuances, leaving gaps for the agent to understand the tool's full context and usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all parameters (project, owner, limit, stale_days) with descriptions. The description adds no additional meaning beyond the schema, such as explaining how parameters interact or affect the dashboard output, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool provides a 'PM focus dashboard' with categories like 'blocked, stale, unassigned, and suggested next cards', which gives a general idea of what it displays. However, it lacks a specific verb (e.g., 'retrieve' or 'generate') and doesn't clearly differentiate from sibling tools like 'list_cards' or 'planning_status', making it somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or comparisons to sibling tools such as 'list_cards' or 'planning_status', leaving the agent with no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states it generates a summary. It doesn't disclose behavioral traits such as whether it's read-only, requires authentication, has rate limits, or what the output format is. This leaves significant gaps in understanding how the tool behaves beyond its basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose. It avoids unnecessary words, but could be more structured by explicitly mentioning parameters or output, though it's appropriately sized for the tool's apparent 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 no annotations, no output schema, and low schema coverage (33%), the description is incomplete. It doesn't explain return values, error handling, or how parameters interact, making it inadequate for a tool with 3 parameters and potential complexity in generating summaries.
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 33% (only 'days' has a description), so the description must compensate but doesn't add meaning for 'project' or 'owner'. It implies parameters relate to filtering (e.g., 'recently done cards'), but doesn't explain their roles beyond what's minimally inferred, resulting in a baseline score due to partial coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool generates a 'daily standup summary' with categories like 'recently done, in-progress, blocked, and hand', which gives a vague purpose. It specifies the type of output but doesn't clearly distinguish what resource it operates on (e.g., cards, projects) or how it differs from sibling tools like list_cards or list_activity, making it somewhat ambiguous.
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 on when to use this tool versus alternatives is provided. The description implies it's for daily summaries, but it doesn't specify prerequisites, context (e.g., for project management), or when not to use it, leaving the agent with minimal direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses 'No auth needed' which is useful behavioral context, and 'mechanically' implies automated or systematic updates. However, it doesn't describe what 'Update planning files' entails—whether it creates, modifies, or deletes data, what the response looks like, error handling, or side effects. For a mutation tool with 11 parameters, this leaves significant behavioral gaps.
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 appropriately concise with two sentences: the first states the purpose and auth context, the second lists operations. It's front-loaded with the core functionality. However, the operation list is somewhat dense and could benefit from grouping or categorization, but it remains efficient without wasted words.
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 high complexity (11 parameters, mutation tool, no output schema, no annotations), the description is incomplete. It lacks details on parameter usage, return values, error conditions, and behavioral nuances. While it covers auth needs and operation types, it doesn't provide enough context for an agent to reliably invoke this tool, especially with many undocumented parameters and no output guidance.
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?
Schema description coverage is 0%, so the description must compensate. It lists operations ('goal, advance, phase_status, error, decision, finding, issue, log, file_changed, test') which maps to the 'operation' parameter's enum values, adding semantic meaning. However, it doesn't explain the other 10 parameters (e.g., 'text', 'phase', 'status'), their relationships to operations, or provide examples. With 11 total parameters and only 1 addressed, the description inadequately compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Update planning files mechanically' with a specific verb ('Update') and resource ('planning files'). It distinguishes from siblings like 'planning_init', 'planning_status', and 'planning_measure' by focusing on mechanical updates rather than initialization, status checks, or measurements. However, it doesn't fully differentiate from 'update_cards' which might also update planning-related items.
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 minimal guidance: 'No auth needed' indicates when authentication isn't required, but it doesn't specify when to use this tool versus alternatives like 'update_cards' or other planning tools. It lists operations but doesn't explain when to choose specific operations or provide context for tool selection. No explicit alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Create' which implies a write/mutation operation, but doesn't address permissions, side effects (e.g., whether this affects existing cards), error conditions, or response format. This is inadequate for a tool with 13 parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and resource. There's no wasted verbiage, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (13 parameters, mutation operation), lack of annotations, and no output schema, the description is insufficient. It doesn't explain behavioral aspects, parameter meanings, or usage context, leaving significant gaps for an agent to operate effectively.
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?
Schema description coverage is low (23%), with only 3 of 13 parameters having descriptions. The description mentions 'Hero card with Code/Design/Art/Audio sub-cards', which hints at the purpose of some parameters (e.g., hero_deck, code_deck), but doesn't explain most parameters like 'owner', 'priority', 'effort', or 'allow_duplicate'. It fails to compensate for the schema's gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the specific resource ('a Hero card with Code/Design/Art/Audio sub-cards'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'create_card' or 'split_features', which might also involve card creation or feature management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context (e.g., project planning phases), or comparisons to siblings like 'create_card' or 'split_features', leaving the agent to infer usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Add') but doesn't explain what happens—e.g., whether this is a mutation, if it requires permissions, if cards are duplicated or moved, or what the expected outcome is. This leaves critical behavioral traits unspecified for a tool that likely modifies state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words—it's front-loaded and efficiently conveys the core action. Every part of the sentence earns its place by specifying what's being added and where.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a mutation tool with no annotations and no output schema), the description is incomplete. It doesn't address behavioral aspects like side effects, error conditions, or return values, leaving gaps that could hinder an AI agent's ability to use it correctly in context with siblings like 'remove_from_hand'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't add any meaning beyond the input schema, which has 100% coverage and fully documents the single parameter 'card_ids' as an array of UUIDs. Since schema coverage is high, the baseline score is 3, as the description doesn't compensate but also doesn't detract from the schema's documentation.
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 ('Add') and resource ('cards to the user's hand'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'create_card' (which might create new cards) or 'remove_from_hand' (the inverse operation), so it doesn't fully distinguish from 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?
The description provides no guidance on when to use this tool versus alternatives. For example, it doesn't specify if this is for adding existing cards (as implied by 'card_ids') versus creating new ones, or mention prerequisites like cards needing to be in a deck first. There's no explicit context or exclusions 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool performs a mutation ('close'), implying it changes state, but doesn't specify permissions required, whether the action is reversible, side effects, or what happens to the comment thread after closing. This is a significant gap for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place by conveying essential purpose without redundancy.
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 this is a mutation tool with no annotations, no output schema, and incomplete parameter documentation (50% schema coverage), the description is inadequate. It lacks behavioral details (e.g., permissions, reversibility), parameter context, and usage guidelines, leaving the agent under-informed for safe and effective tool 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 50% (only 'card_id' has a description specifying 'Full 36-char UUID'), so the description must compensate. However, it adds no parameter information beyond what's implied by the verb—it doesn't explain what 'thread_id' represents or the relationship between parameters. The baseline is 3 because the schema covers half the parameters, but the description doesn't adequately fill the gaps.
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 ('close (resolve)') and resource ('a comment thread'), making the purpose immediately understandable. It distinguishes from sibling 'reopen_comment' by specifying the opposite action, though it doesn't explicitly differentiate from other comment-related tools like 'create_comment' or 'reply_comment' beyond the verb itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., comment must be open), exclusions, or relationships with siblings like 'reopen_comment' (which logically reverses this action). Usage is implied by the verb alone, leaving the agent to infer 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool creates a new comment thread but omits critical details like whether this requires specific permissions, if it's idempotent, what happens on failure, or the expected response format. This leaves significant gaps for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff or redundancy. It is front-loaded and appropriately sized for its simple function, earning a perfect 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?
Given the tool's mutation nature (creating a comment), lack of annotations, and no output schema, the description is insufficient. It fails to address behavioral risks, response expectations, or error handling, making it incomplete for safe and effective agent use despite the clear schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting both parameters ('card_id' as a UUID and 'message' as the comment text). The description adds no additional semantic context beyond what the schema provides, so it meets the baseline of 3 for adequate but not enhanced parameter understanding.
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 ('Start a new comment thread') and the target resource ('on a card'), which is specific and unambiguous. However, it does not differentiate from sibling tools like 'reply_comment' or 'close_comment', which limits its score to 4 instead of 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?
The description provides no guidance on when to use this tool versus alternatives such as 'reply_comment' for existing threads or 'close_comment' for ending discussions. It lacks context about prerequisites, permissions, or typical scenarios, offering only basic functional intent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions what data is retrieved but doesn't cover critical aspects like whether this is a read-only operation (implied by 'Get' but not explicit), authentication requirements, rate limits, error conditions, or response format. For a tool with 4 parameters and no annotation coverage, this leaves significant behavioral 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, efficient sentence that front-loads the core purpose. Every element earns its place by specifying what details are retrieved. There's no redundancy or unnecessary elaboration, making it optimally concise for a retrieval 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?
For a tool with 4 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain the return format, error handling, authentication needs, or how the boolean parameters interact. While concise, it leaves too many contextual gaps for proper agent understanding of this data retrieval operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75% (3 of 4 parameters have descriptions), so the schema does substantial work. The description adds minimal value beyond the schema - it mentions 'content, checklist, sub-cards, conversations, hand status' which loosely maps to the boolean parameters but doesn't provide additional context about parameter interactions or usage scenarios. This meets the baseline for good 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 verb 'Get' and resource 'full card details', specifying what information is retrieved (content, checklist, sub-cards, conversations, hand status). It distinguishes this from sibling tools like 'list_cards' which likely returns summaries rather than full details. However, it doesn't explicitly differentiate from other detail-retrieval tools if they exist, keeping it at 4 rather than 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to use 'get_card' versus 'list_cards' for overviews, or when to use it versus other detail-oriented tools. There's no context about prerequisites, timing, or exclusions, leaving the agent with minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool lists comment threads with messages and thread IDs, implying a read-only operation, but doesn't specify if it's paginated, rate-limited, requires authentication, or what happens with invalid inputs. For a tool with no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('List all comment threads on a card') and adds necessary detail ('with messages and thread IDs'). There is no wasted text, and it directly communicates the tool's function without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a read operation with one parameter) and lack of annotations and output schema, the description is incomplete. It doesn't explain return values (e.g., format of listed threads), error handling, or behavioral constraints. For a tool with no structured output documentation, the description should provide more context to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'card_id' parameter fully documented as a 'Full 36-char UUID'. The description adds no additional meaning beyond this, such as examples or context for where to obtain the card_id. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all comment threads on a card'), specifying what the tool does. It distinguishes itself from siblings like 'list_cards' or 'list_activity' by focusing on comment threads per card. However, it doesn't explicitly differentiate from 'reply_comment' or 'close_comment', which are related but not direct alternatives, keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid card_id), exclusions, or compare to siblings like 'list_activity' (which might include comments) or 'get_card' (which might have comment data). This lack of context leaves the agent to infer usage based on 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 provided, the description carries full burden for behavioral disclosure. 'Mark cards as done' implies a mutation operation, but it doesn't specify whether this is reversible, what permissions are required, if it triggers notifications, or how it affects card state (e.g., moves to a 'done' lane). The description provides minimal behavioral context beyond the basic 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 extremely concise at just three words ('Mark cards as done'), with zero wasted language. It's front-loaded with the core action and resource. Every word earns its place in communicating the essential 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 mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'done' means operationally, what the tool returns, whether changes are permanent, or error conditions. Given the complexity of state-changing operations and lack of structured metadata, the description should provide more contextual information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'card_ids' documented as 'Full 36-char UUIDs'. The description adds no additional parameter information beyond what the schema provides. According to scoring rules, with high schema coverage (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Mark cards as done' clearly states the action (mark) and resource (cards) with a specific status outcome (done). It distinguishes from sibling tools like 'archive_card' or 'mark_started' by focusing on completion status rather than archiving or starting. However, it doesn't specify what 'done' means in this system context.
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 'archive_card' or 'mark_started'. The description doesn't mention prerequisites (e.g., cards must exist, be in a certain state) or exclusions. It's a basic statement with no contextual usage information.
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. 'Mark cards as started' implies a mutation (state change), but it doesn't disclose behavioral traits such as required permissions, whether the operation is idempotent, what happens if cards are already started, or error conditions. This is a significant gap for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It is front-loaded and appropriately sized for the tool's apparent simplicity, earning its place by clearly stating 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 this is a mutation tool with no annotations, no output schema, and incomplete behavioral disclosure, the description is inadequate. It should explain more about the operation's effects, error handling, or return values to be complete enough for safe agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'card_ids' documented as 'Full 36-char UUIDs'. The description adds no additional meaning beyond what the schema provides (e.g., no context on card selection or constraints). Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Mark cards as started' clearly states the verb ('mark') and resource ('cards') with the specific state change ('as started'). It distinguishes from obvious siblings like 'mark_done' by specifying the opposite state, though it doesn't explicitly differentiate from all other card-related tools like 'archive_card' or 'update_cards'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., cards must exist, be in a specific state), exclusions (e.g., not for archived cards), or comparisons to siblings like 'update_cards' or 'mark_done' for state transitions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Remove') but doesn't clarify if this is reversible, requires specific permissions, affects game state, or has side effects. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero waste—it states the core action and target without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., reversibility, permissions), usage context relative to siblings, and expected outcomes, making it inadequate for informed tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'card_ids' fully documented in the schema as 'Full 36-char UUIDs'. The description adds no additional parameter information beyond what the schema provides, so it meets the baseline for high schema coverage without compensating 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 action ('Remove') and target resource ('cards from the user's hand'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'delete_card' or 'archive_card', which might also remove cards but through different mechanisms or to different destinations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'delete_card', 'archive_card', and 'list_hand', there's no indication of whether this tool is for temporary removal, permanent deletion, or other contexts, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Reopen') but doesn't cover critical aspects like permissions needed, whether it's reversible, side effects, or error conditions. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words, making it easy to parse. It's front-loaded with the core action and resource, achieving maximum clarity in minimal space.
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 mutation tool with no annotations, no output schema, and incomplete parameter documentation, the description is insufficient. It lacks details on behavior, outcomes, error handling, and relationships with sibling tools, leaving the agent under-informed.
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 50% (only 'card_id' has a description), and the description adds no parameter details beyond what's implied by the action. It doesn't explain what 'thread_id' represents or how parameters interact, leaving gaps. Baseline 3 is appropriate as the schema provides some documentation.
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 ('Reopen') and the resource ('a closed comment thread'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'close_comment' or 'reply_comment' beyond the obvious verb difference, missing an opportunity to clarify scope or relationship.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., the comment must be closed), exclusions, or how it relates to siblings like 'close_comment' or 'reply_comment', leaving the agent to infer 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('Reply to') but doesn't cover critical aspects like whether this requires authentication, what permissions are needed, if it's idempotent, what happens on success/failure, or if there are rate limits. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately scannable and efficient. Every word earns its place in conveying the essential 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 mutation tool with no annotations, no output schema, and incomplete parameter documentation (50% schema coverage), the description is inadequate. It doesn't address behavioral aspects, return values, error conditions, or usage context. The tool appears to modify data (replying to comments) but lacks necessary operational context.
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 50% (only 'thread_id' has a description). The description doesn't add any parameter-specific information beyond what's implied by the action ('reply' suggests 'message' content). It doesn't explain parameter relationships, constraints, or provide examples, so it doesn't compensate for the schema coverage gap but doesn't contradict it either.
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 ('Reply to') and resource ('an existing comment thread'), making the purpose immediately understandable. However, it doesn't differentiate this tool from potential siblings like 'create_comment' or 'close_comment', which might have overlapping functionality in a comment management system.
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. There's no mention of prerequisites (e.g., needing an existing thread), exclusions (e.g., not for creating new threads), or comparison to sibling tools like 'create_comment' or 'reopen_comment' that might handle related comment operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states 'No auth needed', which is useful, but lacks details on what 'save' entails (e.g., is it idempotent, does it create a new record, what happens on success/failure, rate limits, or response format). This leaves significant gaps 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, efficient sentence with zero waste—it directly states the action and a key condition ('No auth needed'). It's appropriately sized and front-loaded, making it easy to parse quickly.
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 mutation tool with no annotations and no output schema, the description is incomplete. It lacks information on behavioral traits (e.g., what 'save' does operationally, error handling, or response expectations), which is critical given the tool's complexity and the absence of structured data to compensate.
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 75% (3 of 4 parameters have descriptions), so the baseline is 3. The description adds no additional parameter semantics beyond what the schema provides, such as explaining the 'category' enum values or constraints on 'message' and 'context' lengths, which are already documented in 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 verb 'save' and the resource 'CLI feedback item for the development team', making the purpose specific and understandable. However, it doesn't explicitly differentiate from its sibling tool 'get_cli_feedback', which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_cli_feedback' or other feedback mechanisms. It mentions 'No auth needed', which is a usage condition but doesn't address broader 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the dry-run option, which hints at a potentially destructive operation, but doesn't explicitly state whether this tool modifies data permanently, what permissions are required, or what happens to the original feature cards. For a tool with 'split' in its name (implying mutation) and no annotations, this is a significant gap in behavioral 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 extremely concise with just two sentences, front-loading the main purpose and immediately following with a practical usage tip. Every word earns its place, with no redundant or unnecessary information, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 parameters, 3 required), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns, how splitting works, what 'lane sub-cards' are, or the implications of the various deck parameters. For a mutation tool with many parameters and no structured support, the description should provide more context to be complete.
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?
Schema description coverage is only 11%, with most parameters lacking descriptions in the schema. The description adds minimal value by mentioning 'dry_run=true' for previewing, but doesn't explain the purpose of other parameters like 'deck,' 'code_deck,' 'design_deck,' or the various skip options. Given the low schema coverage, the description fails to compensate adequately for the undocumented 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 the action ('batch-split') and target resource ('unsplit feature cards into lane sub-cards'), providing a specific verb+resource combination. It distinguishes this from other tools by focusing on splitting operations rather than creation, deletion, or listing. However, it doesn't explicitly differentiate from potential similar tools like 'scaffold_feature' which might also manipulate feature cards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance by mentioning 'dry_run=true to preview,' suggesting this tool should be used with caution and previewed first. However, it doesn't explicitly state when to use this tool versus alternatives like 'scaffold_feature' or 'update_cards,' nor does it provide context about prerequisites or exclusions beyond the dry-run suggestion.
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 implies a read-only operation ('Get') but doesn't disclose behavioral traits like authentication requirements, rate limits, error conditions, or what 'current' means (e.g., session-based vs. system-wide). For a tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get current account info') and adds specifics in parentheses. There's zero waste—every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain the return format (e.g., structure of name, id, email, role), potential errors, or dependencies. For a tool in a complex server with many siblings, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter info, which is appropriate. Baseline is 4 for 0 parameters, as it avoids unnecessary 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 ('Get') and resource ('current account info') with specific attributes listed (name, id, email, role). It distinguishes from siblings like 'get_card' or 'list_decks' by focusing on account-level data. However, it doesn't explicitly differentiate from potential account-related siblings (none exist in the list), so it's not a perfect 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication state), exclusions, or compare to other tools for account info. With many sibling tools present, this lack of context is a significant gap.
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. 'Restore' implies a mutation operation, but it doesn't disclose behavioral traits such as required permissions, whether changes are reversible, error conditions (e.g., invalid card_id), or side effects. The description is minimal and lacks critical operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse. Every word earns its place, and there's no unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavior, error handling, and return values, which are essential for an agent to use the tool correctly. The description is too minimal for a tool that modifies state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'card_id' documented as a 'Full 36-char UUID'. The description doesn't add meaning beyond the schema, but with only one parameter and high coverage, the baseline is 4. No additional param info is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Restore') and resource ('an archived card'), making the purpose unambiguous. It distinguishes from 'archive_card' by indicating the opposite action, though it doesn't explicitly mention sibling tools. The description is specific but could be more precise about what 'restore' entails.
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 or prerequisites. It doesn't mention if the card must be archived first, what happens if it's already unarchived, or how it relates to tools like 'get_card' or 'update_cards'. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Update' implies mutation, it doesn't address critical aspects like permissions needed, whether updates are atomic or batched, error handling (though 'continue_on_error' parameter exists), or what happens when updating multiple cards versus single cards. The description adds minimal behavioral context beyond the basic 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 extremely concise - just two sentences that directly state the purpose and provide specific examples. Every word earns its place with zero redundancy. The structure is front-loaded with the core purpose followed by clarifying detail about 'Doc cards'.
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 mutation tool with 13 parameters, no annotations, and no output schema, the description is inadequate. It doesn't address the tool's behavioral characteristics, error scenarios, permissions, or return values. While it provides some parameter context, it leaves too many gaps for an agent to confidently use this tool without trial and error.
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?
With 54% schema description coverage, the description adds significant value by specifying which properties can be updated for 'Doc cards' (owner/tags/milestone/deck/title/content/hero). This provides semantic context that the schema alone doesn't offer, though it doesn't cover all 13 parameters. The description effectively compensates for the schema's partial coverage by highlighting key updatable fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('card properties'), and provides specific examples of what can be updated for 'Doc cards'. However, it doesn't explicitly distinguish this tool from other card-modification siblings like 'archive_card', 'delete_card', or 'mark_done', which reduces it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools that modify cards (e.g., 'archive_card', 'mark_done', 'create_card'), there's no indication of when this general update tool is preferred over more specific operations. The mention of 'Doc cards' implies some context but doesn't establish clear usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Create a new card' which implies a write/mutation operation, but doesn't disclose behavioral traits like required permissions, whether creation is idempotent, error handling, or rate limits. The description adds minimal context beyond the basic action, leaving significant gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and uses two concise sentences to add key usage details. Every sentence earns its place by providing essential information without waste, making it efficiently structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of an 8-parameter mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects, doesn't explain return values or errors, and leaves parameters like 'severity' and 'allow_duplicate' unexplained. For a tool of this nature, more comprehensive guidance is needed.
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 63%, with parameters like 'project' and 'allow_duplicate' lacking descriptions in the schema. The description adds value by explaining 'deck/project' for placement and 'parent' for nesting, but doesn't cover all parameters or provide deeper semantics for undocumented ones like 'severity' or 'allow_duplicate'. This partially compensates but doesn't fully bridge the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create') and resource ('card'), specifying it's a new card. It distinguishes from siblings like 'update_cards' or 'archive_card' by focusing on creation. However, it doesn't explicitly differentiate from 'scaffold_feature' or other creation-like tools, keeping it at 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning 'Set deck/project to place it' and 'Use parent to nest as sub-card', suggesting context for placement. However, it lacks explicit guidance on when to use this tool versus alternatives like 'scaffold_feature' or prerequisites, leaving usage somewhat implied rather than clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only mentions the optional 'include_card_counts' parameter without describing what the tool returns (e.g., format, pagination, permissions needed, or rate limits). For a list operation with zero annotation coverage, this is insufficient.
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 with two sentences that directly address the tool's function and key parameter. Every word serves a purpose, and it's front-loaded with the main action, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and parameter effect but lacks details on return values, error handling, or integration with siblings, leaving 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?
The description adds meaningful context for the single parameter by explaining that setting 'include_card_counts=True' provides 'per-deck counts'. Since schema description coverage is 0% and there's only one parameter, this adequately compensates, though it doesn't detail default behavior or other nuances.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all decks'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_cards' or 'list_projects' beyond the resource name, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'list_cards' or 'list_projects'. It mentions the 'include_card_counts' parameter but doesn't explain when to set it to true versus false, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions sorting by 'hand order', which adds some behavioral context, but lacks details on permissions, rate limits, pagination, or what happens if the hand is empty. For a read operation with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('List cards in the user's hand') and adds clarifying details ('personal work queue, sorted by hand order') without any wasted words. Every part contributes meaning, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is minimally adequate. It explains what the tool does and the sorting behavior, but as a read operation with no annotations, it could benefit from more context on permissions or output format to be fully complete 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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately adds no parameter details, focusing instead on the tool's purpose and behavior, which aligns with the baseline expectation for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List cards') and the target resource ('in the user's hand'), with the clarifying note that this refers to a 'personal work queue'. It distinguishes from generic list tools like 'list_cards' by specifying the hand context, though it doesn't explicitly contrast with 'remove_from_hand' or 'add_to_hand'.
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 on when to use this tool versus alternatives. While it implies usage for viewing the hand's contents, it doesn't mention when to choose this over 'list_cards' (which might list all cards) or other sibling tools, nor does it specify 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 the full burden of behavioral disclosure. It states the tool lists milestones with card counts, implying a read-only operation, but doesn't cover critical aspects like pagination, rate limits, authentication needs, or error handling. For a tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('List all milestones') and adds a useful detail ('with card counts'). There is no wasted verbiage, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but has gaps. It explains what the tool does and includes card counts, but lacks usage guidelines and behavioral details like response format or limitations. This makes it minimally viable 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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds value by specifying that card counts are included in the output, which is semantic information beyond the schema. Baseline is 4 for 0 parameters, as it compensates appropriately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('milestones'), specifying what the tool does. It distinguishes itself from siblings like 'list_cards' or 'list_projects' by focusing on milestones. However, it doesn't explicitly differentiate from potential similar tools (e.g., if there were a 'get_milestones' tool), keeping it at 4 rather than 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context (e.g., after creating a project), or exclusions (e.g., not for filtered lists). With siblings like 'list_cards' and 'list_projects', the lack of comparative guidance is a clear gap.
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 'List all projects with deck info', implying a read-only operation that returns a list, but it doesn't disclose behavioral traits like pagination, sorting, filtering, rate limits, or authentication needs. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'List all projects with deck info.' It is front-loaded with the core action and resource, with no wasted words. Every part of the sentence earns its place by specifying the scope ('all projects') and additional info ('with deck info').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple list operation with 0 parameters), no annotations, and no output schema, the description is minimally complete. It states what the tool does but lacks details on behavior, output format, or usage context. For a list tool, this is adequate but leaves clear gaps, such as not explaining what 'deck info' includes or how results are structured.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics beyond what the schema provides. Baseline is 4 for 0 parameters, as it appropriately avoids unnecessary 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 verb 'List' and the resource 'projects', specifying that it includes 'deck info'. It distinguishes from siblings like 'list_decks' (which lists decks) and 'list_cards' (which lists cards). However, it doesn't explicitly differentiate from 'list_activity' or 'list_conversations', which might also involve projects indirectly, so it's not fully specific about 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. It doesn't mention any prerequisites, context, or exclusions, such as whether it's for active projects only or includes archived ones. With siblings like 'list_decks' and 'list_cards', there's no indication of when to prefer this tool over those.
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 implies a read-only operation ('List') but doesn't disclose behavioral traits like pagination, sorting, error handling, or rate limits. The phrase 'sanctioned taxonomy' hints at governance but lacks detail on what that entails operationally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('List project-level tags') and adds clarifying detail without waste. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 0 parameters and no output schema, the description is adequate for a simple list tool but incomplete. It lacks details on return format, error cases, or the implications of 'sanctioned taxonomy'. With no annotations, more behavioral context would improve completeness for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately adds context about 'project-level' scope and 'sanctioned taxonomy', which provides semantic value beyond the empty schema. This compensates well for the lack 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 the action ('List') and resource ('project-level tags') with the clarifying detail 'sanctioned taxonomy'. It distinguishes from siblings like 'get_tag_registry' by focusing on listing rather than retrieving registry data. However, it doesn't explicitly differentiate from other list tools (e.g., 'list_cards', 'list_projects'), which slightly limits specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'list_tags' over 'get_tag_registry' or other list tools, nor does it specify any prerequisites or exclusions. This leaves the agent without contextual usage 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 provided, the description carries the full burden. It discloses that no authentication is needed, which is useful behavioral context. However, it doesn't mention whether this is a read-only or write operation, potential side effects, or how the data is stored/accessed, leaving gaps in behavioral understanding.
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 with two short sentences that directly state the tool's function and an important behavioral note ('No auth needed'). Every word serves a purpose, and it's front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and a simple single parameter with full schema coverage, the description is minimally adequate. It covers the basic purpose and one behavioral aspect but lacks details on usage context, return values, or error handling, which could be helpful for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the 'observations' parameter fully documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 without compensating for any gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Save') and resource ('observed workflow patterns from current session'), making the purpose understandable. However, it doesn't explicitly differentiate from the sibling tool 'get_workflow_preferences' beyond the save vs. get distinction, which is why it doesn't reach 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?
The description provides no guidance on when to use this tool versus alternatives like 'get_workflow_preferences' or other data storage tools. It mentions 'No auth needed', which is a prerequisite, but lacks explicit when/when-not scenarios or comparisons to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds value by stating 'No auth needed', which clarifies authentication requirements, but it doesn't cover other behavioral traits like rate limits, response format, or potential side effects. The description is minimal but doesn't contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two sentences that directly address the tool's purpose and an important behavioral trait ('No auth needed'). It's front-loaded with the core functionality and wastes no words, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 optional parameter, no output schema, no annotations), the description is minimally adequate. It covers the purpose and an authentication detail, but for a tool that likely returns metadata, it could benefit from mentioning the return format or scope. Without an output schema, the description doesn't fully compensate for the lack of structured output information.
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 1 parameter with 100% description coverage, so the schema already documents the parameter fully. The description doesn't add any parameter-specific information beyond what's in the schema, but with 0 required parameters and high schema coverage, a baseline of 3 is appropriate. The score is elevated to 4 because the tool has only one optional parameter, making the description's lack of parameter details less critical.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'local lane (deck category) definitions and metadata', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_tag_registry' or 'list_decks', which might have overlapping or related functions.
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 includes 'No auth needed', which provides some context on prerequisites, but it lacks explicit guidance on when to use this tool versus alternatives. There's no mention of when-not-to-use scenarios or comparisons with sibling tools like 'list_decks' or 'get_tag_registry', leaving usage unclear.
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 adds some behavioral context by stating 'No auth needed,' which is useful for understanding access requirements. However, it lacks details on response format, error handling, or any other operational traits, making it minimally adequate but incomplete.
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 with two short sentences that directly state the purpose and an important behavioral note ('No auth needed'). There is no wasted language, and it's front-loaded with the core action, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but minimal. It covers the basic purpose and an auth note, but for a tool that likely returns a guide, more context on the content or format would be helpful, especially without an output schema. It's complete enough to be usable but lacks depth.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here, but it also doesn't compensate for any gaps since there are none. A baseline of 4 is given as it meets expectations for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('PM session methodology guide'), making the purpose understandable. However, it doesn't differentiate this tool from potential siblings like 'get_account' or 'get_card' that also retrieve resources, leaving room for ambiguity about why this specific guide is needed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools like 'get_account' or 'list_projects', there's no indication of context, prerequisites, or exclusions, leaving the agent to guess based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'No auth needed,' which is useful context for access requirements. However, it doesn't describe other behavioral traits like rate limits, error handling, or what 'compact' entails (e.g., if it's a summary vs. detailed view), leaving gaps for a tool with potential complexity in planning status.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded, using a single sentence that efficiently conveys the purpose and key constraint ('No auth needed'). Every word adds value without redundancy, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 0 parameters, the description is minimal but covers the core purpose and auth aspect. However, for a tool named 'planning_status' in a context with many planning-related siblings, it lacks details on what 'compact' means, how it differs from other status tools, or what the output includes, leaving room for improvement in guiding the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, and the baseline for 0 parameters is 4, as it avoids unnecessary details while being complete for this aspect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('compact planning status'), specifying what information is retrieved (goal, phases, decisions, errors, token count). It distinguishes from siblings like 'planning_init' or 'planning_update' by focusing on status retrieval rather than initialization or modification, though it doesn't explicitly contrast with all planning-related tools.
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 minimal guidance with 'No auth needed,' indicating it's accessible without authentication. However, it lacks explicit when-to-use instructions, such as when to choose this over other planning tools (e.g., 'planning_measure') or general status tools (e.g., 'list_activity'), and doesn't mention prerequisites or exclusions beyond the auth note.
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 full burden. It discloses the key behavioral trait of reversibility, which is crucial for understanding this as a non-destructive operation. However, it lacks details on permissions needed, side effects (e.g., visibility changes), or response format, leaving gaps in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three words, front-loading the core action and including a critical qualifier ('reversible') in parentheses. Every element earns its place with zero wasted words, making it highly efficient for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (a mutation with reversibility), no annotations, and no output schema, the description is minimally adequate. It covers the core action and key trait but lacks details on permissions, side effects, or return values, which could hinder an agent's ability to use it correctly in all scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the schema fully documenting the single 'card_id' parameter as a 36-char UUID. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 without compensating or adding 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 action ('Archive') and resource ('a card'), making the purpose immediately understandable. It distinguishes from sibling 'unarchive_card' by specifying direction, though it doesn't explicitly mention other siblings like 'delete_card' for permanent removal.
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 context by noting '(reversible)', suggesting this is a soft delete alternative to permanent deletion tools. However, it doesn't explicitly state when to use this versus 'delete_card' or other card modification tools, nor does it mention prerequisites like card existence or permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'No auth needed,' which is a useful behavioral trait, and implies a read-only operation ('Read'), but it doesn't cover other aspects like rate limits, pagination, or response format. This leaves gaps in transparency for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two sentences that directly convey key information: the action, resource, optional filtering, and an auth note. Every sentence earns its place without any wasted words, making it front-loaded and 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 the tool's low complexity (1 optional parameter) and no output schema, the description is somewhat complete but lacks details on return values or behavioral constraints. With no annotations, it should ideally cover more aspects like response format or error handling to be fully 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 input schema has 1 parameter with 0% description coverage, but the description adds value by explaining that 'category' is used for optional filtering. However, it doesn't detail the enum values or provide further semantic context beyond what the schema's enum implies, so it partially compensates but not fully.
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 ('Read') and resource ('saved CLI feedback items'), making the purpose evident. However, it doesn't explicitly differentiate this tool from potential siblings like 'list_activity' or 'list_conversations', which might also involve reading data, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context by mentioning optional filtering by category, but it lacks explicit guidance on when to use this tool versus alternatives (e.g., compared to other 'list_' tools). It also doesn't specify prerequisites or exclusions, leaving usage somewhat implied.
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 full burden. It discloses the 'No auth needed' behavioral trait, which is valuable. However, it doesn't describe return format, pagination, error conditions, or whether this is a read-only operation (implied by 'Get' but not explicit). Some behavioral context is missing for a tool with potential complexity in taxonomy structure.
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 concise sentences with zero waste. First sentence states purpose and scope, second provides critical behavioral context ('No auth needed'). Every word earns its place, and information is front-loaded appropriately.
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 read-only tool with no annotations, no output schema, and 100% schema coverage, the description is adequate but has gaps. It covers purpose and one behavioral trait, but doesn't explain return values or potential complexities in the taxonomy structure. Given the sibling tools include multiple registry/listing tools, more contextual differentiation would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with one parameter fully documented in the schema. The description adds no parameter-specific information beyond what the schema provides. The baseline is 3 when schema does the heavy lifting, but the description doesn't compensate with additional context about parameter usage or effects.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('local tag taxonomy') with specific components (definitions, hero tags, lane-tag mappings). It distinguishes from sibling 'list_tags' by focusing on taxonomy/metadata rather than listing tag instances. However, it doesn't explicitly contrast with 'get_lane_registry' which might overlap in lane-tag mappings.
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 retrieving taxonomy/metadata rather than tag instances (contrasted with 'list_tags'), but doesn't explicitly state when to use vs. alternatives like 'get_lane_registry' or 'get_pm_playbook'. The 'No auth needed' provides some context but not comprehensive guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that no authentication is needed, which is useful behavioral context, but it lacks details on rate limits, error handling, or what 'Load' entails (e.g., format, scope). It does not contradict annotations, as there are none.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with zero waste, front-loaded with the core purpose and followed by a key behavioral note. Every word earns its place, 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 no annotations, no output schema, and 0 parameters, the description is minimal but covers the basics: purpose and an auth note. However, for a tool that loads preferences, it lacks details on return values, data format, or potential side effects, leaving gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add param info, which is acceptable here, but it could have mentioned any implicit parameters (none exist), keeping it slightly below perfect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Load' and resource 'user workflow preferences from past sessions', making the purpose specific. However, it does not explicitly differentiate from sibling tools like 'save_workflow_preferences' or other get/list tools, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some context with 'No auth needed', implying usage when authentication is not required, but it does not specify when to use this tool versus alternatives like 'get_account' or other preference-related tools. Usage is implied rather than explicitly guided.
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 of behavioral disclosure. It adds valuable context: 'No auth needed' clarifies permission requirements, and the operations list gives insight into what the tool can do. However, it lacks details on rate limits, side effects, or output format, preventing a score of 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded: the first sentence states the core purpose, followed by key behavioral context and operations. Every sentence earns its place with no wasted words, making it easy for an AI agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (1 parameter with enum, no output schema, no annotations), the description is adequate but has gaps. It covers purpose, auth, and operations, but lacks details on output format, error handling, or how it differs from siblings. This makes it minimally viable but not fully complete for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists operations ('snapshot, report, compare_templates'), which aligns with the enum in the input schema. With 0% schema description coverage, the description compensates by explaining the parameter's purpose. However, it doesn't provide additional semantics like what each operation does or expected inputs/outputs, so it meets the baseline but doesn't add significant 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's purpose: 'Track token usage of planning files over time.' It specifies the resource (planning files) and the action (track token usage over time). However, it doesn't explicitly differentiate from sibling tools like 'planning_status' or 'planning_update', which prevents a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context by listing operations ('snapshot, report, compare_templates'), which implies when to use specific functions. However, it doesn't offer explicit guidance on when to choose this tool over alternatives (e.g., 'planning_status' or 'planning_update') or mention any prerequisites or exclusions beyond 'No auth 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 provided, the description carries full burden. It discloses that no authentication is required and creates specific files in the project root. However, it doesn't mention potential side effects (e.g., file system changes), error conditions, or what happens if files already exist (though the 'force' parameter hints at this). The description adds meaningful behavioral context beyond the minimal schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence) and front-loaded with the core purpose. Every word earns its place: 'Create' (action), 'lean planning files' (what), specific file names (which files), 'project root' (where), and 'No auth needed' (important constraint). Zero waste.
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 single-parameter tool with no annotations and no output schema, the description provides good coverage of purpose and behavioral context. It mentions authentication requirements and file creation specifics. However, it doesn't describe what the tool returns (success/failure indicators) or potential error cases, leaving some gaps in 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?
Schema description coverage is 100% (the 'force' parameter is fully documented in the schema). The description doesn't add any parameter-specific information beyond what's in the schema. According to scoring rules, with high schema coverage (>80%), the baseline is 3 even with no param info in description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create lean planning files') and specifies the resources (task_plan.md, findings.md, progress.md) and location (project root). It distinguishes from siblings like planning_measure, planning_status, and planning_update by focusing on file creation rather than measurement or updates. However, it doesn't explicitly contrast with scaffold_feature which might also create files.
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 context (initial project planning) but doesn't explicitly state when to use this versus alternatives like planning_update or scaffold_feature. It mentions 'No auth needed' which provides some usage context, but lacks explicit guidance on prerequisites or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates the irreversible nature of the operation ('Permanently delete... Cannot be undone'), which is crucial for a destructive tool. However, it doesn't mention potential side effects (e.g., what happens to associated data) or error conditions.
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 with just two sentences that each serve a distinct purpose: the first states the core action, the second provides critical usage guidance. There is zero wasted language, and the most important information (permanent deletion) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description does well by emphasizing irreversibility and providing alternative guidance. However, it could be more complete by mentioning what 'permanently delete' entails (e.g., removal from all views, data cleanup) or potential error cases, though the concise approach is generally effective.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'card_id' fully documented as a 'Full 36-char UUID.' The description adds no additional parameter information beyond what the schema provides, so it meets the baseline for 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 specific action ('permanently delete') and resource ('a card'), distinguishing it from sibling tools like archive_card. It uses precise language that leaves no ambiguity 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides when-not-to-use guidance by stating 'use archive_card if reversibility needed,' directly naming an alternative sibling tool. This gives clear context for choosing between destructive and non-destructive options.
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:

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

Score Badge

Copy to your README.md:

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

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