Kelvia MCP Server

Server Quality Checklist

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

Latest release: v1.0.2
Disambiguation4/5
While the tool names are largely clear and map to distinct actions, a few sets (list_tasks/list_daily_tasks/list_calendar_tasks; list_board_tags/list_tags) overlap in purpose and rely heavily on descriptions to disambiguate. Overall, an agent can distinguish them with careful reading, but some names are similar enough to risk misselection.
Naming Consistency5/5
All tools use the snake_case verb_noun pattern consistently (create_board, update_task, list_board_members, delete_daily_plan_block). Even multi-word resources (daily_plan_blocks, board_invitations) follow the same convention. No mixing of styles or cryptic abbreviations.
Tool Count2/5
At 58 tools, the server is excessively large for a typical MCP surface. While the coverage is comprehensive, the sheer number makes it unwieldy for agents to select from, and many tools could be consolidated (e.g., a single 'daily_plan_block' CRUD set). This exceeds the recommended 3-15 range by a wide margin.
Completeness5/5
The tool set provides full CRUD coverage for boards, tasks, stages, tags, comments, worklogs, invitations, and daily plan blocks, with additional lifecycle operations (archive, unarchive, reorder, start/complete/reopen). There are no obvious missing operations for the stated project-management domain, and even niche features like task summaries and daily plans are covered.
Average 4.1/5 across 58 of 58 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 12 commits in the last 12 weeks
- Last stable release on August 10, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
This server has been verified by its author.
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?
The description simply restates the operation implied by the tool name and adds no behavioral nuance beyond the annotations (readOnlyHint=false, destructiveHint=true, idempotentHint=true). It does not clarify what archiving entails (e.g., reversibility, visibility changes, or return value), so it contributes little beyond the structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action and target. Every word carries meaning, and there is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter fully specified in the schema, and annotations declare destructive and idempotent behavior, so the structured context is strong. The description is sufficient for basic selection and invocation, though it omits when-to-use guidance and does not mention the unarchive counterpart.
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 already fully documents board_id as a required UUID, and the description's phrase 'by UUID' is redundant with the schema. No additional parameter format, constraints, or edge-case guidance is provided. Baseline 3 applies due to 100% 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 uses a specific verb ('Archive') and resource ('board') with a clear target ('by UUID'), making the action unambiguous. It does not explicitly differentiate from related operations like delete_board or unarchive_board, leaving slight ambiguity about the meaning of archive vs delete.
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 unarchive_board, delete_board, or update_board. There are no prerequisites, exclusions, or context cues beyond the bare action.
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?
The description simply states the action and adds no behavioral context beyond the annotations. It does not disclose permission requirements, effects on other board data, or error behavior. Annotations already indicate it is a non-destructive write operation, but the description adds no value here.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, highly concise with no wasted words. While it is extremely minimal, the length is appropriate for a simple rename operation, and it is 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's simplicity, the description, schema, and annotations together provide adequate context. However, the description alone is thin, omitting any mention of identifier alternatives or potential side effects. The complete schema mitigates this, but the description could be more 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 schema provides 100% coverage with descriptions for all four parameters, including the alternative board_slug identifier. The description 'Rename a board stage' adds no information beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Rename a board stage' uses a specific verb ('rename') and resource ('board stage'), clearly distinguishing it from sibling tools like update_board, delete_board_stage, or reorder_board_stages. It aligns well with the tool name and title, leaving no ambiguity about its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, alternative tools, or exclusions. The only context is the verb itself, which implies usage, but no explicit 'when to use' or 'when not to use' is given.
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?
Annotations already communicate destructiveHint=true and readOnlyHint=false. The description adds no extra behavioral context, such as whether tasks in the stage are deleted, whether the stage must be empty, or any permission requirements. It is not contradictory, but it contributes nothing beyond the 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 a single, front-loaded sentence with no redundancy or filler. It is as concise as possible while still stating the core purpose.
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 destructive operation, the description is thin: it does not mention consequences like task deletion, whether the operation requires an empty stage, or how board_id and board_slug interact. The annotations and schema partially compensate, but the description alone leaves meaningful gaps about the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters with clear descriptions (board_id, stage_id, board_slug), so the description does not need to add parameter detail. It provides no additional semantics, but the schema is sufficient; hence the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('a board stage'), which unambiguously distinguishes it from sibling stage operations like create, update, reorder, start, or complete. It is specific and uses the expected verb-resource structure.
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, nor does it mention prerequisites, side effects, or when not to use it. It merely restates the action without any contextual 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?
The description adds no behavioral context beyond the action itself. Annotations indicate the tool is idempotent and non-destructive, but the description does not explain effects such as restoring board visibility or potential failure if the board is not archived. No contradiction with annotations, but no added value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is front-loaded and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and annotations cover safety, but the description lacks usage guidance and any indication of return values or edge cases. It is adequate for basic invocation but incomplete for a fully informed 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 fully describes the single parameter board_id with 'Board UUID', and schema description coverage is 100%. The description's reference to UUID adds no extra meaning beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (unarchive), the resource (board), and the method of identification (by UUID). It is specific and naturally distinguishes from sibling tools like archive_board.
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 offers no guidance on when to use this tool versus alternatives. It does not mention that it is the inverse of archive_board or any context about restoring archived boards.
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?
The description says 'Create (or fetch, if it already exists)' which implies idempotent behavior (repeated calls safely fetch the existing stage). However, the annotation idempotentHint is false, indicating the tool is not idempotent. This contradicts the annotation, so the description is misleading about a core behavioral trait.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, starts with the action, and packs essential information (create-or-fetch, purpose, role requirement) without any filler words or redundant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description omits critical context: neither board_id nor board_slug is required in the schema, yet the description says 'for a board' without explaining how the board is determined. There is also no output schema, so the description should describe what the tool returns, but it doesn't. The idempotency contradiction further degrades completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has descriptions for all four parameters (100% coverage), so the schema carries the parameter meaning. The tool description does not add any additional parameter-specific guidance beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Create (or fetch)') applied to a specific resource ('the special backlog stage for a board'), and adds distinguishing semantic context ('holds tasks that aren't part of any active/planned stage'). This differentiates it from sibling tools like create_board_stage, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is for the special backlog stage, not a generic stage, and it requires ADMIN/OWNER role. However, it does not explicitly mention alternatives or when not to use this tool (e.g., for normal stages use create_board_stage).
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?
Annotations already indicate readOnlyHint=false and idempotentHint=true, covering the write nature and idempotency. The description adds the 'kanban drag-and-drop equivalent' analogy, which provides some behavioral context but doesn't disclose effects on other tasks or position handling beyond 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 a single concise sentence with no filler. It front-loads the action and uses a familiar analogy, making it highly scannable and effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple reorder tool, the description is adequate but lacks clarity on cross-column moves (despite column_id being required) and doesn't mention return values or edge cases. The openWorldHint and idempotentHint are not explained, leaving some context gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented. The description doesn't add meaning beyond the schema; it merely restates the general operation. This matches the baseline for full 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 ('Move/reorder') and resource ('a task'), and adds the kanban drag-and-drop analogy for context. It distinguishes from sibling tools like reorder_board_stages and reorder_daily_plan_blocks by focusing on tasks. However, the phrase 'inside a column' slightly conflicts with the column_id parameter which could imply cross-column movement, making it not perfectly precise.
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 reordering tasks in a kanban board but provides no explicit when-to-use guidance or comparison with alternatives. It doesn't mention exclusions or prerequisites, so the context is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, indicating a mutating, non-idempotent operation. The description adds the validation constraint that minutes must be >0 and ≤1440, which is useful but already present in the schema. It also states the return value (created worklog entry), which is not in annotations. This adds some context beyond annotations but does not reveal other side effects or authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that fronts the core purpose ('Log time spent on a task'), then adds the key validation rule and return value. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, no output schema, annotations present), the description covers the essential purpose, a critical constraint, and the return value. The schema handles parameter details. The description is complete enough for a straightforward create operation, though it does not explain the meaning of worked_at or comment fields (handled by schema) or any side effects beyond creation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the schema. The description mentions the minutes constraint but does not add new semantics beyond what the schema already provides. The baseline of 3 is appropriate since the schema carries full weight.
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 'Log time spent on a task' uses a specific verb with a clear resource (task worklog). It distinguishes from sibling tools like update_task_worklog, delete_task_worklog, and get_task_worklogs by specifying the creation operation. The name add_task_worklog is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that updating or deleting worklogs would use different tools, nor does it specify prerequisites like task ownership or permissions. No explicit context or exclusions are given.
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?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the agent knows it's a destructive write. The description adds 'frozen' which implies the stage becomes locked, but it does not explain side effects or prerequisites. No contradiction with 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 a single concise sentence that front-loads the primary action and state. There is no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with comprehensive annotations and a 100% schema-covered parameter set, the description is sufficient. The term 'frozen' provides additional context about the resulting state, though it doesn't elaborate on workflow implications.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters described in the schema. The description adds no additional parameter-specific detail, so the baseline of 3 applies.
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 'Set stage status to COMPLETED (frozen)' uses a specific verb and resource, clearly identifying the action as transitioning a stage to a completed/frozen state. This distinguishes it from sibling tools like start_board_stage and reopen_board_stage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that it should be used when a stage is finished or contrast with start_board_stage or reopen_board_stage. Given the sibling tools, this 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?
The description adds no behavioral context beyond what annotations already provide. Annotations correctly indicate destructiveHint=true, readOnlyHint=false, and idempotentHint=true. The description merely restates 'delete' without adding details like permanence, cascading effects, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It conveys the essential action, resource, and identifier at the start.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema) and strong annotation coverage (destructiveHint, idempotentHint), the description is almost complete. It lacks explicit mention of alternates like archive_board, but the core functionality is fully specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with board_id described as 'Board UUID' and format uuid. The description's 'by UUID' reinforces but does not add new semantics. Per the baseline rule, a score of 3 is appropriate when the schema fully documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('board'), and specifies the identifier type ('by UUID'). This distinguishes it from sibling tools like archive_board, unarchive_board, get_board, and delete_board_stage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: it deletes a board. However, it does not explicitly mention when to use this over alternatives like archive_board, nor does it state any prerequisites or consequences. The context is minimal but sufficient for a straightforward delete operation.
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?
The description adds no behavioral context beyond what annotations already provide. Annotations include destructiveHint=true, idempotentHint=true, and openWorldHint=true, but the description merely restates the action and does not disclose consequences like permanence, required permissions, or side effects. Since annotations already cover the safety profile, the description contributes little extra 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 sentence, 'Delete a worklog entry from a task,' with no filler or repetition. Every word earns its place, and the key action and resource are front-loaded. This is an excellent model of conciseness for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (two required UUID parameters, no output schema, and safety annotations present), the description plus schema and annotations are nearly sufficient. It clearly states the resource and action, and annotations cover destructive/idempotent behavior. However, it lacks explicit usage guidance or mention of any edge cases, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for both task_id and worklog_id ('Task UUID' and 'Worklog UUID'). The description adds no additional parameter-level detail beyond the context that the worklog is 'from a task,' which is already implied by the parameter names. Schemas carry the semantic burden, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Delete' and clearly identifies the resource as 'a worklog entry from a task.' This distinguishes it from sibling tools like delete_task_comment (comment, not worklog) and add/update_task_worklog (different operations). The title and description align perfectly, leaving 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage context (when you need to remove a specific worklog entry) but does not explicitly mention alternatives or exclusion criteria. It lacks guidance such as 'use this instead of update_task_worklog when you need to permanently remove the entry,' so the agent must infer when to choose this tool over 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?
Annotations already cover idempotency and non-destructiveness. The description adds the specific behavioral outcome (status becomes ACTIVE) but does not mention side effects, reversibility, or any requirements. With annotations present, this is adequate but not enriched.
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 waste. It is appropriately concise for a simple state-change tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description plus schema and annotations are nearly sufficient. However, it lacks any note about the relationship to 'reopen' or 'complete', which would improve contextual completeness in a toolset with overlapping state transitions.
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 provides complete descriptions for all parameters (100% coverage), so the baseline is 3. The description does not add any additional parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set stage status to ACTIVE') with a specific verb and resource. However, it does not explicitly distinguish itself from sibling tools like reopen_board_stage, which may also set a stage to ACTIVE, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the description: use when you want to activate a stage. However, there is no explicit guidance on when to use this over alternatives (e.g., reopen vs start), nor any exclusions or prerequisites.
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?
Annotations already convey readOnlyHint=false, destructiveHint=false, and idempotentHint=true, so the description adds no safety context beyond implying the comment must already exist. No contradiction with annotations, but no extra behavioral detail is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no irrelevant details or repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update operation with all three required parameters clearly documented in the schema and annotations present, the description is adequate. It lacks return value or error condition info, but no output schema exists and the operation is low-complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described (task_id, comment_id, content). The description adds no additional parameter meaning, so baseline 3 applies.
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 'Update an existing task comment' uses a specific verb ('Update') and resource ('task comment'), clearly distinguishing it from sibling tools like add_task_comment and delete_task_comment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that this should be used after a comment exists, nor does it distinguish the update scenario from adding or deleting a comment.
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?
The description only restates the core action and does not disclose behavioral details beyond annotations. It does not mention whether updates are partial/full, how missing worklogs are handled, or what is returned. Annotations already provide safety hints (readOnlyHint false, idempotentHint true, destructiveHint false), but the description adds no extra 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, clear sentence. It is concise, front-loaded, and contains no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool description is minimal, but the schema and annotations fill in parameter and safety details. It lacks explicit guidance about partial updates or error behavior, and no output schema is present. For a simple update tool, the description is adequate but leaves room for richer 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?
The input schema descriptions cover all five parameters (100% coverage) with meaningful details such as 'Updated time in minutes (max 1440)' and 'Optional note'. The tool description contributes no additional parameter meaning, so the baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the resource ('existing worklog entry for a task'). It distinguishes itself from sibling tools like add_task_worklog and delete_task_worklog by explicitly mentioning 'existing'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'existing worklog entry' indicates this is for modifying already-created worklogs, implying when to use it. Sibling tool names (add_task_worklog, delete_task_worklog) provide clear alternatives, though no explicit exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful context about what data is included (columns, stages, config, member count) but doesn't disclose potential absence of required parameters or return structure. This adds some value beyond annotations but not rich behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary purpose, and each sentence earns its place. It gives a clear action, parameter context with an example, and a concise list of returned content without unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with strong annotations and 100% schema coverage, the description is largely complete. It summarizes the return content, which is valuable given there is no output schema. A minor gap is that the schema lists no required parameters, while the description implies a slug is needed, but this is not a major omission in 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 coverage is 100%, with both 'slug' and 'board_slug' already described in the schema. The description repeats the slug concept but doesn't add significant new meaning. The baseline of 3 is appropriate since the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets detailed info for a single board by its URL slug. It specifies the resource (board) and the key parameter (URL slug), and distinguishes from sibling tools like list_boards by focusing on a single board. The content list ('all columns, stages with their statuses, board config and member count') further clarifies the tool's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need detailed info for a specific board by its slug) but doesn't explicitly mention alternatives or when not to use it. It doesn't reference sibling tools like list_boards for listing all boards, so usage guidance is only implied, not explicit.
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?
The description adds the behavioral constraint that the full ordered list must be supplied, which goes beyond the schema's 'All stage IDs in target order.' The annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false) already communicate the safety profile, so the description only needs to add extra context. It does not describe side effects, error behavior, or changes to other stage properties, but the annotations cover the key safety aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that leads with the verb and resource, then explains the required input. There is no redundancy; every word adds value. It is appropriately short 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?
Although the operation is simple, the description omits crucial context: how to identify the board (only ordered_stage_ids is required in the schema, but a board_id or board_slug is logically necessary), and what the return value is (no output schema exists). The description does not compensate for these gaps, leaving an agent uncertain about mandatory inputs and expected response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for all three parameters with 100% coverage, so the description adds little beyond the schema. The word 'full' in the description reinforces the existing 'All stage IDs' description for ordered_stage_ids. However, the description does not clarify how board_id and board_slug are used or that one of them is required for the operation to work, despite not being marked as required in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Reorder stages on a board') with a specific scope (stages on a board) and the method (by passing full ordered list of stage IDs). It is distinct from sibling tools like reorder_daily_plan_blocks or reorder_task, leaving no ambiguity about which operation this is.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by passing full ordered list of stage IDs' implies that the tool should be used when a complete reordering of stages is needed, and it hints that a partial list is not acceptable. However, it does not explicitly mention when not to use it or provide alternatives (e.g., using update_board_stage to change individual stage positions). The guidance is clear but lacks explicit exclusions.
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?
Annotations already indicate a non-read-only, non-destructive, non-idempotent operation. The description adds the return behavior (created comment with author info), which is useful context beyond annotations, though it does not elaborate on side effects or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the main action and immediate return info. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 parameters, annotations, and no output schema, the description sufficiently covers action and return. It is complete for the agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with descriptions (content and task_id), so the description need not add extra parameter detail. Baseline of 3 is appropriate given 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 action ('Post a comment on a task') with a specific verb and resource, distinguishing it from sibling tools like update_task_comment, delete_task_comment, and get_task_comments.
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 through the action but does not explicitly state when to use this tool versus alternatives. No exclusions or conditions are mentioned.
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?
Annotations already indicate a mutating, destructive operation, so the description doesn't need to restate that. It adds valuable context by specifying the required authorization level (ADMIN/OWNER), which is critical for an agent to know before invoking. This goes beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose and includes the key requirement. No unnecessary words, making it highly concise and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description omits critical context about how to identify the target board. The schema does not require board_id or board_slug, yet the description says 'on that board,' leaving ambiguity about whether board identification is needed and how it should be provided. This is a meaningful gap for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for all parameters, so the description does not need to compensate. It does align 'role/title' with the role and title params, but adds no additional meaning beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Update board member role/title.' This distinguishes it from sibling tools like remove_board_member and list_board_members, which handle deletion and listing, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear permission prerequisite ('Requires ADMIN/OWNER on that board'), which is a useful usage constraint. However, it does not explicitly contrast with alternatives (e.g., remove_board_member for removal) or state when not to use it, leaving some ambiguity.
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?
Annotations already indicate readOnlyHint=false, destructiveHint=false, idempotentHint=false. The description adds the requirement for ADMIN/OWNER permission, which is useful context. It does not describe the invitation acceptance flow or behavior on duplicate invites, but given annotation coverage, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the action, target, method, and permission requirement. No wasted words, and all key information 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?
Given the schema covers all parameters and annotations disclose safety traits, the description is mostly complete. It fails to mention that board_id or board_slug is likely needed to identify the board, but the schema allows this to be inferred. Overall, it is sufficient for a well-documented tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all four parameters, so the baseline is 3. The description restates the role enum but doesn't add new meaning beyond what the schema provides. It also doesn't clarify how board_id vs board_slug are used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states exactly what the tool does: 'Invite a user to board by email with role ADMIN/MEMBER/VIEWER.' It uses a specific verb (invite), identifies the resource (board), and includes the critical dimensions (email, role). This clearly distinguishes it from sibling tools like revoke_board_invitation or accept_board_invitation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use to invite a user by email with a specified role. It also states the prerequisite permission (ADMIN/OWNER). It does not explicitly name alternative tools or exclusions, but the use case is well implied.
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?
Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds an auth requirement (ADMIN/OWNER role), which is a useful behavioral trait beyond the annotations. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the action, and includes the essential role requirement. Every word is purposeful with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the full schema and annotations, the description is adequately complete for a straightforward create tool. It could differentiate from the many sibling stage tools, but the role requirement and clear purpose make it sufficient for an AI agent to select it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so all five parameters are already documented. The description adds no additional parameter semantics, but the schema carries the burden effectively, meriting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a stage on a board' with a clear verb and resource. The verb 'create' distinguishes it from sibling tools like update_board_stage, delete_board_stage, reorder_board_stages, and start_board_stage, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides the role requirement (ADMIN/OWNER) as a prerequisite, but it does not explicitly state when to use this tool versus alternatives such as update_board_stage or reorder_board_stages. Usage is implied by the name and title 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, so the description is not required to state that it is read-only. The description adds useful context about ordering by creation time and the fields returned, but this is not extensive behavioral disclosure. It does not contradict the 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 two sentences, front-loaded with the core purpose and followed by return field details. There is no redundant information or filler; every word contributes to understanding the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool, the description covers the purpose, ordering, and return fields. However, it does not specify the ordering direction (ascending/descending) or mention any potential pagination or limits, leaving a minor gap 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?
The input schema fully describes the only parameter (task_id) with format uuid and description 'Task UUID', giving 100% coverage. The description does not add additional parameter semantics beyond referring to 'a task', 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 'Get all comments for a task ordered by creation time', using a specific verb and resource. It distinguishes itself from sibling comment tools like add_task_comment, update_task_comment, and delete_task_comment by focusing on retrieval and listing the return fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this tool retrieves all comments for a task. However, it does not explicitly mention when to use it over alternatives or include exclusions. The usage is obvious given the tool's purpose, but it lacks explicit guidance about when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds the role enumeration and 'all members' claim. It does not discuss edge cases like permission requirements or pagination, but for a simple read-only listing with good annotations this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with front-loaded purpose and a practical usage note. No filler.
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 low-complexity read-only tool with a single parameter and strong annotations, the description is sufficient. It includes the main action, role types, and a prerequisite, though it could optionally hint at the response format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the board_id parameter already includes a description referencing list_boards and get_board. The instruction to use list_boards first adds workflow context but does not add new parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with a clear resource 'members of a board' and specifies the output dimension (roles with enumerated values). This distinguishes it from sibling tools like list_board_tags and list_board_columns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs to call list_boards first to obtain the board id, providing a clear prerequisite. It does not explicitly mention alternatives or exclusions, but the read-only nature and scope (members, not invitations) are contextually clear from the description and sibling names.
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?
readOnlyHint and openWorldHint annotations already establish the safe, non-exhaustive nature. The description adds the scoping logic, but it leaves ambiguity about whether 'due today' includes completed tasks and does not disclose default return verbosity. This aligns with the baseline for annotation-covered tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb, and contains no filler. The parenthetical adds precise filter criteria and the optional board filter is conveyed efficiently.
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 read-only list tool with full schema and annotation coverage, the description covers the essential relevance criteria. It does not explain the return format, but the 'detailed' parameter and openWorldHint provide some indication; a dedicated output schema would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 6 parameters have schema descriptions (100% coverage), so the description adds little beyond what the schema already provides. The only addition is confirming the board filter is optional, which is also apparent from having zero required parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'tasks relevant for today', with explicit inclusion criteria (assigned to me and not done, or due today). This distinguishes it from siblings like list_tasks and list_calendar_tasks by specifying the daily relevance filter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is for today's relevant tasks, with an optional board filter. It does not explicitly mention alternatives or exclusions, but the daily relevance criterion and optional board filter imply the appropriate scenario.
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?
Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the mutation and idempotence are known. The description adds the behavioral constraint that all visible block UUIDs must be passed, and the drag-and-drop analogy conveys an intuitive mental model. However, it does not disclose failure modes (e.g., what happens if the set is incomplete) or whether the operation replaces the entire order atomically.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences. The first sentence states the purpose and scope, and the second delivers the critical usage instruction. No wasted words, and the most important information 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 simple reorder tool with two well-described parameters and annotations that cover mutation/idempotence, the description is sufficient. It conveys the core constraint (all visible UUIDs) and the target resource. It could optionally mention that the current visible list can be fetched with list_daily_plan_blocks, but this is implied and not essential. The output schema is absent, but a reorder tool naturally needs no return value description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both parameters have clear descriptions in the schema. The tool description essentially repeats the ordered_ids semantic ('ALL block UUIDs visible on that date, in the desired order') and adds the 'drag-and-drop' analogy, but it does not add new details beyond the schema, so it meets the baseline for full 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 a specific action ('Reorder the day-planner blocks visible on a given local date') and provides a relatable analogy ('drag-and-drop equivalent'). It distinguishes the tool from siblings such as update_daily_plan_block or set_daily_plan_block_status by focusing solely on reordering, and no other daily-plan reorder tool exists among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs the key usage requirement: 'Pass ALL block UUIDs visible on that date, in the desired order.' This is a critical guideline that prevents partial-update mistakes. It does not explicitly mention when not to use the tool or name alternative tools, but given the sibling list, this is the only reorder tool for daily plan blocks, so the context is clear.
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?
Annotations already include destructiveHint=true and readOnlyHint=false, covering the destructive nature. The description adds the authorization requirement (ADMIN/OWNER), which is useful context beyond the annotations. No contradiction with 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 a single, front-loaded sentence: 'Revoke an invitation by id. Requires ADMIN/OWNER.' Every word contributes necessary information, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple revocation tool, the description is adequately complete. The annotation covers destructive behavior, and the description adds the required role. It could be improved by explicitly clarifying that it is for invitations sent by the user, but overall it is sufficient.
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 for all three parameters (invitation_id, board_id, board_slug). The description does not add any extra meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Revoke an invitation by id', which is a specific verb and resource. It distinguishes itself from siblings like 'decline_board_invitation' by focusing on the revoke action, and the 'by id' clarifies the target.
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 the permission context 'Requires ADMIN/OWNER', which gives a clear usage condition. However, it does not mention alternatives (e.g., decline_board_invitation for invitations you received) or any exclusions, so the guidance is only 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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safe read-only nature is known. The description adds that it returns the current user's profile but no additional behavioral traits like error conditions or side effects. Since the bar for disclosure is lower with annotations, this is acceptable but not enhanced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately identifies the action and resource. It contains no unnecessary words and all information is relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description is complete: it specifies the subject (current authenticated user), the fields returned, and the read-only nature. No additional context is needed for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is empty. The description compensates by clearly indicating what the response will include (id, email, firstName, lastName, avatarUrl), which is helpful given there is no output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Get[s] the profile of the currently authenticated user' and explicitly lists the returned fields (id, email, firstName, lastName, avatarUrl). This specific verb+resource combination distinguishes it from sibling tools like get_board or get_task, which target different resources.
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: it is for fetching the current user's profile, which is unique among the sibling tools. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites such as authentication requirements.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is established. The description adds value by enumerating the fields returned (title, status, etc.), but it does not disclose other behavioral aspects like authentication requirements or rate limits. The description is consistent with annotations, and no contradiction is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the first sentence delivers the core purpose, and the second sentence concisely lists the returned fields. Every sentence contributes meaningful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter retrieval tool with no output schema, the description adequately covers what the tool does and what it returns. It lists the full set of fields included, making the return value clear. The read-only annotation and explicit field enumeration satisfy the needed 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 coverage is 100% with the 'id' parameter already described as 'Task UUID' with format uuid. The description's mention of 'by its UUID' merely restates what the schema provides, adding no new semantic information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get full details of a single task by its UUID.' This specifies a distinct verb, resource, and scope, distinguishing it from sibling tools like list_tasks (which retrieves multiple tasks) and get_task_by_number (which uses a different identifier).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when full details of a specific task identified by UUID are needed, and the emphasis on 'by its UUID' contrasts with get_task_by_number. However, it does not explicitly name alternatives or provide exclusion criteria, so it falls short of full guideline clarity.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds the filtering behavior (due before date and not done) but does not disclose additional traits such as ordering, pagination, or response format. This adds some value beyond annotations but is not rich 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?
A single, front-loaded sentence that states the action and key filters with no redundant words. Every element contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, filtered list tool with one well-documented parameter and good annotations, the description is complete. It conveys the exact selection criteria and scope ('the user's'), and no output schema is expected for a simple list operation. No critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the single parameter local_date has a clear description ('Local date YYYY-MM-DD — blocks overdue relative to this date'). The main description echoes this with 'due before the given local date' but does not add semantics beyond schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('List') and precisely identifies the resource ('the user's day-planner blocks') with clear qualifiers ('due before the given local date and are still not done'). This distinguishes it from the more general sibling tool list_daily_plan_blocks, which presumably lists all blocks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies its use case: retrieving overdue, incomplete day-planner blocks. However, it does not explicitly mention alternatives or exclusions (e.g., 'use list_daily_plan_blocks to see all blocks'), so it lacks the explicit 'when not to use' guidance that would earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the destructive nature is covered. The description adds the ADMIN/OWNER permission requirement, which is useful behavioral context beyond annotations. No contradiction; idempotentHint is consistent with a removal 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?
Two short sentences effectively communicate the action and a key precondition. No fluff; every word earns its place and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple destructive action with full schema descriptions and good annotations, the description is complete. It covers the core action and permission, while the schema handles parameter details. No output schema exists, so return values need not be explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with descriptions for all three parameters (board_id, board_slug, target_user_id). The tool description adds no additional parameter-level detail, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Remove a member from board' with a specific verb and resource, distinguishing it from sibling tools like update_board_member or list_board_members. The permission requirement adds specificity.
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 gives a clear precondition ('Requires ADMIN/OWNER') but does not explicitly discuss when to use this tool versus alternatives such as revoke_board_invitation or update_board_member. Usage is implied rather than stated with exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral details not in annotations: returns the updated block and emphasizes partial updates ('Pass only the fields you want to change'). It also notes the title syntax for linking board tasks. Annotations already declare non-read-only and non-destructive; there is no contradiction. However, it doesn't cover potential error conditions or other side effects, keeping it just short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with four short sentences, front-loaded with the main purpose. However, the title reference duplicates schema information and could be omitted, but overall it's efficiently sized and structured.
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 mutating tool with 7 params and no output schema, the description covers the core purpose, partial-update behavior, and return value. The schema provides exhaustive param details, so the description only needs to connect these elements. It succeeds but leaves out any note on when to use alternatives (covered under usage) and potential constraints like recurrence-dependent fields (covered in schema). Overall, adequate for this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema describes all 7 parameters with 100% coverage, so the description adds limited value. The only param-specific mention is the title's `@boardSlug/N` reference, which duplicates the schema text. The general guidance 'Pass only the fields you want to change' applies across all params but offers no new parameter semantics. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Update fields of an existing day-planner block,' providing a specific verb and resource. It clearly differentiates from sibling tools like create_daily_plan_block and delete_daily_plan_block by emphasizing 'existing' and 'update.' The mention of partial updates and title linking further defines scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use case: updating existing blocks, and instructs to 'Pass only the fields you want to change,' giving clear context for usage. It doesn't explicitly name alternatives or exclusions, but the phrase 'existing day-planner block' delineates from create/delete. Lacks explicit when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a write operation (readOnlyHint=false) and non-idempotent. The description adds behavioral context beyond that: the `@boardSlug/N` syntax makes the title render as a clickable link, and it states that the tool returns the created block. There is no contradiction with the 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 only three sentences, each carrying meaningful content: the core creation purpose, the linking feature, and the return value. It is front-loaded and free of filler. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has 6 parameters and no output schema, the description adequately covers the core purpose and the most notable special behavior (@boardSlug/N linking). It explicitly states that the created block is returned, which is helpful in the absence of an output schema. The remaining details, such as default recurrence, are left to the schema, which is well-documented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all six parameters, so the baseline is 3. The tool description repeats the `@boardSlug/N` syntax already present in the title parameter description, but adds no new semantic detail for other parameters like `scheduled_time` or `recurrence`. Thus, it does not significantly elevate understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Create a block in the user's personal day-planner'. It explicitly distinguishes this from a 'board task', which immediately differentiates it from the many task/board sibling tools. The added detail about linking a board task via `@boardSlug/N` further clarifies its unique function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context by stating that the block belongs to the user's own time-blocking schedule and explicitly says 'not a board task', which steers away from using this tool for board tasks. It does not name a specific alternative tool like 'create_task', but the exclusion is explicit enough. Overall, usage context is clear and unambiguous.
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?
Annotations already declare non-read-only, non-idempotent, and non-destructive behavior. The description adds that the operation returns 'the created task with its generated id and number,' which gives useful output context. It does not describe side effects or auth needs, but the annotation coverage lowers the burden.
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 exactly two sentences, front-loaded with the action and resource, and contains no filler or repetition. Every sentence contributes meaning: one states what it does and its requirements, the other states the return value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 13 parameters and no output schema, the description provides the necessary high-level context: purpose, required inputs, and return shape. The schema handles all parameter details. It could mention optional capabilities (e.g., statuses/priorities) but those are covered thoroughly in the input schema, so the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with every parameter receiving a detailed comment. The tool description mentions only the required board_slug and title, which are already documented in the schema. Thus the description adds no additional semantic value beyond the schema, earning the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb and resource: 'Create a new task on a board.' This clearly distinguishes it from sibling tools like update_task, delete_task, and get_task. It also names the required inputs (board slug and title), making the purpose immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states prerequisite inputs ('Requires the board slug and a title') but does not explicitly mention when not to use it or suggest alternatives like update_task for existing tasks. This is clear context without exclusions, so it earns a 4.
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?
Annotations already flag destructive and non-read-only behavior. The description adds valuable authorization context by specifying the ownership rule, which goes beyond the structured metadata. It does not contradict annotations and provides extra 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 two short sentences, front-loaded with the core action and followed by the key restriction. There is no redundant or filler content—every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter destructive operation with complete schema and annotations, the description is adequate. It covers the action, the object, and the critical permission rule. Not mentioning return values or error cases is acceptable since no output schema exists and the operation is straightforward.
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?
Both parameters (task_id and comment_id) have full schema descriptions with UUID format and required status. The tool description adds no additional parameter-level meaning, but with 100% schema coverage, the schema already carries the full burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource construction ('Delete a comment from a task') and clearly distinguishes itself from sibling tools like update_task_comment, add_task_comment, and get_task_comments. It immediately states the primary action and target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states a key usage constraint: 'You can only delete your own comments.' This provides practical context for when the tool is applicable, though it does not explicitly name alternative tools or exclusion scenarios. Still, for a simple delete operation, this is sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral details beyond what annotations provide: it discloses the ordering ('newest first'), the type of changes covered ('task/stage/member changes'), and the role requirement. No contradiction with readOnlyHint or openWorldHint is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences. The first sentence front-loads the core purpose and scope; the second gives the access requirement. Every word is purposeful and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters and no output schema, the description provides high-level context: what an audit trail contains, ordering, and role. It doesn't describe pagination or return fields, but the schema covers parameters and the tool is a straightforward read-only list. This is sufficient for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 9 parameters have descriptions in the schema (100% coverage), so the description is not required to repeat them. The description's mention of 'whole board' aligns with board_id/board_slug but adds little beyond schema. Achieves the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('audit trail for a whole board'), and the specific scope ('task/stage/member changes'). The phrase 'newest first' adds behavioral context. This distinguishes it from the sibling tool get_task_activity by emphasizing board-level scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the authorization prerequisite ('Requires ADMIN/OWNER role') and indicates the board-level context. It does not explicitly mention alternatives such as get_task_activity, but the scope is unambiguous. It provides clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds behavioral detail beyond that: it resolves the number to a UUID and returns the same shape as get_task. This gives the agent useful context about the tool's internal behavior and output, while not overpromising. No contradiction with 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 two sentences, front-loaded with the core action, and every sentence earns its place. It avoids redundancy and is compact while still providing essential context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple lookup with two well-described parameters and a read-only annotation. The description states the return shape by referencing get_task, which is sufficient given there is no output schema. It does not mention error handling, but that is not necessary for this level of complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already explains both parameters (number as #N without '#', board_slug as the board slug). The description adds minor context ('human-friendly number', 'within a board') but does not materially enhance the schema's parameter semantics, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a precise resource ('task by its human-friendly number'), and explicitly differentiates from sibling get_task by noting it resolves the number to the UUID. It clearly states the scope ('within a board') and the use case, making it unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear guidance on when to use this tool: 'Handy when you know the #N but not the UUID.' This implies the alternative (get_task when the UUID is known) and provides context, though it does not explicitly name the alternative or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds value by disclosing the return structure (id and name) and the downstream use of these IDs, which are useful behavioral traits not present in the 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 a single, front-loaded sentence that communicates purpose, output, and usage in under 20 words. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no required parameters and no output schema, the description is adequately complete. It states the return fields and how to use them, and annotations cover read-only behavior. It could mention ordering or empty results, but these are minor gaps for such a straightforward 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?
The schema covers 100% of the parameters with descriptions, so the description doesn't need to explain them. The text adds only the generic 'by slug' which is already in the schema, and it emphasizes the board context, but no extra parameter semantics are provided beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('kanban columns for a board by slug'), and clearly distinguishes itself from sibling tools like list_board_tags by focusing on columns rather than tags. It also specifies the returned fields (id and name), removing ambiguity about the tool's output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use the returned IDs in create_task and update_task, which provides clear guidance on when this tool is needed. It lacks explicit alternatives or exclusions, but the context is clear enough for an agent to select it appropriately.
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?
Annotations already declare readOnlyHint=true, so the description doesn't need to restate safety. It adds meaningful behavioral context by disclosing the ADMIN/OWNER permission requirement, which is beyond standard annotations. It does not describe return format, but the readOnly annotation lowers the burden and the permission note adds value.
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 that are front-loaded with the core action. The first sentence states purpose, the second adds the key prerequisite. Every word earns its place—no redundancies or filler.
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 straightforward list tool with two well-documented optional parameters and readOnly annotations, the description provides sufficient context: what is listed, for which entity, and who can access it. It doesn't explain the difference between board_id and board_slug, but that's already in the schema. A note about return type would be nice since there's no output schema, but 'list' implies an array. Overall complete for its simplicity.
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% since both parameters (board_id, board_slug) have descriptions in the schema. The tool description adds no additional parameter meaning beyond stating the tool lists invitations. Baseline 3 is appropriate when schema covers all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and identifies the exact resource ('invitations for a board') with the status scope ('pending/accepted/declined'). This clearly distinguishes it from sibling tools like list_board_members, list_board_tags, and list_my_invitations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool is for viewing invitations for a specific board, which sets it apart from alternatives like list_my_invitations. It adds a usage prerequisite ('Requires ADMIN/OWNER'), but does not explicitly name alternatives or provide when-not-to-use guidance. Context is clear enough for a simple read tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true and openWorldHint=true annotations already covering the safety profile, the description adds meaningful behavioral context: tags are shared among board members, uniqueness is board-scoped, and the returned ids/names have specific usage patterns in other tools. The 'let the board pick up new ones' hint also reveals how tag_names are handled, which is beyond what annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and every clause adds value. There is no redundant content, and the structure flows logically from purpose to usage detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with an output described in the text, the description is fairly complete. It covers the result shape (id and name) and integration with task operations. However, it does not mention whether a board_id or board_slug is strictly required, nor does it address pagination or ordering, which could matter for boards with many tags. Still, given the simple scope, the gaps are minor.
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%: both parameters have clear descriptions ('Board UUID' and 'Board URL slug'). The tool description does not add any additional meaning about the parameters, such as clarifying that at least one is required or how they relate. The baseline of 3 applies because the schema already does the heavy lifting, and the description doesn't compensate further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource in the first sentence ('Get the tag vocabulary of a board'), which clearly states the tool's function. It also distinguishes this tool from potential global tag listings by emphasizing that tags are board-scoped ('same name on another board is a different tag'), effectively differentiating it from the sibling tool 'list_tags'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool: when you need a board's tag vocabulary. It also explains how to use the results ('use the ids in create_task/update_task tag_ids, or just pass tag_names'), providing practical context. However, it does not explicitly mention alternatives or when not to use this tool, so it stops short of a full exclusionary guideline.
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?
Annotations already declare this as a non-read-only, non-destructive, idempotent operation. The description adds behavioral nuance by explaining that recurring blocks track completion per-day, which is not captured by the annotations or schema. No contradiction is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with around 18 words, front-loaded with the verb 'Mark'. It conveys the essential scope and recurring-block nuance without any filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides the essential behavior, the per-date scope, and the recurring-block special case, which is sufficient for a simple status mutation tool. It does not specify the return value, but given the absence of an output schema and the simplicity of the operation, this is not a critical gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all three parameters, including an enum for status. The tool description adds no additional parameter semantics beyond the schema's existing descriptions, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Mark' with the resource 'day-planner block' and clarifies the scope as 'one specific local date'. It also distinguishes from the sibling 'update_daily_plan_block' by noting that recurring blocks track completion per-day, not globally.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool is for setting completion status on a specific date, and the note about recurring blocks helps users decide when this tool is appropriate. However, it does not explicitly name alternative tools or state when not to use it, so it falls short of a top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool creates a board membership and returns it, which goes beyond the annotations. Annotations already indicate it is mutating (readOnlyHint=false) and non-destructive, so the description adds useful return-value context without contradicting structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately conveys the action, target, and result. It is concise and front-loaded with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is complete. It explains the purpose, the return value, and the context (pending, current user). Sibling tools and annotations provide additional context, making this fully sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description ('Invitation UUID (from list_my_invitations)') already explains the meaning. The tool description adds little beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Accept a pending board invitation') and the target resource ('board invitation sent to the current user'). It also specifies the return value, which differentiates it from sibling tools like decline_board_invitation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it is for accepting a pending invitation for the current user. However, it does not explicitly mention alternatives or exclusions, such as 'use decline_board_invitation to reject'. The context is clear but lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds that it returns the created board with its generated slug, which is beyond the annotations. It also mentions the default column set. However, it does not discuss permissions, side effects, or error cases. With annotations indicating a non-read operation, this is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary purpose. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create operation with two parameters and no output schema, the description covers the main behavior and return value. It is sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover both parameters fully, and the description adds that the columns array is optional and defaults to a standard set. This clarifies behavior beyond the schema's property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a new board' with a specific verb and resource, and notes the optional columns and return value. This clearly differentiates from sibling tools like update_board and delete_board.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for creating new boards, which is evident from the context. It doesn't explicitly mention alternatives or when not to use, but the sibling list shows distinct operations. Clear context but no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveness (destructiveHint=true) and idempotency (idempotentHint=true), and the description adds that the invitation is 'pending' and 'sent to the current user,' which clarifies that only the user's own pending invitations are affected. It doesn't detail side effects like notification to the inviter, but the annotation coverage lowers the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the action and scope. There is no wasted text, and the sentence structure is straightforward and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with one well-documented parameter and no output schema, the description fully covers the context: what the tool does, to whom it applies, and the state of the invitation. The annotations fill in the behavioral profile, making this complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single parameter, including its provenance ('from list_my_invitations'). The description adds no additional meaning beyond the schema, 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 action (decline), the resource (board invitation), and the scope (sent to the current user). This distinguishes it from siblings like accept_board_invitation and revoke_board_invitation by emphasizing the invitation is pending and belongs to the current user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'pending board invitation sent to the current user' implies the tool is for invitations the user has received, not ones they created (which would be revoked via revoke_board_invitation). However, it doesn't explicitly contrast with accept or revoke alternatives, but the context is clear enough for the intended use.
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?
Annotations already indicate destructive and non-read-only behavior, but the description adds context by specifying permanence, permission requirements, and the confirmation message response. This goes beyond the structured annotations without contradicting them.
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 sentences deliver all necessary information: action, target, permissions, and return type. No redundancy or filler, making it efficiently front-loaded and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter destructive operation with no output schema, the description covers the essential behavioral aspects: what is deleted, who may do it, and what the response contains. The tool is simple enough that no further detail is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the 'id' parameter described as 'Task UUID to delete'. The description repeats this without adding new semantic detail, so it does not exceed the baseline expected from high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Permanently delete') and resource ('a task by its UUID'), clearly distinguishing it from sibling tools like delete_task_comment and delete_task_worklog. The scope is unambiguous and directly maps to the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states permission prerequisites (task creator or board OWNER/ADMIN), which tells the agent when the tool is usable. However, it does not explicitly name alternatives or state when not to use it, leaving a slight gap in guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint: true, so the safety profile is covered. The description adds meaningful behavioral details beyond the annotation: it discloses the output ordering ('newest first') and the specific event categories included ('status/priority/assignee/field changes, comments, worklogs'). It does not contradict the annotations, and the added context is useful but not exhaustive (e.g., no mention of pagination or access requirements).
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, information-dense sentence. It front-loads the core action ('Get the audit trail for a task') and immediately provides scope and ordering details. There is zero redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one simple parameter and is a read-only operation. There is no output schema, so the description reasonably carries the burden of explaining what the tool returns. It enumerates the key dimensions ('who changed what and when') and the main event types, which is sufficient for an agent to decide whether to invoke it. The description is complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage: the only parameter, task_id, is described as 'Task UUID' with a uuid format. The description adds no further meaning to this parameter beyond the schema's own documentation. Since the schema already carries the full semantic load, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the audit trail for a task: who changed what and when (status/priority/assignee/field changes, comments, worklogs), newest first.' It uses a specific verb ('get') and resource ('audit trail'), and it distinguishes itself from sibling tools like get_task_comments and get_task_worklogs by covering all change types. This makes it unmistakable 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool—when a comprehensive activity/audit trail is needed, as opposed to narrower tools for comments or worklogs. It names the included event types but does not explicitly call out alternatives or state when not to use it. The context is clear and the scope is well-defined, though explicit exclusion guidance is absent.
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?
Annotations already disclose readOnlyHint=true and openWorldHint=true, so no side effects need to be stated. The description adds behavioral context beyond the annotations by specifying the source of the data ('Summary tab') and enumerating the exact return fields, which is valuable since there is 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 one sentence that front-loads the action ('Read a task's summary') and immediately follows with essential context and return shape. Every word earns its place, with no filler or redundant expansion of structured data.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and no output schema, the description is fully complete: it states the purpose, the exact data returned, and the source context. The annotations cover safety, so no further disclaimers are 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?
The schema already documents task_id with 100% coverage ('Task UUID') and a clear required status. The description adds no new parameter-specific detail, but the baseline of 3 applies because the schema fully covers the parameters and the tool has only one parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and identifies the exact resource ('a task's summary'), clearly distinguishing it from sibling tools like get_task (full task) and set_task_summary (write operation). The em-dash clarification and return fields remove any ambiguity about what this tool retrieves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you need the summary digest shown in a task's Summary tab. It does not explicitly name alternatives or exclusions, but the context is clear enough that an agent can differentiate it from get_task or get_task_comments.
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?
Annotations already indicate readOnlyHint=true, and the description adds value by disclosing the exact fields returned (id, minutes, comment, workedAt, author). This goes beyond the safe-read signal and helps the agent understand the output shape. No contradictions with 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 concise and front-loaded: two sentences, no redundant information. Every phrase serves a purpose, and the field list is useful without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only retrieval with one well-documented parameter, the description is complete. It covers the return format (entry fields) and the core purpose. No output schema exists, but the field list compensates adequately. The annotations cover safety, and the schema covers parameters.
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 fully describes the only parameter (task_id as a UUID with a description). The description does not add further parameter semantics, but with 100% schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Get') and resource ('time-tracking worklogs for a task'). It also lists the fields of each entry, which distinguishes it from related sibling tools like add_task_worklog or get_task_activity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is for retrieving time-tracking worklogs for a specific task. It does not explicitly name alternatives or exclusions, but the scope is unambiguous and sufficient for a simple getter tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description is not burdened with restating safety. It adds context about the authenticated user scope and enumerates the exact return fields (id, name, slug, isArchived, columns, stages, config, taskCounter, createdAt), which is valuable behavioral detail. No contradiction with 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 a single, front-loaded sentence that states the action and resource, then lists return fields in a compact and readable manner. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, read-only list tool with no output schema, the description adequately covers purpose, access restrictions, and return shape. It includes all key fields and even indicates archived state via 'isArchived'. Pagination/ordering are not mentioned but are unnecessary for this simple case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is trivially 100%. Per rubric, a 0-parameter tool receives a baseline of 4; the description correctly omits parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and resource 'Kelvia boards', clearly stating the scope 'accessible to the authenticated user'. It enumerates the return fields, which distinguishes it from tools like get_board (single board) or list_board_columns (columns only).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing all boards but does not explicitly contrast with sibling tools such as get_board for a specific board or list_board_columns for columns only. No when-not-to-use guidance is provided.
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?
Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true, covering the basic safety profile. The description adds the precise behavioral detail of the state change (COMPLETED to ACTIVE), which goes beyond the annotations and provides useful context. No contradictions with 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 a single short sentence, front-loaded with the verb 'Reopen' and a precise state transition. There is no wasted text or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple state-change operation, the description, combined with the schema and annotations, provides enough context. No output schema exists, so return values need not be explained. The sibling tools show related operations, but the description is self-contained and sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter having a description (board_id, stage_id, board_slug). The description does not add parameter-specific details, but the schema already handles that. Baseline 3 is appropriate since the description adds no extra semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('reopen') on a specific resource ('stage') with an explicit state transition ('from COMPLETED to ACTIVE'). This distinguishes it from sibling tools like complete_board_stage and start_board_stage, which handle opposite or different transitions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: when a stage is in COMPLETED state and needs to return to ACTIVE. It doesn't explicitly name alternatives or exclusions, but the state transition implies the precondition and usage scenario, which is sufficient for this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the annotations: it explicitly states that the tool 'replaces any previous summary' and that there is one summary per task. It also discloses markdown support and where the summary appears. The destructiveHint=false annotation is not contradicted because the replacement is a normal field update, but the description clarifies the overwrite behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that front-load the core action and then add essential details (location, markdown, replacement). Every sentence earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with only two string parameters, no output schema, and helpful annotations, the description covers the essential aspects: what the summary is, where it is shown, that markdown is supported, and that it replaces the previous summary. No critical gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described, providing a baseline of 3. The description enriches the 'summary' parameter by specifying that it should be a digest of the task's current state and what has been done, and notes it appears in the Summary tab. This is meaningful guidance beyond the schema's brief description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Write or replace') and clearly identifies the resource ('a task's summary'). It also defines the summary's content ('concise digest of the task's current state and what has been done') and location ('Summary tab'), distinguishing it from sibling tools like get_task_summary or update_task.
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 (setting/replacing a task's summary) and notes it is shown in the Summary tab, but it does not explicitly state when to prefer this tool over alternatives such as update_task, nor does it mention when not to use it. The guidance is inferred rather than explicit.
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?
Annotations already indicate a non-read-only, non-destructive, idempotent operation. The description adds valuable behavior beyond that: 'Changing columns reorders/renames them' and 'Returns the updated board,' which are not visible from annotations. No contradiction with annotations was found.
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?
Three short sentences, front-loaded with verb and resource, with every sentence adding behavioral or usage information. No filler or repetition.
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 low-complexity update tool, the description covers scope, partial-update semantics, column behavior, and return value. The schema and annotations round out the picture; no output schema exists, but the return value is explicitly stated. It omits permissions or alternatives, but those are not essential for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema already covers all parameters, the description adds partial-update semantics ('Pass only fields you want to change') and clarifies the effect of the columns parameter on ordering/renaming. This goes beyond the schema's basic type/description fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Update a board's name or column list'), clearly distinguishing it from sibling tools like create_board and update_board_stage. It explicitly names the mutable fields, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction 'Pass only the fields you want to change' gives clear usage context for partial updates. However, it does not explicitly name alternatives or exclusions (e.g., using update_board_stage for stage changes), so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnlyHint=false), but the description adds meaningful behavior: tags are shared across board members and are auto-created by task tools. This goes beyond the structured annotations, though it doesn't cover edge cases like duplicate handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise, front-loaded sentences: action, context, and guidance. No filler or redundancy; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create tool with a single required parameter and full schema coverage, the description fully covers the core context, including the shared nature of tags and the auto-creation fallback. No output schema is needed for such a straightforward operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (name, board_id, board_slug) described in the schema. The description adds no extra parameter meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a tag to a board's vocabulary') with a specific resource (tags on a board) and differentiates from siblings by noting that create_task/update_task auto-create tags. This avoids confusion with similar tag-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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when NOT to use the tool: 'Usually you don't need this: create_task/update_task tag_names create missing tags by themselves.' This names concrete alternatives and gives clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is known. The description adds context about the scope (personal day-planner, date filter, status field) that is not present in annotations, though it does not elaborate on return format or pagination.
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 sentences, each purposeful: the first states what it does and the second provides differentiation from a sibling. No wasted words, and the core information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with a single parameter and no output schema, the description fully covers what the tool does, its scope, and its relationship to a similar tool. An agent can confidently select and invoke it without additional 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 coverage is 100% because local_date has a clear description. The tool description repeats 'given local date' but adds no new semantic detail beyond the schema, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists the user's personal day-planner blocks for a given local date, including their done/not-done status. It explicitly distinguishes this from list_daily_tasks, which lists board tasks, so there is no ambiguity about what resource is being accessed.
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 names an alternative tool (list_daily_tasks) and clarifies when to use this tool instead: for the user's private schedule, not board tasks. This gives the agent clear context for tool selection and excludes a likely confusable use case.
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?
Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds useful context about the tool returning raw stored fields rather than date-resolved entries, but it doesn't mention any other behavioral aspects like ordering, pagination, or whether all definitions are returned. This is minimal but reasonable given the simple read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that front-loads the core action and resource, then adds a parenthetical detail and a contrast with the sibling tool. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only listing tool with no output schema, the description is complete. It specifies the action, the resource, the key output fields, and the distinction from the sibling tool, which is all the agent needs to decide and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is effectively 100% with no properties to describe. The baseline for no params is 4, and the description adds value by enumerating the fields present in the output, which gives the agent an idea of what to expect without needing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists the user's day-planner block definitions and names the specific fields (recurrence rule, scheduled time, active_from). It also explicitly distinguishes this from list_daily_plan_blocks by noting the result is not resolved against a specific date, making the purpose and scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear contrast with list_daily_plan_blocks, signaling when to use this tool (when you need stored definitions rather than date-resolved blocks). This gives the agent a direct decision rule for choosing between sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds the specific resource scope (invitations sent to the current user) and the statuses and fields returned. It does not mention edge cases or ordering, but for a simple read-only list tool, it provides adequate behavioral context beyond the 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 a single concise sentence that front-loads the action and resource, with no filler. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (no parameters, read-only), the description fully covers what the agent needs to know: what is returned (invitations, statuses, board, role). No output schema exists, so this description is sufficient for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there are no parameter semantics to explain. The baseline for 0 parameters is 4, and the description adds no unnecessary parameter details.
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 that the tool lists board invitations sent to the current user, with a specific verb ('List') and resource ('board invitations'), and explicitly notes the statuses (pending/accepted/declined) and included fields (inviting board and role). This distinguishes it from the sibling tool list_board_invitations, which likely covers board-level invitations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is for viewing the current user's own invitations. However, it does not explicitly mention alternatives such as list_board_invitations or when not to use this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds partial-update semantics ('pass only the fields you want to change') and states the return value, which is not visible from annotations. Annotations already cover read-only/destructive/idempotence, so no contradiction; some additional detail on side effects could push it higher.
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?
Three short sentences, front-loaded with the action, and every word adds value. No repetition of schema details or padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 14 richly documented parameters and no output schema, the description correctly focuses on partial update behavior and return value. It stops short of explicitly noting the required id and error conditions, but these are inferable or present in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema coverage, the description provides the key global instruction that only supplied fields are updated and all are optional, which is not explicitly stated in the schema. This materially reduces the risk of sending a full replacement payload.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Update... an existing task') and clarifies the scope ('one or more fields'), distinguishing it from create/delete/comment-update siblings. The return value is also stated, removing ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly conveys when to use it: modifying an existing task with selective fields. It does not name alternatives or exclusions, but the context is unambiguous and the sibling tools are easily differentiated by task vs. comment/board operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, the description discloses that this is a soft-delete, preserving earlier occurrences and completion history. This adds valuable behavioral context that annotations (destructiveHint=true) do not fully convey, and it aligns with the idempotentHint without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a parenthetical clarification, front-loading the core action and adding essential detail without any filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema), the description fully covers the key behavioral nuance (soft-delete) and scope. Nothing critical is missing for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already documented. The description adds nuance to local_date by explaining the delete is 'from that date onward' and that earlier occurrences are kept, enriching the schema's basic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove a day-planner block'), the resource (day-planner block), and the scope ('starting from a given local date onward'). It also distinguishes itself from siblings by specifying the remove operation and soft-delete semantics, which differentiates it from update/set-status/reorder tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool (to remove a block from a date onward) and its soft-delete behavior. However, it does not explicitly mention alternatives or when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safe-read nature is established. The description adds context about the due-date scoping and the calendar-view purpose. It does not mention potential edge cases like timezone handling or pagination, but the bar is lower given the annotations; the description sufficiently supplements them without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and scope. The second sentence earns its place by providing a crucial differentiation from a sibling tool. There is zero redundancy; every word contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with 3 parameters (2 required), good annotations, and no output schema, the description is complete. It covers what the tool does, its unique scope, and its relationship to a sibling. No critical information is missing for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds semantic meaning by linking the date range to the concept of 'due date' – not just any date – and clarifies that the range applies to a calendar view. This goes beyond the schema's simple 'ISO date range start/end inclusive' and helps the agent map 'from'/'to' to the actual filtering intent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with a clear resource ('tasks') and a precise scope ('with a due date inside a date range, for a calendar view'). It explicitly distinguishes itself from the sibling tool 'list_tasks' by highlighting the due date scoping, making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit alternative: 'Unlike list_tasks, this is scoped by due date range rather than status/search filters.' This tells the agent when to choose this tool over its sibling (when the primary need is due-date-based filtering) and clarifies the intended use case ('for a calendar view').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, openWorldHint), the description adds crucial behavioral context: tags are board-scoped, duplicate names across boards are distinct, and each item includes its board. This substantially clarifies the tool's behavior without contradicting the 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 three sentences, with the primary action front-loaded. Every sentence adds value: scope, domain nuance, and a pointer to the alternative. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (no params, no output schema), the description is complete: it states the scope, clarifies the board-tag relationship, and points to the sibling tool for more specific use cases. There are no missing critical details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully covers the input. The description adds no parameter-specific detail because none is needed, meeting the baseline for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list tags), the resource (tags), and the scope (across every board you can access). It explicitly distinguishes itself from the sibling tool list_board_tags, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: use this tool for tags across all accessible boards, and use list_board_tags for a single board. This directly addresses when to use this tool versus the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description reveals the default COMPACT response shape with exact fields, warns that detailed=true 'can exceed limits on large boards,' and clarifies that with no filters it returns tasks across all accessible boards. This adds meaningful behavioral context without contradicting 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 dense yet efficient: three sentences front-load the core purpose, then provide the compact-shape structure, the detailed alternative, and a pointer to single-task tools. Every sentence serves a purpose, and the embedded JSON snippet is a compact, structured reference.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 14 optional parameters and no output schema, the description covers the essential behavior, response shape, token-limit caveat, and alternatives. It is sufficiently complete for an agent to select and invoke the tool appropriately without needing additional external 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?
Schema coverage is 100%, so each parameter is already documented. The description adds value by explaining the interaction of the detailed parameter with token limits and by stating the global effect of omitting all filters. This goes slightly beyond the schema while not repeating every field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb+resource combination: 'List tasks with optional filters.' It distinguishes itself from related tools by stating 'use get_task / get_task_by_number for one full task,' clearly differentiating a bulk-list operation from single-task retrieval.
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?
Explicit guidance is provided: the default compact shape conserves tokens, detailed=true should be used cautiously on large boards, and get_task/get_task_by_number are recommended when a single full task is needed. This gives clear when-to-use and when-not-to-use direction relative to alternatives.
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:

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

Score Badge

Copy to your README.md:

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

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