plane-ce-mcp

Server Quality Checklist

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

Latest release: v1.1.0
Disambiguation4/5
Most tools target distinct entity-action pairs, with clear separation across projects, work items, states, cycles, modules, pages, and more. Minor overlap exists (e.g., manage_work_item_assignee vs update_work_item's assignees field) but descriptions clarify the differences.
Naming Consistency4/5
Tool names predominantly follow a verb_noun snake_case pattern (e.g., list_projects, create_state, update_cycle). Some inconsistency occurs with get_ vs retrieve_, and set_ vs create_ for property values, but overall the pattern is predictable.
Tool Count2/5
With 142 tools, the surface is overly large and likely overwhelming for most agents. While Plane is feature-rich, many tools could be consolidated (e.g., manage_X_work_items into update_cycle/module). The count far exceeds practical usability.
Completeness5/5
The tool set covers virtually all domain entities: projects, work items, states, labels, cycles, modules, pages, work item types, custom properties, relations, initiatives, milestones, intake items, work logs, and roles. Gaps are minimal given the Community Edition limitations.
Average 3.9/5 across 142 of 142 tools scored. Lowest: 2.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 68 commits in the last 12 weeks
- Last stable release on July 12, 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.
Add a glama.json file to provide metadata about your server.
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?
Annotations indicate a write operation, which description confirms, but no details on whether items are moved or copied, or effects on source cycle. Description adds minimal behavioral context 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Short but includes inaccurate extra parameter. Could be more concise and accurate without the misleading workspace_slug.
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?
No output schema, and description lacks completeness: doesn't explain transfer semantics (move vs copy), required permissions, or whether all work items are affected. Important context missing for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and description adds a workspace_slug parameter not in schema, causing confusion. The inline descriptions are brief and don't clarify format or constraints for the actual parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool transfers work items between cycles, using a specific verb and resource. However, it mentions a workspace_slug parameter not present in the schema, slighting clarity.
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 on when to use this tool vs alternatives like manage_cycle_work_items or list_cycle_work_items. The description lacks usage context and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description only restates 'Delete' without adding new behavioral details like cascading effects or permissions required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes an extra argument (workspace_slug) not in the schema, wasting space. It could be more concise by aligning with the schema.
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 lacks information about return values, error conditions, and dependencies (e.g., cycle must exist). The inconsistency with the schema further undermines completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes workspace_slug as an argument, but it is not present in the schema. It does provide context for project_id and cycle_id as UUIDs, but the inconsistency reduces reliability.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Delete) and the resource (a cycle by ID). It effectively distinguishes from sibling cycle management tools like 'complete_cycle' and 'manage_cycle_work_items'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as archiving a cycle or transferring work items. There is no mention of prerequisites or constraints.
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?
Annotations already declare destructiveHint=true, but the description adds no behavioral context. Worse, it mentions 'workspace_slug' as an argument, contradicting the input schema which only has 'project_id'. This mismatch undermines transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes an incorrect parameter (workspace_slug) not present in the schema, making it misleading. Conciseness is not an excuse for inaccuracy.
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?
As a destructive tool, the description lacks context on consequences, error handling, or reversibility. The parameter error further reduces completeness. No output schema exists to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description lists two parameters but one (workspace_slug) is not in the schema, and the other (project_id) is described only as 'UUID of the project', adding minimal meaning 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 'Delete a project by ID' with a specific verb and resource, distinguishing it from siblings like retrieve_project, update_project, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. The description only states the action, leaving the agent to infer usage from the tool name.
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 indicate destructive and idempotent; description adds no extra context about 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very short, but lacks substance; could include more useful details without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and siblings offering related operations, description fails to provide sufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%; description mislabels project_id as 'UUID of the state' and adds no meaning beyond parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a state by ID', specifying verb and resource. However, it does not differentiate from other delete tools 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., archive), nor prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description merely repeats the action 'delete' without elaborating on consequences (e.g., cascading deletions, reversibility, or permission requirements). Annotations already indicate destructiveHint=true, but the description adds minimal value beyond that. It also incorrectly includes 'workspace_slug' in the args, which is not present in the input schema, creating confusion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains unnecessary 'Args:' formatting and an extraneous parameter. It could be more concise by directly stating the required parameters without the label.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is destructive (destructiveHint=true) and has no output schema, the description should explain what happens on success/failure, any dependencies, and the role of the missing workspace_slug. It fails to provide this context, making it incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It attempts to describe parameters but incorrectly includes 'workspace_slug', an argument not in the schema. While it correctly mentions 'project_id' and 'module_id' as UUIDs, the extra erroneous parameter misleads the agent.
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 'Delete a module by ID', using a specific verb ('delete') and resource ('module'). This distinguishes it from sibling tools like create_module, retrieve_module, and update_module.
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 on when to use this tool versus alternatives. It does not specify any preconditions, dependencies, or cases where deletion might be inappropriate (e.g., if the module has associated work items).
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 indicate destructiveHint=true and idempotentHint=true. The description adds no extra context about side effects, such as whether deletion is hard or soft, or cascading impacts.
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 very concise with a single line and an Args section. No wasted words, but could include more useful detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple destructive tool with no output schema, the description lacks information about return values, confirmation, or recovery. Given the annotations, the description could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only states parameter names and mentions 'UUID' implicitly, but no format examples, validation rules, or additional context beyond what the schema provides.
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 'Delete a work item by ID', which uses a specific verb and resource. Among many siblings with work item operations, this uniquely identifies the deletion 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?
No guidance on when to use this tool versus alternatives (e.g., other delete tools like delete_work_item_relation_definition). No mention of prerequisites or conditions.
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 repeats the word 'delete' from the destructive hint annotation. It fails to disclose important behavioral traits such as irreversibility, cascading effects on related data, required permissions, or idempotency behavior beyond what annotations already provide, adding no new context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with a single line and a bullet list. However, it could be better structured by grouping parameters or adding a sentence about return value. It is not verbose but lacks sufficient detail for a deletion tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and three required parameters, the description does not explain what the tool returns upon success or what errors may occur. It omits confirmation of deletion or any side effects, leaving the agent uncertain about the outcome.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description merely lists parameter names without explaining their hierarchical relationships or formats. For example, it doesn't clarify that project_id is the parent of work_item_id, which would help the agent construct correct invocations.
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 deletes a work log for a work item, using specific verb and resource. It distinguishes itself from sibling tools like create_work_log and update_work_log by its destructive nature, 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as update_work_log or list_work_logs. There is no mention of prerequisites, conditions for deletion, or when not to use it, leaving the AI agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds no behavioral details beyond stating it returns a summary. Furthermore, it includes 'workspace_slug' in the Args list which is not present in the input schema, creating confusion about the actual required parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes unnecessary detail about arguments that are not reflected in the schema, making it slightly misleading. It could be improved by aligning with the actual schema and removing extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description mentions a return type (list of ProjectWorklogSummary objects), which is useful. However, the inconsistency between described args and schema reduces completeness. With only one required parameter and an output schema available (implied), the description is mostly adequate but slightly flawed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description is the sole source of parameter meaning. It explains project_id as 'UUID of the project', which adds basic context. However, it also mentions workspace_slug which is not in the schema, and provides no explanation for its usage or why it appears in the Args but not the 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 states 'Get work log summary for a project', clearly specifying the verb (Get), resource (work log summary), and scope (project). This distinguishes it from sibling tools like list_work_logs which return individual logs, while this returns a summary.
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 on when to use this tool versus alternatives such as list_work_logs. The description simply states what it does and lists arguments, but offers no context about prerequisites, typical use cases, or situations where this tool is preferred.
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 declare readOnlyHint=true, so the read-only nature is known. The description adds no further behavioral context (e.g., pagination, sorting, error handling). The 'params' dictionary is vague and undocumented.
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?
Concise with no wasted words; uses a clear docstring format. However, it could be even more efficient by omitting obvious parameter types if schema already provides, but it's acceptable.
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?
Despite having an output schema, the description omits important details like filtering, sorting, pagination, and error scenarios. For a listing tool with many siblings, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description merely restates parameter types ('UUID', 'dictionary') without explaining accepted query parameters or constraints. Minimal value added over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List work items in a milestone' with specific verb and resource. It distinguishes from sibling tools like 'list_work_items' (which likely lists all work items) and 'manage_milestone_work_items' (which adds/removes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'search_work_items' or 'list_cycle_work_items'. The description lacks when-not-to-use or alternative suggestions.
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=true, so the description's 'retrieve' is consistent. Description adds no extra behavioral details (e.g., idempotency, rate limits), but doesn't need to given annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short and front-loaded, but includes an erroneous parameter (workspace_slug) that undermines accuracy. Conciseness is good, but the error reduces effectiveness.
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 retrieval tool with annotations and output schema, the description is mostly adequate. However, the mismatch between mentioned arguments and actual schema parameters leaves some incompleteness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description should clarify parameters. It incorrectly includes workspace_slug not in schema, and while it specifies UUIDs for project_id and module_id, it doesn't describe allowed formats or constraints comprehensively.
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?
Description clearly states 'Retrieve a module by ID' with verb and resource. However, it mentions workspace_slug as an argument that is not in the input schema, causing slight confusion.
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 on when to use this tool versus alternatives like retrieve_project or other retrieve tools. No mention of context or 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 declare readOnlyHint=true, which is consistent. Description adds that it returns a 'Project object'. No additional behavioral details like error handling or auth needs are provided, but for a simple read operation 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and structured with an Args section. However, the Args section contains a parameter not in the schema, making it technically inaccurate. Could be improved by removing workspace_slug. As is, it's still relatively concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists so return details are not needed. However, the inconsistency in parameters (workspace_slug) creates confusion. No mention of error cases or edge cases. For a retrieval tool, it should at least match the schema accurately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% so description must compensate. It adds that project_id is a UUID, which is helpful. However, it also lists workspace_slug as an argument which is not in the schema, introducing false information. This undermines reliability.
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 verb 'Retrieve' and resource 'project by ID' clearly state the tool's purpose. However, the description mentions 'workspace_slug' which is not in the input schema, causing slight confusion. Among siblings like list_projects and update_project, this tool is clearly for single entity retrieval.
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 on when to use this tool vs alternatives. Does not specify that it returns a full project object or that it is idempotent. Missing context about when to prefer this over list_projects or search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate mutation (readOnlyHint=false, destructiveHint=false) and openWorldHint=true. The description adds only 'Returns: Created Cycle object' and parameter formats. It does not disclose side effects, validation rules, error scenarios, or permission requirements. Minimal behavioral context beyond what annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args and Returns sections, front-loading the action. It is concise despite listing many parameters, but the inclusion of 'workspace_slug' adds noise. Overall efficient.
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?
While the description lists parameters and return type, it lacks context on when to create a cycle, constraints (e.g., unique names), and the inconsistent workspace_slug parameter undermines completeness. With an output schema, return values are covered, but behavioral context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description provides explanations for all 9 parameters, including format hints (e.g., ISO 8601 for dates, UUID for identifiers). However, it lists 'workspace_slug' which is not in the input schema, causing a discrepancy. The descriptions add value but are not fully consistent.
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 'Create a new cycle' with a list of parameters. It distinguishes from sibling tools like retrieve_cycle, update_cycle, etc., but does not explicitly differentiate from other creation tools like create_project or create_state. The purpose is clear and specific enough for most agents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No mention of prerequisites (e.g., needing a workspace slug) or context when create vs. manage_cycle_work_items should be used. The description lacks any usage direction.
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 provide readOnlyHint=true and openWorldHint=true, so the description's behavioral disclosure is adequate. It adds a return type hint but does not detail pagination, error behavior, or other side effects beyond what annotations imply.
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 short and structured as a docstring with Args and Returns sections. It is front-loaded with the main purpose. However, the inclusion of a non-existent parameter slightly detracts from conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of output schema and annotations, the description covers the basic purpose and parameters. However, it lacks context about what a cycle is and includes an erroneous parameter, limiting completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists 'workspace_slug' as an argument, but the input schema does not include it, which is misleading. It does provide type hints (UUID) for the two schema parameters, but schema coverage is 0%, so the description only partially compensates and introduces an error.
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 tool name 'retrieve_cycle' and description 'Retrieve a cycle by ID' clearly state the action and resource. However, the description does not distinguish it from sibling retrieve tools like 'retrieve_project' or 'retrieve_module'.
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, nor are there any conditions or exclusions mentioned. The description is purely functional without usage context.
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 confirm read-only behavior, which is consistent with 'Retrieve'. Description does not elaborate on side effects or data scope beyond the return type. With readOnlyHint and openWorldHint, additional context missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured as a docstring with clear Args/Returns sections but includes an extra non-existent parameter. It is moderately concise but the error hurts efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema, return values are not needed, but the description lacks explanation of what 'intake work item' means versus regular work items. The workspace_slug mismatch indicates incomplete context for a new user.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must explain parameters. It adds guidance for work_item_id and mentions params, but incorrectly includes workspace_slug which is not in the schema. This error undermines the added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that it retrieves an intake work item by ID, specifying the action and resource. However, it mentions 'workspace_slug' as an argument that is not present in the input schema, which could cause some confusion.
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?
Provides guidance on using the 'issue field' for work_item_id, but does not explicitly differentiate from sibling tools like 'retrieve_work_item' or 'list_intake_work_items'. The implied usage context is present but not explicit.
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 provide readOnlyHint=false and destructiveHint=false, but the description adds minimal behavioral context beyond stating it creates a comment. It does not disclose idempotency, rate limits, or what happens with conflicting parameters like comment_html and comment_json.
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 structured as a docstring with a clear first sentence stating purpose, followed by a parameter list. It is concise without unnecessary words. The parameter list is needed due to zero schema coverage, so it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, output schema, and is a mutation in a complex API, the description is incomplete. It does not explain parameter interactions (e.g., comment_html vs comment_json), required permissions, or validation rules. Lacks context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides basic meanings for all 7 parameters (e.g., 'UUID of the project', 'Access level for the comment (INTERNAL or EXTERNAL)'). However, it lacks details on constraints, usage patterns, or parameter interactions.
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 'Create' and the resource 'comment for a work item'. It aligns with the tool name and distinguishes from sibling CRUD operations like update, delete, list.
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 (e.g., update_work_item_comment for editing). It does not mention prerequisites or exclusion criteria. Sibling names imply usage but description lacks explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds no behavioral context beyond the obvious action. Lacks details on irreversibility, permissions, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is very short with no unnecessary repetition. However, it could be better structured or include a brief note on behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and multiple sibling tools, the description lacks completeness. Does not explain post-deletion state or how to verify success. Minimal for a destructive action.
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 0%, so description must compensate. It adds 'UUID of the project' which provides type clarity beyond the schema's 'string'. However, it is minimal and does not explain constraints like required format or existence.
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 'Delete the estimate for a project', which is a specific verb and resource. It distinguishes from sibling tools like get_project_estimate, create_project_estimate, update_project_estimate, etc.
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 on when to use this tool versus alternatives. Does not mention prerequisites or context (e.g., estimate must exist). No exclusions or when-not-to-use information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, but description adds no behavioral details such as pagination, ordering, or authorization requirements. Minimal value 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short and includes args in a list format. Efficient, though could be slightly better structured with bullet points.
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?
Adequate for a simple list tool with output schema present, but misses important context like default ordering, pagination behavior, or any limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%; description only states parameter types (UUID, dictionary) without explaining acceptable query parameters for 'params'. No mention of pagination or filtering.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List comments for a work item', using a specific verb and resource. It distinguishes from sibling tools like retrieve_work_item_comment (single retrieval) and comment CRUD tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., retrieve_work_item_comment for a single comment). No prerequisites or context provided.
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 non-destructive, idempotent, non-read-only. Description adds return type but no extra behavioral details like default behavior for omitted parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Structured as a docstring with purpose first, but parameter list is lengthy. No unnecessary wording, but could be more concise by omitting obvious parameter names.
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?
Output schema exists, so return info is covered. Parameter documentation is adequate for a simple update, but lacks context on usage scenarios or parameter interactions.
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?
22 parameters described with one-line explanations, adding meaning beyond schema types. However, many descriptions are minimal and schema coverage is 0%, so description partially compensates.
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 'Update a project by ID' and lists parameters. It distinguishes from create/delete, but not from update_project_features, a sibling that might overlap.
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 on when to use this vs alternatives like update_project_features. No when-not-to-use or exclusion criteria mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds no behavioral context beyond annotations; annotations already indicate mutation (readOnlyHint=false) and idempotency (idempotentHint=true), but description only restates the parameter list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise in the one-liner but includes a verbose parameter list; could be more compact without losing clarity.
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?
Adequate for a simple update operation given output schema exists, but lacks usage context and behavioral details beyond 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?
Schema description coverage is 0%, so description compensates by listing parameters with brief descriptions; provides some added value (e.g., color format, group examples) but mostly mirrors schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Update' and the resource 'state by ID', and distinguishes from sibling tools like create_state, delete_state, and list_states.
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 on when to use this tool over alternatives; lacks context on when an update is appropriate versus creation or retrieval.
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, consistent with creation. The description adds no further behavioral traits (e.g., permission requirements, side effects, or lifecycle details). With annotations present, the description provides minimal additional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main sentence but includes a docstring-style Args/Returns section. It is not overly long, but the inclusion of a non-existent parameter (workspace_slug) wastes some space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 required parameters and an output schema, the description is minimal. It explains the return type but does not elaborate on what an intake work item is or any constraints. For a create operation, it is moderately complete but could be improved with more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists parameters workspace_slug, project_id, and data, but workspace_slug is not in the input schema (only project_id and data are required and defined). This error reduces clarity. Data is described as a dictionary, which aligns with the schema's object type. However, the schema coverage is 0%, so the description adds some meaning but contains a factual mistake.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Create a new intake work item in a project,' clearly identifying the action (create) and resource (intake work item). Among sibling tools like 'create_work_item', this distinguishes intake-specific creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as 'create_work_item' for regular work items. There are no usage prerequisites or exclusion scenarios mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate writes (readOnlyHint false) but description does not disclose any additional behavioral traits (e.g., side effects, permissions, rate limits). Major inconsistency: description lists workspace_slug parameter not present in input schema, causing potential confusion.
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?
Structured as a list of arguments following a clear one-line purpose. Reasonably concise for 19 parameters, though could be slightly tighter.
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?
Covers purpose and parameters, but lacks context on side effects (openWorldHint true). Inconsistency with workspace_slug reduces completeness. Output schema exists so return description is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description provides brief explanations for each parameter (e.g., 'Project identifier (e.g., MP for My Project)'), adding value over bare schema (0% coverage). However, workspace_slug is described but missing from schema, and defaults are not mentioned despite schema showing null defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Create a new project' with specific verb and resource. Differentiates from sibling tools like update_project and delete_project by indicating creation.
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 on when to use this tool vs alternatives. Does not mention prerequisites or context for selecting this tool over update_project or list_projects.
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 repeats the delete action, which is already captured by the destructiveHint annotation. It adds no new behavioral context such as reversibility, impact on associated work items, permission requirements, or error conditions. Given annotations already convey destructiveness, the description fails to provide additional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for purpose and a minimal args list. Every part is necessary and no words are wasted. It is well structured with a clear separation of function and parameters.
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 delete tool with annotations covering idempotency and destructiveness, the description is mostly adequate. However, it omits important context such as whether deletion cascades, if the label must exist, or how to obtain the IDs. Missing details reduce completeness for an agent operating in a complex environment with many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by listing both parameters (project_id and label_id) and briefly explaining each as a UUID. This adds meaning beyond the schema's type-only definitions, though it lacks further details like format constraints or examples.
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 'Delete a label by ID', specifying the action (delete) and resource (label). While it doesn't explicitly distinguish from siblings, the verb itself differentiates it from create, update, and retrieve operations. It is concise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like manage_work_item_label or update_label. There is no mention of prerequisites, scenarios, or conditions for deletion, leaving the agent to infer usage context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true and destructiveHint=false, but the description adds no extra behavioral context beyond stating the update operation. It doesn't clarify partial update semantics or nullification behavior.
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 docstring format is clear and front-loaded with the purpose, though the parameter list is somewhat verbose. It is logically structured with Args and Returns.
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 is sufficient for a simple update operation, but lacks specification on return format (output schema not shown) and patch behavior. Given the tool's moderate complexity and available annotations, it is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description lists parameters with minimal explanations (e.g., 'title: Milestone title'). It provides basic type info but lacks details on constraints (e.g., that fields can be null). Baseline compensation is adequate but not rich.
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 a milestone by ID' and lists the specific parameters. It distinguishes itself from siblings like create_milestone, retrieve_milestone, and delete_milestone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as when to patch versus replace, or prerequisites like existing milestone.
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 indicate readOnlyHint=false, destructiveHint=false, idempotentHint=false. The description adds no behavioral traits beyond 'link'. It does not explain idempotency behavior (if already linked), permissions, or effects. Minimal additional value.
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 two clear sentences plus Args/Returns. No redundant text. Efficient, though could be slightly more structured with bullet points.
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 presence of annotations and an output schema, the description covers basic purpose and parameters. However, it lacks behavioral context (idempotency, error states) and prerequisites. Adequate for a simple operation but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It lists parameters with trivial 'UUID of the project/work item/page' but adds no meaningful semantics beyond the names. Should clarify roles like 'project containing the work item'.
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 'Link a page to a work item' using a specific verb and resource. It distinguishes from sibling tools like 'detach_page_from_work_item' and 'list_work_item_pages'.
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 basic purpose but no explicit guidance on when to use versus alternatives (e.g., 'detach_page_from_work_item'). It does not mention prerequisites or edge cases like whether linking is idempotent. Usage context is implied.
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 indicate readOnlyHint=false (write operation) and destructiveHint=false. The description adds that it 'creates' and 'Returns: Created Label object,' which is consistent but provides minimal extra context about side effects, authentication requirements, or rate limits. No behavioral details beyond the obvious creation action are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a single introductory sentence followed by a bullet list of parameters with brief descriptions, and a return statement. It front-loads the purpose and uses space efficiently. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters and an output schema (implied by 'Returns: Created Label object'), the description covers all parameters with sufficient detail. It does not explain the return format, but output schema likely handles that. The description is complete enough for an agent to understand the tool's purpose and required inputs, though it could mention potential side effects or constraints like uniqueness of label names.
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 0%, so the description carries full burden. It lists all 8 parameters with clear, meaningful descriptions (e.g., 'project_id: UUID of the project', 'color: Label color (hex color code)'). This adds significant value beyond the schema's type-only definitions. Could be improved by noting which parameters are required, but that is partially covered by the schema's required list.
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 'Create a new label,' which is a specific verb+resource combination. It distinguishes itself from sibling tools like list_labels, retrieve_label, update_label, and delete_label by being the creation action. However, it could be improved by explicitly contrasting with manage_work_item_label or other label-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives like update_label or delete_label. The description only lists parameters, implying the need for a project_id and name, but does not state prerequisites or conditions under which creation is appropriate. Sibling tools are numerous but no exclusions or context are 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 indicate readOnlyHint=false and not destructive, but the description only repeats 'Create' without detailing side effects (e.g., does it trigger notifications? require specific permissions?). No behavioral context beyond what annotations imply.
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: a single sentence plus a clean list of parameters and return. Every element is functional with no wasted words.
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?
While the output schema exists (so return type is documented), the description omits important creation context: no mention of duplicate handling, required permissions, or whether the milestone is immediately associated with the project. It's minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It provides one-line comments for each parameter (e.g., 'UUID of the project') but lacks richer semantics like formatting constraints, validation rules, or relationships between 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 states 'Create a new milestone' with a specific verb (create) and resource (milestone). This clearly distinguishes it from sibling tools like update_milestone, retrieve_milestone, and list_milestones.
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 (e.g., create_work_item for task milestones). No prerequisites, exclusions, or context about project relationships are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and idempotentHint=false, consistent with creation. Description adds no additional behavioral context beyond the basic nature of creation.
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?
Extremely concise with a one-line summary and clear Args/Returns structure. No wasted text.
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?
Simple tool with output schema. Missing context on idempotency, uniqueness, or required prerequisites (e.g., valid work item). Adequate but not thorough.
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 0%. Description lists parameters with basic types (UUID, URL) but no constraints or format details. Provides minimal meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a link for a work item' with a specific verb and resource. It distinguishes from siblings like retrieve, update, delete links.
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 on when to use this tool vs alternatives (e.g., list_work_item_links, create_work_item_relation). No context on preconditions or avoidances.
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, so the description's 'Delete' aligns. It adds detail about the expected identifier (issue field), but does not disclose side effects, permissions, or consequences beyond the action. With annotations covering the safety profile, the description provides moderate additional value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes an Args block with a superfluous parameter (workspace_slug not in schema). This reduces efficiency. The core statement is concise but the extra detail is misleading, making it average.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with no output schema and annotations covering safety, the description should clarify what an intake work item is and whether deletion is reversible. The presence of an erroneous parameter (workspace_slug) indicates incomplete specification. The note about work_item_id helps but overall completeness is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It describes project_id as UUID and work_item_id with a specific source. However, it incorrectly lists workspace_slug as an argument not present in the schema, causing confusion. This inconsistency undermines the semantics provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action and resource: 'Delete an intake work item by work item ID.' This distinguishes it from siblings like delete_work_item. The verb-resource pair 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a specific note about using the issue field for work_item_id, which guides correct invocation. However, it offers no explicit guidance on when to use this tool versus alternatives like delete_work_item or delete_intake_work_item itself. Context for tool selection is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true and readOnlyHint=false. The description adds no additional behavioral context such as irreversibility, permission requirements, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short and front-loaded with the action. However, it repeats parameter names in a list format, which is acceptable.
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 delete operation with no output schema, the description lists required parameters and is complete enough. It could mention that deletion is irreversible.
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 0%, but the description adds minimal value by stating each parameter is a UUID. This clarifies the expected format beyond the parameter name but lacks additional constraints.
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 'Delete a single estimate point', indicating the action and resource. It distinguishes among sibling delete tools by specifying 'estimate point'.
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 on when to use this tool vs alternatives like delete_project_estimate or delete_work_item. No context about prerequisites or 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true, so the description's mention of 'Delete' aligns. The description adds no additional behavioral context beyond what annotations provide, such as error handling or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, listing parameters in a structured Args block. It is slightly padded with the 'Args:' header but remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (delete a link with three required params), the description is adequate but could mention return values or error cases. It lacks details about idempotency or what happens when the link does not exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description should add meaning beyond the property names. It lists parameter names and states they are UUIDs, but does not explain their format, constraints, or behavior. This adds minimal value over 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 'Delete' and the resource 'link for a work item'. It distinguishes itself from sibling tools like create_work_item_link, update_work_item_link, and retrieve_work_item_link.
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, nor are there any prerequisites or conditions mentioned. The name and description imply a straightforward delete, but no extra context is 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 readOnlyHint=true, so the agent knows it's a safe read operation. The description adds no further behavioral traits beyond the parameter list, but the read-only nature is consistent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with Args and Returns sections, but it includes 'workspace_slug' which is not in the schema, wasting space and potentially misleading. The description is otherwise reasonably concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description does not need to explain return values. However, the inconsistency with 'workspace_slug' and lack of pagination or filtering details beyond 'params' makes the description incomplete for a list tool. More guidance on when to use this over list_work_items would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning by mentioning 'workspace_slug' as an argument, but this parameter is not present in the input schema, causing inconsistency. The description of 'params' as optional query parameters (per_page, cursor) adds some value, but the schema coverage is 0% and the extra invalid parameter reduces reliability.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all intake work items in a project,' which is a specific verb+resource+scope. It distinguishes itself from sibling tools like list_work_items by specifying 'intake' work items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing intake work items in a project, but does not explicitly state when to use this tool versus alternatives like list_work_items, nor does it provide 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 indicate readOnlyHint and openWorldHint, which are not contradicted. The description adds that it returns a list of WorkItemActivity objects, but provides no further behavioral context 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with clear Args and Returns sections. It avoids unnecessary words, though the Returns section may be redundant given the output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with an output schema, the description covers the basics but lacks details on ordering, filtering, pagination, or what constitutes an 'activity'. With only 3 parameters and no enums, it is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description merely lists the parameters in the Args section without adding meaning beyond type and required status (e.g., no explanation of 'params' format or allowed keys).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List activities for a work item', specifying verb and resource. It requires project_id and work_item_id, and distinguishes from sibling tools like 'retrieve_work_item_activity' (single activity).
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 on when to use this tool vs alternatives. There is no mention of when not to use it or what distinguishes it from similar list tools like 'list_work_item_comments' or 'retrieve_work_item_activity'.
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=true and openWorldHint=true. The description adds that the return type is 'WorkItemDetail object with expanded relationships', which provides helpful context beyond the annotations but does not discuss auth, rate limits, or other behaviors.
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 a one-line summary followed by parameter and return definitions. It is structured but could be further improved by using shorter descriptions for obvious parameters.
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 existence of an output schema, the return value description is adequate. However, the description lacks guidance on when to use this tool versus related tools like 'list_work_items' or 'search_work_items', and does not address the openWorldHint implications.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description lists all parameters and provides meaning for 'expand' and 'fields' (comma-separated). While not exhaustive, it adds enough value to compensate for the missing schema descriptions.
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 'Retrieve' and resource 'work item'. However, it does not differentiate from sibling 'retrieve_work_item_by_identifier', which may cause confusion about which tool to use for non-ID lookups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'retrieve_work_item_by_identifier' or 'search_work_items'. It does not mention prerequisites or common use cases.
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 indicate idempotent and non-destructive mutation. The description says 'Update' but does not provide additional behavioral details such as partial update capability, side effects, or permission requirements beyond what is obvious from the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured as a docstring with an Args list, but it is verbose and includes redundant parameter listings that mirror the schema. Could be more concise by omitting obvious fields.
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 presence of an output schema (not shown) and annotations covering idempotency and safety, the description adequately explains parameter semantics and overall purpose. Missing error or edge-case information, but sufficient for a standard update tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args section adds meaningful context to each parameter (e.g., 'ISO 8601 format' for dates), which goes beyond the schema that only has types and defaults. With 0% schema coverage, the description fully compensates.
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 begins with 'Update a cycle by ID' which clearly states the action (update) and resource (cycle). It distinguishes from sibling tools like create, retrieve, delete, and complete by the verb, but does not explicitly differentiate.
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 on when to use this tool versus alternatives like complete_cycle, or any prerequisites or context. The description only lists parameters without usage context.
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 read-only nature is clear. The description adds minimal behavioral context beyond that, such as the return type being a list of WorkItemLink objects. It does not contradict annotations, but it does not disclose additional traits like authorization requirements or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using a docstring format that lists arguments and return type in a structured way. Every sentence adds value, and it is front-loaded with 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?
Given the output schema exists, the description adequately states the return type. However, it lacks context about what a WorkItemLink represents, how it differs from other link or relation types, and whether pagination or filtering is supported. The tool is simple but could benefit from more completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by documenting the two required parameters as UUIDs and the optional params as a dictionary. This adds meaningful type and structure information beyond the bare schema, helping the agent understand expected values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists links for a work item. It uses a specific verb ('list') and resource ('links for a work item'), but it does not differentiate from the sibling tool 'list_work_item_relations', which might cause confusion. The purpose is clear but lacks sibling distinction.
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. The sibling list includes many similar tools (e.g., list_work_item_relations, list_work_item_activities), and the description offers no context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only (readOnlyHint=true) and open-world (openWorldHint=true). The description adds no behavioral details beyond the basic retrieve action, such as required permissions or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, front-loading the purpose in the first sentence, and using a structured Args/Returns format with no unnecessary text.
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 retrieval tool with one parameter and an output schema, the description is adequate. It mentions the return fields (name, slug, namespace), which adds value.
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?
With 0% schema description coverage, the description adds minimal meaning by clarifying that role_id is a UUID. This is helpful but does not fully compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a role definition by ID, using a specific verb and resource. It distinguishes from sibling tools like list_roles (which lists all roles) and other retrieve tools for 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 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. For example, it doesn't mention that list_roles should be used to list all roles.
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 says 'create', which is consistent with annotations but adds no behavioral context beyond the annotations themselves. It does not mention idempotency, side effects, permissions, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear one-sentence purpose, a parameter list, and a return description. It is front-loaded and each line adds value, though the parameter list could be more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 10 parameters and an output schema, the description covers the essential purpose and parameter meanings. It does not explain relationships or constraints further, but for a creation tool this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by listing all 10 parameters with brief but meaningful explanations (e.g., 'project_id: UUID of the project', 'color: State color (hex color code)'). This adds value beyond the schema types.
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 'Create a new state.' with a list of parameters and return type. This verb+resource combination is unambiguous and distinct from sibling tools like list_states, update_state, and delete_state.
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 does not provide any guidance on when to use this tool versus alternatives. It lacks explicit context on prerequisites, when not to use it, or comparisons to related tools like update_state.
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 does not elaborate on behavioral traits beyond what annotations provide. With readOnlyHint=false, the agent knows it's a write operation, but no details on permissions, side effects, or limits are mentioned. The description adds no extra 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and structured as a docstring with clear parameter documentation. It wastes no words, though it could be slightly more compact by omitting the 'Args' section pattern.
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 presence of an output schema (which documents return values), the description adequately covers the input side. It explains all required and optional parameters sufficiently for an agent to invoke the tool, though it lacks usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite having 0% schema description coverage, the description explicitly lists each parameter with a brief explanation (e.g., 'duration: Duration of work in minutes'), adding meaning beyond the raw type definitions 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 tool's action ('Create') and resource ('work log'), with the target context ('for a work item'). It is easily distinguishable from sibling tools like 'list_work_logs', 'update_work_log', and 'delete_work_log'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, such as 'create_intake_work_item' or 'create_work_item'. There is no discussion of prerequisites, conditions, or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=false, destructiveHint=true, idempotentHint=true. The description adds no additional behavioral context such as cascading effects or reversibility.
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?
Extremely concise: two short sentences plus parameter list. Every word is necessary 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?
Given no output schema and simple delete action, description is adequate but could mention side effects or restrictions. Siblings like manage_milestone_archive provide alternatives not referenced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so the description adds value by stating 'UUID of the project' and 'UUID of the milestone', clarifying the required IDs.
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 'delete' and the resource 'milestone', distinguishing it from sibling tools like delete_project, delete_cycle, etc.
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 on when to use this tool vs alternatives like manage_milestone_archive or other delete tools. The description provides no context for decision-making.
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 indicate destructiveHint=true, but description only repeats the delete action without disclosing potential side effects or scope limitations beyond parameter descriptions.
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?
Extremely concise: one purpose sentence followed by bullet-style parameter descriptions. No wasted words.
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?
Adequate for a simple deletion tool with annotations, but lacks error conditions, prerequisites (e.g., property must exist), or behavior when option is in use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, description adds UUID explanations for each parameter and notes project_id can be omitted for workspace scope, providing meaningful context beyond field names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete) and the resource (option from work item property), distinguishing it from sibling tools like delete_work_item_property or delete_work_item_property_value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. Does not mention prerequisites or cases where other deletion tools might be preferred.
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 declare destructiveHint=true and idempotentHint=true. The description adds no additional behavioral context, such as whether deletion cascades or if underlying relations must be empty first. It simply restates the name's action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with no fluff. The verb-resource pattern is front-loaded, and the parameter is documented efficiently. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (single parameter, no output schema), the description covers the basics but leaves gaps. For a destructive and idempotent tool, it does not address side effects or prerequisites (e.g., whether the definition must be unused). It is adequate but not thorough.
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?
With 0% schema description coverage, the description must compensate. It documents the parameter 'definition_id' as 'UUID of the relation definition to delete,' adding purpose beyond the schema. However, it omits format specifics or constraints beyond the term 'UUID', leaving some ambiguity.
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 ('workspace relation definition'), leaving no ambiguity. It effectively distinguishes the tool from siblings like create, update, and list.
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 deletion of a relation definition is needed, but provides no explicit guidance on when to use versus alternatives, no prerequisites, and no exclusions. For a destructive tool, context about requirements (e.g., no existing relations) would be helpful.
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 description's statement of returning a List of State objects adds some context but doesn't disclose pagination, sorting, or other behaviors. It does not contradict 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 extremely concise, with three short sentences that directly convey the purpose and parameters. Every sentence adds value, and the key information is front-loaded.
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 and the presence of an output schema (implied by 'Returns: List of State objects'), the description covers the basic purpose and parameters. However, it lacks details on pagination or filtering behavior for the list, which is a common need for such tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description adds meaning by explaining project_id as a UUID and params as optional query parameters as a dictionary. However, it doesn't specify available query parameter keys or values, leaving the agent to guess the full range of options.
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 'all states in a project', which is specific and distinguishes it from sibling tools like retrieve_state (single state) or create_state. It leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like retrieve_state for a single state or list_projects for projects. It lacks context on prerequisites or filtering, leaving the agent to infer usage without explicit help.
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 indicate write operation (readOnlyHint=false) and openWorldHint=true, but the description does not disclose potential side effects, required permissions, or behavior if both add and remove overlap. It adds minimal value beyond what annotations suggest.
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?
Extremely concise: four lines including the Args list. Every sentence adds value, and the most important information (purpose and constraint) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description should explain return value or confirmation. It does not mention atomicity or error handling. Still, for a simple add/remove operation, the coverage is adequate but not 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?
With 0% schema description coverage, the description compensates by explaining each parameter's purpose (e.g., 'UUID of the project'). However, it does not specify format constraints (e.g., valid UUID) or limits on array sizes, leaving some ambiguity.
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 (add or remove), the resource (work items on a milestone), and the scope (in a single call). It is specific and distinguishes the tool from siblings like manage_cycle_work_items and manage_module_work_items, even without explicit comparison.
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?
Provides a clear constraint: 'At least one of add_ids or remove_ids must be provided.' However, it lacks guidance on when not to use this tool versus alternatives (e.g., when to use manage_cycle_work_items instead). No exclusions or context about 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 include readOnlyHint=true and openWorldHint=true. The description describes a read operation (retrieve) which aligns with readOnlyHint. It adds that the return is a Label object, but does not discuss potential errors, permissions, or side effects. The description adds minimal behavioral context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for purpose, followed by a structured argument and return section. Every part is necessary, and the key information is front-loaded. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (retrieve by ID) and the existence of an output schema (indicated by context), the description covers the essential functional aspects. It does not mention error handling or not-found cases, but for a straightforward retrieval, this level is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), but the description provides docstrings: 'project_id: UUID of the project' and 'label_id: UUID of the label', adding semantic meaning (the expected type UUID) beyond the schema's plain string type. This compensates for the schema's lack of descriptions.
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 'Retrieve a label by ID' specifying the verb and resource. It also lists the required parameters (project_id, label_id). However, it does not explicitly differentiate from sibling tools like list_labels or other retrieve tools, but the purpose is clear enough.
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 on when to use this tool versus alternatives. The description does not mention that this is for retrieving a single label by ID, while list_labels would be used for listing all labels. No explicit conditions or exclusions are provided.
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 idempotent (idempotentHint: true) and non-destructive (destructiveHint: false). Description adds error behavior when feature disabled, but lacks details on permissions or side effects. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Structured as parameter list with returns and raises, front-loading purpose. Somewhat verbose with full parameter list repeated from schema. Adequate but could be more concise.
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 annotations and output schema, description covers purpose, parameters, and errors. Lacks usage context and deeper behavioral details. Fairly complete for a mutation tool but not exhaustive.
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?
Lists all parameters with names and types, adds format info (ISO 8601 for dates). However, schema coverage is 0% and description does not explain semantics beyond what is in the schema, e.g., logo_props structure is unclear. Baseline 3 due to low coverage and superficial help.
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?
Explicitly states 'Update an initiative by ID', which clearly conveys the action and resource. Distinguishes from siblings like create_initiative, retrieve_initiative, and delete_initiative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or when not to use. Context implied by name and sibling tools, but lacks clear comparisons or prerequisites, which is a gap given many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate mutability (readOnlyHint=false) but description adds minimal behavioral context beyond what annotations provide. The default value of last_used=true is noted, but other side effects are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with Args and Returns sections, and the main purpose is front-loaded. Could be more concise by omitting redundant parameter details already in the schema.
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?
Covers basic creation but misses guidance on when to use this vs. create_project_estimate_points, and does not fully explain the 'type' parameter or external system fields. Output schema exists but is not detailed.
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 0%, so description provides essential meaning for parameters (e.g., 'UUID of the project', 'Name of the estimate...'). However, it lacks detail on the 'type' parameter values and implications of external_id/source.
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 'Create a new estimate for a project' with a specific verb and resource, distinguishing it from sibling tools like create_project_estimate_points, update_project_estimate, and delete_project_estimate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like create_project_estimate_points. The description lists parameters but does not provide context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, so the bar is lower. The description adds no additional behavioral context, such as that the deletion is permanent or requires specific permissions. It neither contradicts nor enriches 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 extremely concise: one line for the action and a list of arguments. Every sentence is necessary and efficiently conveys the tool's purpose and required inputs.
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 delete operation, the description, combined with annotations and schema, provides near-complete information. It lacks mention of return value or error scenarios, but these are typical for delete tools and not critical.
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?
With 0% schema description coverage, the description adds value by specifying that each parameter is a UUID. However, the parameter names are already self-explanatory, and the description only adds 'UUID of the ...' which is minimal but helpful.
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 'Delete a comment for a work item,' specifying the verb and resource. Among siblings like delete_work_item and delete_work_item_relation_definition, it uniquely identifies the action of deleting a work item 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 or when not to use this tool. There is no mention of prerequisites, permissions, or alternatives. The description simply states the action without any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true and idempotentHint=true. The description does not add behavioral details beyond 'Delete', such as potential side effects, prerequisites, or error scenarios.
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?
Extremely concise: one action sentence followed by clear parameter explanations. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple delete operation. Annotations cover safety and idempotence. Missing details like failure modes, but acceptable given tool simplicity.
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?
Despite 0% schema description coverage, the description explains both parameters: work_item_type_id as UUID and project_id as UUID with scope clarification. This adds meaning beyond the schema structure.
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 'Delete a work item type by ID', using a specific verb and resource. It distinguishes from sibling tools like delete_work_item (deletes a work item) and other delete operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention conditions, when-not, or provide context for choosing delete_work_item_type over other delete or update tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint. Description confirms read-only listing and return of Milestone objects. No contradictions, but minimal added behavioral insight.
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?
Short and front-loaded with purpose and args. Efficient, no superfluous text. Could be slightly more structured but overall concise.
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?
Output schema exists, so return value is covered. Annotations handle safety. Description adequately explains purpose and parameters, but lacks depth on params behavior given openWorldHint.
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?
With schema coverage at 0%, description explains project_id as UUID and params as optional dictionary. Lacks specifics on allowed keys or usage, but covers basic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'List all milestones in a project' with specific verb and resource. Distinguishes from retrieve_milestone and other milestone functions.
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?
Does not explicitly state when to use or not use this tool versus alternatives. Provides no exclusions or context for choosing among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a write operation (readOnlyHint=false). The description adds no further behavioral context, such as side effects, permission requirements, or changes to module visibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear two-line summary followed by a parameter list. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple toggle operation, the description covers the core purpose and parameters. However, it does not mention return values or success indicators, but given no output schema, this is acceptable. It could include more about the effect on the module.
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 0%, but the description explains each parameter: project_id, module_id, and archive. This adds meaning beyond the schema types, though the explanations are brief.
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 'Archive or unarchive' and the resource 'module', and it lists the required parameters. It distinguishes from siblings like manage_project_archive and manage_work_item_archive by focusing on modules.
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 on when to use this tool versus alternatives like manage_project_archive or manage_module_work_items. It does not specify prerequisites or when it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this tool modifies data (readOnlyHint=false) and is idempotent (idempotentHint=true). The description adds no further behavioral context such as authentication needs or side effects, so it meets the baseline but adds no extra value.
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, using a single paragraph with a clear list of arguments. It is well-structured and front-loaded with the purpose. Minor redundancy with schema type info does not significantly detract.
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 explains all parameters and notes the return type, but lacks details on update behavior (e.g., partial vs full replacement), constraints, or validation rules. Given the output schema exists, return values are covered, but the description remains adequate with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by listing all parameters with brief explanations (e.g., 'UUID of the project', 'Comment content in HTML format', 'Access level for the comment (INTERNAL or EXTERNAL)'), adding meaning beyond the bare schema types.
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 'Update a comment for a work item', specifying the verb 'update' and the resource 'work item comment'. This distinguishes it from sibling tools like create, retrieve, list, and 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, no prerequisites, and no scenarios where it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a non-destructive write operation. The description adds no behavioral context beyond the obvious fact that it creates a module. It does not address authorization, rate limits, or side effects, but the annotations provide a baseline safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-organized. It starts with a clear one-sentence purpose, followed by a bulleted list of parameters with brief descriptions, and ends with the return value. Every line adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
All parameters are thoroughly documented, and the return type is mentioned. However, the description lacks usage context such as prerequisites or relationships with other tools. Given the existence of an output schema (not shown), the return description is sufficient, but overall completeness is slightly hindered by missing usage guidelines.
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?
With 0% schema description coverage, the description fully compensates by providing meaningful explanations for all 10 parameters. It includes allowed values for status, ISO 8601 format for dates, and clarifies types (UUID, list). This is essential for correct parameter usage.
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 opens with 'Create a new module,' clearly specifying the verb and resource. It lists all parameters with their purposes, making the tool's function apparent. However, it does not explicitly differentiate from sibling create tools like create_cycle or create_initiative, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, nor does it specify when not to use it. The agent must infer usage solely from the tool name and parameter list.
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 provide destructiveHint=true and idempotentHint=true. The description adds valuable context: it deletes 'value(s)' and for multi-value properties, all values are deleted. This goes beyond annotations, but it doesn't mention error cases or success response. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main action. The multi-value behavior note is important. The Args list is somewhat redundant with the schema but provides extra context. No wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the destructive nature (annotations) and absence of output schema, the description should clarify success/failure behavior, error conditions (e.g., property not found), and idempotency. It only covers the multi-value nuance. The agent is left wondering what happens upon execution.
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?
With 0% schema coverage, the description bears the burden. It adds labels like 'UUID of the project' etc., providing basic semantic mapping. However, it doesn't add constraints like format validation, immutability, or relationships. For 3 parameters, this is adequate but minimal.
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 deletes value(s) of a custom property on a work item, specifying it's for custom properties and clarifying behavior for multi-value properties. This distinguishes it from siblings like set_work_item_property_value (set) and delete_work_item_property (delete property definition).
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 you want to delete a property value) but does not explicitly guide when to use this over alternatives, nor does it mention prerequisites (e.g., property must exist) or when not to use it. The clarification about multi-value behavior is helpful but not comprehensive 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 value by clarifying that 'work_item_page_id' is the link ID, not the page ID. However, it does not discuss side effects, permissions, or return behavior beyond the removal action. Annotations already indicate destructive and idempotent, so the description adds moderate contextual information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for the action followed by a clean bullet list of three arguments. Every sentence is purposeful and front-loaded, with no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the action and parameters are described, the description is incomplete regarding the output/return behavior, which is important since there is no output schema provided. It does not specify what happens on success (e.g., returns a boolean or void) or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by explaining each parameter's role (e.g., 'UUID of project', 'UUID of the work item page link (not the page ID)'). This adds essential meaning beyond the bare schema, though format details are omitted.
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 page link from a work item') and distinguishes it from related siblings like 'attach_page_to_work_item' and 'list_work_item_pages'. It specifies the exact resource and operation, 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives, nor does it mention prerequisites (e.g., needing the link ID from list_work_item_pages). No explicit 'when to use' or 'when not to use' context is 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 indicate readOnlyHint=true and openWorldHint=true, and the description adds that a ToolError is raised when the initiatives feature is disabled. However, it does not discuss pagination behavior or potential large response sizes beyond the open world hint.
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 but includes a docstring-like breakdown (Args, Returns, Raises) that adds structure. The main sentence is front-loaded, though the docstring format is slightly verbose for a tool description.
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 presence of an output schema and annotations, the description covers the error case and implies pagination via parameter examples. It is reasonably complete but could mention pagination behavior explicitly.
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 parameter 'params' has 0% schema description coverage, but the description elaborates with 'Optional query parameters as a dictionary (e.g., per_page, cursor)', adding meaningful context beyond the empty schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all initiatives in a workspace,' specifying the verb (list), resource (initiatives), and scope (all in workspace). It is distinct from siblings like create, retrieve, update, 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?
No usage guidance is provided. The description does not mention when to use this tool versus alternatives such as list_initiative_projects or retrieve_initiative, nor does it specify prerequisites or limitations.
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 (readOnlyHint=true) already indicate no side effects. The description adds return type but does not disclose pagination, ordering, or any other behavioral details. The return type is helpful but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose, followed by parameter and return documentation. It is slightly verbose due to the structured format but remains clear and free of redundancy. Could be shortened slightly without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only 3 parameters (1 required), no nested objects, and an output schema, the description covers the essential functionality and return type. It could mention pagination or default behavior, but it is largely sufficient for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides clear explanations for property_id and project_id (UUIDs, scope hint), which the schema lacks (no descriptions). params is only vaguely described as 'Optional query parameters', leaving it underdocumented. With 0% schema coverage, the description compensates well for required params.
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 'List options for a work item property' clearly states the verb 'list' and the resource 'options', distinguishing it from sibling tools like create/update/delete options and retrieve single option. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as retrieve_work_item_property_option (for single option) or list_work_item_properties (for properties). The description does not mention 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 provide readOnlyHint=true, so the description's mention of 'Retrieve' is consistent. It adds the return type 'WorkItemActivity object' but does not disclose what happens if the activity is not found or any other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with no wasted words, front-loading the purpose. Every part adds value, and the structure is 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 tool is simple and has an output schema, but the description does not explain what an activity is or mention potential error cases. Adequate for a simple retrieval but could be more informative.
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 coverage is 0%, but the description lists all three parameters and describes them as 'UUID of the project', etc., adding meaning beyond the bare schema types. However, it lacks additional details such as format constraints or examples.
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 'Retrieve a specific activity for a work item', using a specific verb and resource. It distinguishes itself from the sibling 'list_work_item_activities' by specifying 'specific activity'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives like list_work_item_activities. The usage is implied (when you have an activity ID), but no exclusions or context are provided.
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 that this tool is a safe mutation (idempotent, not destructive). The description adds the list of updatable fields (name, description, external_id, external_source) which is useful. However, it does not clarify behavior like partial updates, validation, or error cases. No 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 concise: a single sentence stating the purpose, followed by a structured list of arguments and the return type. Every element is informative and no extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic purpose and parameter semantics. The output schema is present, so return structure is documented elsewhere. However, it lacks usage guidelines, prerequisites, and behavioral details like partial update behavior. Given the tool's simplicity, this is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description carries the full burden. It provides one-line explanations for each parameter, adding meaning beyond type/nullability. For example, it clarifies that 'external_id' is an 'External system identifier' and 'external_source' is 'External system source name'. However, it lacks details like validation rules or format constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action 'Update the estimate for a project', which is a specific verb+resource. Among siblings, there are separate tools for creating, deleting, and getting estimates, so this tool's purpose is clear and distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like create_project_estimate or delete_project_estimate. There is no mention of prerequisites (e.g., the estimate must already exist) or conditions under which updating is appropriate.
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 idempotent, non-destructive, and non-read-only. Description adds minimal behavioral context beyond listing parameters, no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Short and to the point, with a clear structure of description, Args, and Returns. No unnecessary text.
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?
Sufficient for a simple update tool with an output schema. Explains parameters and return type. Could be improved by noting that 'url' is optional.
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?
Despite 0% schema coverage, the Args section explains each parameter (project_id, work_item_id, link_id, url) and their purpose, adding value beyond the schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Update a link for a work item' with a specific verb and resource. Distinguished from sibling tools like create_work_item_link and delete_work_item_link.
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 on when to use this tool versus alternatives (e.g., create or delete). Only describes the action without context.
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 provide idempotentHint and destructiveHint. The description adds conditionals (e.g., required when changing to RELATION) but lacks deeper behavioral context like auth needs or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-structured as a docstring with line breaks. It could be more concise, but for 15 parameters, it is adequately organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of output schema and annotations, the description covers param behaviors and dependencies thoroughly. It lacks usage guidelines but is otherwise complete for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries the full burden. It provides types, examples (e.g., settings format), and dependencies (e.g., relation_type required when updating to RELATION), adding significant value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Update' and the resource 'work item property', distinguishing it from siblings like create, retrieve, delete, and manage work item property tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives such as create or delete work item property. Only parameter dependencies are mentioned, not context of use.
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 indicate readOnlyHint=false, idempotentHint=true, no destructiveness. The description adds 'Update' which is consistent, but provides no additional behavioral context like partial updates 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with Args and Returns sections, front-loaded with main sentence. Slightly verbose due to repeating schema details, but necessary given no schema descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all 8 parameters and mentions return type. With an output schema present and simple update semantics, no major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description adds value by explaining each parameter's purpose (e.g., 'Omit for workspace scope' for project_id, 'List of project IDs this type applies to' for project_ids).
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 'Update a work item type by ID', specifying the action and resource. It distinguishes from sibling tools like 'create_work_item_type' and 'delete_work_item_type'.
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 on when to use this tool versus alternatives, no prerequisites or context provided. The description only lists parameters and returns.
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 indicate write operation (readOnlyHint=false). Description adds context on point dict fields and example but doesn't disclose behavior like duplicate key handling or overwriting. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear header, bullet points, example, and explicit args. Could be slightly more concise, but no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing context about prerequisites (e.g., estimate must exist) and behavior when points already exist. Output schema exists but is not elaborated, which is acceptable.
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 0%, but description compensates by detailing point dict fields, providing an example, and listing required args, adding significant meaning beyond the minimal 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?
Description clearly states 'Create estimate points for a project estimate' and distinguishes from sibling tools like create_project_estimate and update_project_estimate_point by specifying it creates point definitions within an estimate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance relative to siblings. The example implies usage, but prerequisites (e.g., estimate must exist) and alternatives are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only (writes) and non-destructive. The description adds no behavioral context beyond stating it creates a work item. No mention of permissions, side effects, or rate limits. With annotations present, the description falls short of adding significant behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an Args block and clear line-by-line parameter definitions. It is front-loaded with the purpose. While lengthy due to many parameters, every sentence adds information, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (19 parameters, output schema exists), the description adequately explains parameters and return type. However, it does not differentiate from other creation tools (e.g., create_intake_work_item) or mention when to use this specific tool, 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides extensive explanations for each parameter, including types, requiredness, and special behavior (e.g., description_stripped being ignored if description_html is set). This adds substantial value beyond the bare 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 starts with 'Create a new work item,' which clearly states the verb and resource. It distinguishes itself from siblings like update_work_item and delete_work_item by focusing on creation, and the parameter list clarifies the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives (e.g., create_intake_work_item), nor does it provide exclusions or prerequisites. Usage is implied by the purpose but lacks explicit 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?
Annotations already indicate it's not read-only (readOnlyHint=false) and not inherently destructive (destructiveHint=false). The description adds that it 'makes it the active estimate system', which clarifies the effect. However, it does not disclose side effects like overwriting a previous active estimate or authentication requirements. Given annotations, this is acceptable but could be richer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for the action, then clear Args and Returns sections. Every word earns its place. No fluff, perfectly 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 low complexity (2 required params, output schema exists, annotations present), the description provides sufficient information to understand the tool's function and output. However, it lacks mention of error conditions or prerequisites, which would make it more complete. Still, it meets the needs for a simple linking 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?
With 0% schema description coverage, the description must add meaning. It lists both params with their roles (project_id, estimate_id) and mentions UUID type, but does not provide additional context such as where to obtain IDs or constraints. This adds some value beyond the bare names but is minimal.
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 'Link' and identifies the resources 'estimate to a project', clearly stating the outcome 'making it the active estimate system'. This distinguishes it from sibling tools like create_project_estimate (which creates a new estimate) and get_project_estimate (which retrieves the current estimate).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to set an existing estimate as the active one for a project) but does not explicitly mention when not to use it or provide alternatives among siblings. The usage context is somewhat clear but lacks explicit 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?
Annotations already provide readOnlyHint: true and openWorldHint: true. The description only adds 'Returns: List of Label objects', which does not significantly add behavioral context beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear purpose statement followed by Args and Returns sections. Every sentence serves a purpose, and there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description covers the main purpose and return type. However, it does not mention pagination or filtering options, which could be relevant for a list 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?
With 0% schema description coverage, the description adds some meaning by stating 'project_id: UUID of the project' and 'params: Optional query parameters as a dictionary'. However, it does not specify what query parameters are allowed, leaving ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all labels in a project' with a specific verb and resource. It distinguishes from sibling tools like 'create_label', 'retrieve_label', 'update_label', and 'delete_label' by focusing on listing all labels.
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 context 'in a project' but does not explicitly state when to use this tool over alternatives like 'retrieve_label' or 'manage_work_item_label'. Usage is implied but not guided with exclusions or when-not scenarios.
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 claims to list 'ALL valid estimate points', but the annotation openWorldHint=true suggests the result may not be exhaustive, creating a contradiction. Annotations already indicate read-only, but the description does not address the open-world behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose, numbered workflow steps, parameter list, and return description. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the workflow, prerequisites, and return structure (list of EstimatePoint with id/value). Given the output schema exists, it is sufficient, though it could add error handling or validation notes.
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 0%, so the description must compensate. It identifies both parameters (project_id, estimate_id) and explains that estimate_id comes from get_project_estimate, but provides no additional constraints, format, or examples beyond basic UUID mention.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all valid estimate points for a project, distinguishes from sibling CRUD tools (create/update/delete), and explains the output structure with id and value.
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 describes when to use (before update_work_item with estimate_point), provides a 4-step workflow, and mentions prerequisite of having estimate_id from get_project_estimate.
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=true and openWorldHint=true. The description adds that it returns a list of link objects, which is useful but does not disclose additional behavioral traits like pagination or ordering.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core action. At four lines, every sentence contributes meaning, though the Args/Returns formatting is slightly repetitive given the schema and output schema exist.
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 and the presence of an output schema, the description provides the essential purpose and parameters. However, it lacks details on response format, pagination, or ordering, which would be helpful for 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?
With 0% schema description coverage, the description names the two required parameters (project_id, work_item_id) and their roles. However, it adds no details on format or constraints beyond what the schema provides.
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 'pages linked to a work item'. It effectively distinguishes from sibling tools like 'list_pages' (all pages) and mutation tools like 'attach_page_to_work_item'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It specifies that the tool lists pages for a work item, implying use when you need pages associated with a specific work item. However, it does not explicitly state when not to use it or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true and destructiveHint=false, and the description adds little beyond confirming update behavior. No contradictions, but the description does not enrich understanding of side effects or safety 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 succinct with clear Args and Returns sections, every sentence adds value, and it is front-loaded with the main verb and resource.
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?
While the output schema exists and parameters are described, the description claims a workspace_slug parameter that is absent from the input schema, indicating a mismatch. No guidance on authentication, rate limits, or prerequisites, making it incomplete for a mutation tool with boolean toggles.
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 0%, but the description explains each parameter with a brief purpose (e.g., 'modules: Enable/disable modules feature'), adding meaning that the schema (types only) does not provide. However, workspace_slug is listed in the description but missing from the input schema, causing confusion.
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 'Update features of a project' and lists specific feature toggles (modules, cycles, etc.), distinguishing it from sibling tools like update_project (project metadata) and update_workspace_features (workspace-level).
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 enabling/disabling project features but does not explicitly state when to use vs alternatives, nor provides prerequisites or exclusions. It is adequate but lacks explicit 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?
Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds only that it 'updates features', which is consistent but does not provide additional behavioral context such as scope of changes (e.g., affects all projects) or potential side effects. With annotations covering the safety profile, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a one-line summary, a list of parameters with explanations, and a return type statement. Every sentence serves a purpose and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is an output schema and all parameters are optional, the description adequately explains the tool's purpose and parameters. However, it lacks usage context or guidance on when to use this tool versus siblings, which is a gap for completeness. Still, the tool is simple and the main details are covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description carries the full burden. Each parameter is explained with 'Enable/disable [feature] feature', which adds clear meaning beyond the raw boolean/null type. However, it lacks details like default behavior or interaction between parameters, which could be useful. This is a solid addition but not exhaustive.
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 'Update features of the current workspace', specifying the verb and resource. It distinguishes from sibling tools like 'update_project_features' by explicitly mentioning workspace. The argument list further clarifies the exact features affected.
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 'update_project_features' or other feature-related tools. There is no mention of prerequisites, typical use cases, or exclusions, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details the mutation: setting end_date to today. Annotations already indicate readOnlyHint=false and openWorldHint=true. No additional behavioral traits (e.g., permissions, side effects) are disclosed beyond the core action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a main sentence, explanatory context, then Args and Returns. It is concise but includes valuable explanation, which prevents a higher score for brevity.
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 tool with annotations and implied output schema, the description covers purpose, why it exists, and parameter roles. It lacks details on error conditions or prerequisites (e.g., if cycle already closed), but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds basic parameter descriptions ('UUID of the project', 'UUID of the cycle to complete'), providing minimal meaning beyond the type. More detail (e.g., format, constraints) would improve the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool's purpose: 'Complete (close) a cycle by setting its end date to today.' It also explains the context that Plane lacks an explicit 'complete' action, distinguishing it from sibling tools like update_cycle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the use case for closing a cycle and the reason for this tool's existence. It implicitly differentiates from update_cycle but does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, idempotentHint=false, destructiveHint=false. The description adds the return value ('Created WorkItemPropertyOption object') but does not disclose side effects beyond creation, such as whether the property must exist or what happens if an option with the same name already exists. The behavioral disclosure is adequate but minimal given annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a well-structured docstring with Args and Returns sections. Every sentence adds information about parameters or return value. It is not overly verbose but could be slightly more concise by omitting redundant parameter names. Overall, it is efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple. With an output schema present, the description does not need to detail return fields. It covers all parameters and the return object. However, it lacks information on prerequisites (e.g., does the property need to be of option type?) or error scenarios. For a create operation, this is almost complete but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides brief but meaningful descriptions for all 8 parameters (e.g., 'UUID of the work item property', 'Hex color string e.g. "#FF5733"'). While not extensive, this adds essential meaning beyond the raw schema, effectively covering 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 clearly states the action ('Create an option on a work item property') and the resource. It distinguishes itself from sibling tools like 'create_work_item_property' (creates the property itself) and 'update_work_item_property_option' (updates an existing option), showing specific verb-resource pairing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. The description lists required parameters (property_id and name) but does not contrast with alternatives like updating or deleting options. The purpose is clear from the name but fails to provide explicit 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 indicate destructive and idempotent behavior. The description adds specific error context when the feature is disabled, which is helpful 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, parameter, and error case. All sentences add value, though parameter info could be integrated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, parameter, and a key error case. Lacks success return behavior, but given no output schema, it is reasonably complete for a simple delete 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?
Schema has 0% description coverage, but the description clarifies that 'initiative_id' is a UUID, adding meaning beyond the schema's bare type definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Delete an initiative by ID' with a clear verb and resource. It distinguishes from sibling tools like retrieve_initiative or update_initiative.
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 on when to use this tool versus alternatives; no mention of prerequisites or 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 indicate destructiveHint=true and readOnlyHint=false, so the destructive nature is clear. The description adds the step to get attachment_id but does not disclose additional behavioral traits like irreversibility or permission needs.
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, front-loaded with the purpose, and includes only essential information. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion tool with annotations, the description covers the action and ID retrieval. However, it lacks information about return value, success/error handling, and any side effects, making it somewhat incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds basic type info ('UUID') for each parameter, which is helpful but minimal. Could include more detail on value constraints or sources.
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 an attachment') and the resource ('from a work item'). It is specific and distinguishes itself from sibling attachment tools like list, upload, download.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using list_work_item_attachments to get the attachment_id, which is a helpful prerequisite. Does not explicitly mention when not to use, but 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not add behavioral context beyond what the annotations (readOnlyHint=true, openWorldHint=true) already provide. It does not mention any side effects, authorization requirements, rate limits, or output specifics. Since annotations cover the safety profile, a score of 3 is appropriate.
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 and well-structured. It uses a clear header for the action, followed by a minimal Args list and a Returns line. Every sentence serves a purpose with no 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?
While the description adequately explains parameters and return type, it lacks context about the nature of 'work item property' (e.g., property definition vs. property value). Given siblings like get_work_item_property_value, this omission could lead to incorrect tool selection. The presence of an output schema mitigates some completeness concerns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining each parameter: work_item_property_id as UUID, project_id with scope guidance, work_item_type_id with endpoint guidance. This adds valuable semantics beyond the raw 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 'Retrieve a work item property by ID.' It specifies the resource (work item property) and the method (retrieve by ID), making it distinct from siblings like list_work_item_properties or create_work_item_property.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage guidance by indicating when to omit optional parameters (e.g., 'Omit for workspace scope', 'omit to use project-level endpoint'). However, it fails to explicitly mention when to prefer this tool over alternatives such as list_work_item_properties or get_work_item_property_value, which is a notable gap.
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 minimal value beyond annotations. Annotations already declare readOnlyHint: true and openWorldHint: true, so no need to state that. The description notes 'Omit for workspace scope' for project_id, which adds context, but does not disclose other traits like permission requirements or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured. It uses a clear docstring format with a purpose sentence, Args section, and Returns section. Every sentence is necessary and 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?
Given the tool's low complexity, output schema exists (so no need to detail return), and annotations cover safety, the description is complete. It explains both parameters, including the optionality of project_id, and the return type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining both parameters: work_item_type_id is a UUID, project_id is a UUID with the note 'Omit for workspace scope'. This adds meaning beyond the schema, though no format or constraints are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieve' and the resource 'work item type' with the method 'by ID'. It is specific and distinguishes from sibling tools like list_work_item_types (which lists all) and resolve_work_item_type (which likely resolves by name or other criteria).
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, when to omit project_id, or when to use list_work_item_types instead. The only usage hint is implicit from the parameter description.
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. The description adds that it returns an Updated EstimatePoint object, which is expected. No additional behavioral traits (e.g., permissions, error states) are disclosed 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured as a bullet list, starting with a concise one-line purpose. It is efficient and avoids redundancy, though it could be slightly more compact by omitting the 'Args:' and 'Returns:' labels.
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 8 parameters, 3 required, and the presence of an output schema, the description covers the essential input semantics. However, it lacks guidance on error conditions, prerequisites, or when to use optional parameters, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description lists all 8 parameters and adds meaningful context (e.g., value max 20 chars, key is integer). It does not explain optionality or inter-parameter relationships, but provides enough for basic understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update a single estimate point,' which is a specific verb-resource combination. It distinguishes this tool from siblings like create_project_estimate_points, delete_project_estimate_point, and list_project_estimate_points by focusing on the update operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives (e.g., when to update vs. create an estimate point). Usage is implied by the verb 'update,' but no when-not-to-use or contextual cues 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 indicate readOnlyHint=false, so the mutation behavior is clear. The description adds that this is a create operation, which is consistent. It does not elaborate on potential side effects, such as whether definitions can be modified or deleted later, or any restrictions on uniqueness. The description adds minimal 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 concise and well-structured: a one-line summary, a brief explanation of the resource, an 'Args' list with clear labels, and a 'Returns' line. Every sentence is informative and there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (5 parameters, output schema exists), the description adequately covers the purpose, parameters, and return type. It could mention uniqueness constraints for the 'name' parameter, but overall it is sufficient for the agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by listing all parameters in the 'Args' section and explaining each: name (unique name), outward/inward (labels from source/target perspective), is_active (availability for use), color (hex code for UI). This adds meaning beyond the property names and types in the schema. However, it does not specify format constraints (e.g., max length for name).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'workspace relation definition'. It explains that a relation definition describes a named relationship type, distinguishing it from creating an actual relation instance (a sibling tool). The purpose 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to create a relation definition) but does not explicitly state when not to use it or provide alternatives. It lacks guidance on prerequisites or context, relying on the tool name and sibling context. The agent would need to infer usage from the description of what a relation definition is.
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 destructiveHint=true and readOnlyHint=false. Description adds scoping nuance but no new behavioral traits beyond what annotations convey. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise (one sentence plus Args list) and front-loaded. Could remove 'Args:' label, but overall efficient with no unnecessary words.
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?
Basic usage is clear, but lacks details on return values, error handling, or behavior when property doesn't exist. Without output schema, agent may need to infer. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but description enriches parameter meaning: 'UUID of the property', 'Omit for workspace scope', and 'omit to use project-level endpoint'. This compensates for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The statement 'Delete a work item property by ID' clearly specifies the action (delete) and the resource (work item property). It distinguishes from sibling tools like delete_work_item_property_value and delete_work_item_relation_definition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on when to omit optional parameters: 'Omit for workspace scope' for project_id and 'omit to use project-level endpoint' for work_item_type_id. However, no explicit when-not-to-use or alternatives compared to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotations (readOnlyHint, openWorldHint). It does not mention authentication requirements, side effects, or any dynamic behavior, leaving the agent to infer from the tool name and 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 exceptionally concise—two sentences that convey the purpose and return type without unnecessary words. 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.
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 (no parameters, annotations present, output schema exists), the description is adequately complete. It does not explain the UserLite object, but the output schema covers that, so no further detail is needed.
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 no parameters, so the input schema fully covers parameter semantics. The description provides no additional parameter details, but with zero parameters, the baseline of 4 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 it retrieves information about the current user. It uses a specific verb ('Get') and resource ('current user information'), and it is distinct from sibling tools that operate on projects, work items, or other entities.
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 tool is self-explanatory for retrieving current user info; no alternatives exist among siblings. While no explicit when-to-use or when-not-to-use guidance is provided, the context is straightforward, making it clear when this tool is appropriate.
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. The description adds no additional behavioral traits beyond parameter descriptions, so minimal extra 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?
One sentence for purpose followed by concise parameter and return descriptions. No wasted words, well 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?
Covers inputs and basic purpose. With output schema present, return description is adequate. Could mention pagination behavior explicitly, but overall 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?
Schema description coverage is 0%, but the description explains initiative_id as 'UUID of the initiative' and params with examples (per_page, cursor). This adds meaningful context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List projects linked to an initiative' with a specific verb and resource. It distinguishes from siblings like list_initiatives (lists initiatives) and manage_initiative_projects (likely manages linking).
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 to list projects for an initiative but does not explicitly state when to use vs alternatives, nor mention 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 indicate this is a mutation (readOnlyHint=false). The description adds the state constraint and visibility effect, but does not detail other behavioral aspects like permissions or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (2 sentences plus bullet list), front-loaded with purpose, and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation with 3 required params and no output schema, the description covers the action, preconditions, and param meanings. It could optionally mention return values or error conditions, but is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully explains all three parameters: project_id and work_item_id as UUIDs, and archive as a boolean with clear meaning. This adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool archives or unarchives a work item, using specific verbs and resource. It is distinct from sibling tools like manage_cycle_archive or manage_module_archive.
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 prerequisite (only completed/cancelled states) and a behavioral consequence (archived items no longer appear in active lists). However, it does not explicitly state when to use this tool vs alternatives or 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?
The description states that it returns a 'State object', but the exact structure is likely defined in the output schema. The annotations already indicate readOnlyHint and openWorldHint, so the description adds minimal behavioral 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 remarkably concise, consisting of a single line of purpose and a brief parameter list. Every element is necessary and front-loaded; there is no superfluous content.
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 presence of an output schema, the description appropriately does not elaborate on return values. It sufficiently covers the two required parameters. For a simple retrieval tool with low parameter count, the description is complete enough, though it could mention that the state must exist or handle errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description explicitly adds semantics by noting that 'project_id' is a 'UUID of the project' and 'state_id' is a 'UUID of the state', providing essential context beyond the schema's type definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieve'), the resource ('state'), and the identifying parameters ('by ID'). It distinguishes from siblings like 'list_states' and 'create_state' by specifying retrieval of a single state via IDs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. It implies usage for fetching a specific state, but lacks comparison with 'list_states' or 'retrieve_state_by_identifier' (not present, but siblings include other retrieve tools). This is adequate but not exemplary.
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=true and openWorldHint=true. The description adds minimal extra behavior (return type) but does not disclose permissions, existence constraints, or error conditions beyond what annotations suggest.
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 bullet list of parameters and return type, front-loaded and without any superfluous content.
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 (retrieve by ID) and the existence of an output schema, the description adequately covers the needed information. Minor lack of error context is offset by the straightforward nature of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining each parameter as UUIDs and their role (project, work item, link). This adds meaningful semantic context beyond parameter names and types.
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 'Retrieve' and the resource 'specific link for a work item', distinguishing it from sibling tools like list_work_item_links (list all) and CRUD operations.
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 lists required parameters but does not explicitly state when to use this tool versus alternatives like list_work_item_links. Usage context is implied by parameter requirements but not clearly defined.
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, idempotentHint=true, destructiveHint=false. The description adds no extra behavioral context (e.g., side effects on label relationships, permissions needed). With annotations, the bar is lower, but additional detail like 'only updates provided fields' would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-line purpose, followed by a clear list of parameters with descriptions, ending with 'Returns: Updated Label object'. No extraneous 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?
Given 9 parameters (2 required) and an existing output schema, the description covers all parameters and indicates the return type. Could mention that only non-null fields are updated (since defaults are null), but overall complete for an update operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides brief explanations for each of the 9 parameters in the Args block. This adds meaning beyond the schema's type-only definitions, guiding the user on what each parameter represents.
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 starts with 'Update a label by ID' - a clear verb+resource combination. The tool name and description align. It distinguishes from sibling tools like create_label, delete_label, retrieve_label, list_labels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like create_label or delete_label. The context of 'update' implies it's for modifying existing labels, but no when-not-to-use or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is not read-only and not destructive, and the description adds no additional behavioral traits beyond what is implied by 'update.' The return type is mentioned but adds minimal new insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a one-liner purpose, an Args list, and a Returns line. It is efficient but slightly verbose due to the full parameter list. Still, it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and annotations, the description covers purpose, parameters, and return type. It lacks information about default behavior or when to omit project_id, but is largely complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description fully compensates by providing clear, concise descriptions for all 9 parameters (e.g., 'UUID of the work item property,' 'Hex color string'). This adds essential meaning beyond the bare 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 'Update an option on a work item property,' using a specific verb and resource. It effectively distinguishes this tool from sibling tools like create or delete for the same entity.
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 updating existing options by listing parameters, but it lacks explicit guidance on when to use this tool versus create or other alternatives. No when-not-to-use or prerequisite context is provided.
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 destructiveHint=false. The description adds no behavioral details beyond stating 'Update,' so it does not surpass 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 concise: one sentence for purpose, bullet-like parameter list, and return statement. No redundancy or unnecessary text.
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 presence of an output schema and annotations, the description is adequate. It covers purpose, parameters, and return type. Minor improvement would be noting partial updates via optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the schema has 0% description coverage, the description lists all 6 parameters with brief explanations (e.g., 'UUID of the relation definition to update'), adding meaning beyond type information. It lacks detailed constraints or examples.
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 'Update an existing workspace relation definition,' specifying a precise verb and resource. It distinguishes from sibling tools like create_work_item_relation_definition and delete_work_item_relation_definition.
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 is implied by the verb 'Update' and the tool name, but no explicit guidance is given on when to use versus alternatives, nor are any prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, indicating no side effects. The description adds no additional behavioral context beyond what annotations provide, such as rate limits or data freshness. It is consistent but does not add value 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with the main action, followed by a structured Args and Returns section. It is efficient and easy to parse, though the Args section could be more concise by integrating into the main sentence.
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 retrieval operation with readOnlyHint and an output schema (not shown), the description covers the essential information: what it retrieves, the required IDs, and the return type. No obvious gaps 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% description coverage (only types), but the description adds parameter names and a brief explanation ('UUID of the project', etc.). This compensation is helpful, and for retrieval, the parameter semantics are clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Retrieve a specific comment for a work item.', using a specific verb and resource. It distinguishes from sibling tools like list_work_item_comments (which retrieves all comments) and create/update/delete.
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 a single comment is needed by ID, but does not explicitly state when not to use it or mention alternatives like list_work_item_comments for fetching multiple comments. It provides clear context but lacks 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 indicate readOnlyHint=false, idempotentHint=true, destructiveHint=false, which are consistent with an update operation. The description adds useful detail about description_stripped being a convenience that gets wrapped into HTML and ignored if description_html is set. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear purpose, but the parameter list is verbose and could be more concise. Each parameter is listed with its type and description, which is thorough but lengthy. It could be shortened without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 20 parameters and an output schema, the description covers all inputs and notes the return type. It provides sufficient context for an agent to understand what fields can be updated and how they relate. The presence of an output schema reduces the need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides meaningful explanations for all 20 parameters, including relationships (e.g., description_stripped vs description_html), formats (ISO 8601 for dates), and allowed values (priority levels). This fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Update a work item by ID.', clearly stating the action and resource. It distinguishes from sibling tools like create_work_item, delete_work_item, etc., by focusing on update.
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 modifying an existing work item, but does not provide explicit guidance on when to use this tool versus alternatives like manage_work_item_assignee or manage_work_item_label. No exclusions or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is known. The description adds valuable behavioral context: the id field is a key for another tool. No contradictions. It doesn't disclose rate limits or auth requirements, but annotations cover the main risks.
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. First states the core purpose, second provides a critical usage note. No wasted words. Front-loaded with the main action.
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, the description covers the main purpose, parameter usage, and the significance of the output id. The presence of an output schema reduces the need to describe return format. Could mention that it returns an array, but overall complete enough.
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 0%, so the description must compensate. It explains the project_id parameter (omit for workspace-level types) but does not explain the generic 'params' parameter, which is an anyOf object. This leaves ambiguity about what additional parameters might be passed. Thus partial but not full compensation.
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 work item types and distinguishes between workspace-level and project-specific types by instructing to omit project_id. It also explains the practical use of the id field for another tool, making the purpose specific and actionable. Among siblings like create_work_item_type, this is distinct.
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 guidance on when to omit project_id (workspace-level) and how the result is used downstream (list_work_item_properties). It could be improved by explicitly stating when to use this tool vs alternatives, but the context is sufficient for most agents.
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 openWorldHint=true. The description confirms read-only behavior by stating 'List work logs' and adds the return type (list of WorkItemWorkLog objects), which is beyond what annotations provide. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured as a Google-style docstring with clear Args and Returns sections. Every sentence is necessary and earns its place, with no extraneous content.
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 list operation with read-only hints and an output schema (implied). The description covers the essential purpose and parameters. It doesn't address pagination, sorting, or permissible query parameters, but given the overall simplicity and annotation support, it is still fairly 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 description adds basic meaning for project_id ('UUID of the project') and work_item_id ('UUID of the work item'), which is not present in the schema (which only specifies type 'string'). However, the params parameter is described as 'Optional query parameters as a dictionary' with no further details, leaving ambiguity about allowed keys or formats. Schema description coverage is 0%, so the description partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List work logs for a work item.' which specifies the action (list) and the resource (work logs scoped to a work item). It effectively distinguishes from sibling tools that create, update, or delete work logs, as well as other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description names the required parameters (project_id and work_item_id) and mentions optional params, clearly indicating the context needed. It does not explicitly state when not to use this tool or name alternatives, but the sibling list (create_work_log, update_work_log, delete_work_log) provides implicit differentiation.
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 indicate a mutation (readOnlyHint=false) but the description adds valuable context: archived projects are hidden but not deleted, and all work items/cycles/modules are preserved. This goes beyond what annotations provide. Could still mention permissions or reversibility more explicitly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single-line summary, a few lines explaining behavior, then a clear Args section. Front-loaded with the verb, every sentence serves a purpose 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?
For a simple 2-parameter mutation tool with no output schema, the description covers purpose, parameters, and behavioral implications (hidden but not deleted, items preserved). It could optionally mention that archived projects can still be retrieved via retrieve_project, but not necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description's Args section compensates well, defining project_id as UUID and archive as boolean with clear semantics (True=archive, False=unarchive). This makes both parameters' purpose clear beyond their types.
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 'Archive or unarchive a project' with specific verb and resource. It distinguishes from sibling tools like delete_project or manage_work_item_archive by explaining that archived projects are hidden but not deleted and all work items/cycles/modules are preserved.
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 (to change archive status) but does not explicitly contrast with sibling tools like manage_work_item_archive, manage_cycle_archive, or manage_module_archive. No direct guidance on when to use this vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, which the description reinforces. It adds valuable context about a specific error case when the initiatives feature is disabled, including steps mentioned in the error. 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 extremely concise with clear sections for Args, Returns, and Raises. Every sentence provides meaningful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple retrieval with an output schema covering the return format. The description explains an error condition and provides enough context for an agent to use it correctly. Could optionally mention that the initiative is a work item type, but not required.
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 only defines 'initiative_id' as a string without format. The description adds that it is a 'UUID,' specifying the expected format. Since schema description coverage is 0%, this addition is important and goes 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 'Retrieve an initiative by ID,' specifying the action (retrieve) and resource (initiative). It distinguishes from siblings like 'retrieve_project' and 'list_initiatives' by focusing on a single initiative retrieval via ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have an initiative ID and need the full object, but does not explicitly state when to use this over alternatives (e.g., list_initiatives when you need to search). No when-not or alternative guidance is provided.
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. The description adds no behavioral details beyond the basic retrieval action, which is consistent with annotations. No 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, well-structured line with a clear purpose, followed by an Args/Returns section. Every sentence is informative with no 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 retrieval tool with annotations and an output schema, the description sufficiently covers the behavior and parameter usage. It explains how to use project_id (omit for workspace scope), which is important context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description provides clear semantics for each parameter: 'property_id: UUID of the work item property', 'option_id: UUID of the option', 'project_id: UUID of project. Omit for workspace scope.' This adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Retrieve a single option from a work item property', which is a specific verb and resource. It distinguishes from siblings like 'list_work_item_property_options' by focusing on a single retrieval by IDs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like listing all options. The purpose implies use for a specific option, but no direct exclusion or alternative mention.
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 mutability and safety. Description adds return type and parameter list but doesn't clarify partial update behavior or any side effects, which is typical for update operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening sentence followed by a parameter list. It's reasonably concise but slightly longer due to the parameter listing, yet every sentence is informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 11 parameters and the presence of an output schema, the description adequately covers what the tool does, what parameters mean, and what is returned. It doesn't cover error conditions or permission requirements, but these are less critical for an update tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides detailed explanations for all 11 parameters, including format hints (ISO 8601), status values, and user ID types, fully compensating for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Update a module by ID' with a full list of updatable fields, distinguishing it from sibling tools like retrieve_module (read), create_module (create), or delete_module (delete).
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?
Implicitly clear that this tool updates an existing module, but lacks explicit guidance on when to use vs alternatives or prerequisites like needing the module to exist.
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 are present (idempotentHint=true, destructiveHint=false), and the description adds context by listing updatable fields and confirming the return of an updated object, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured as a docstring with args and returns, front-loaded with the purpose. Minor redundancy (repeating 'UUID of the') but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and annotations, the description adequately covers the update operation. It could mention partial update behavior or error cases, but openness is acceptable with openWorldHint=true.
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?
With 0% schema description coverage, the description fully compensates by providing clear meanings for all 5 parameters: UUIDs for IDs, duration in minutes, and description text.
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 specifies the action ('Update') and resource ('a work log for a work item'), distinguishing it from sibling tools like 'create_work_log' and 'delete_work_log'.
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 modifying existing logs but does not explicitly state when to use this tool versus creating or deleting, nor does it mention prerequisites like the log must exist.
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 non-readOnly, non-destructive, open-world. Description adds the import behavior but does not disclose potential side effects (e.g., existing type behavior, reversibility). It adds parameter details but not deeper 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a one-line summary, then detailed explanation, then parameter list. Some redundancy (e.g., 'Bulk-link...to a project' followed by 'Imports...'), but overall clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains what the tool does and what parameters are needed. It covers the core functionality and distinguishes from siblings, though missing edge cases or error conditions.
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 0%, so burden is on description. The 'Args' section explains 'project_id: UUID of the project' and 'work_item_type_ids: List of workspace-level work item type UUIDs to import', adding meaning beyond the schema's bare types.
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 'bulk-link workspace-level work item types to a project' and explains the purpose of making them available within the project. It distinguishes from the sibling tool resolve_work_item_type, making its specific role clear.
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 advises 'For the common case of getting one named type usable in a project, prefer resolve_work_item_type', providing clear when-to-use and when-not-to-use guidance relative to an alternative.
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 tool is read-only. Description adds return structure (dependencies and custom groups), providing useful behavioral detail 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?
Three sentences, front-loaded with purpose, includes Args and Returns sections. No redundant 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 simple task and presence of output schema (as per context), the description fully covers the tool's behavior with the return keys. No gaps for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are described with their purpose ('UUID of the project', 'UUID of the work item'), adding meaning to the schema's bare type string. Schema coverage is 0%, so description compensates well.
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?
Clear verb 'List' and resource 'every relation for a work item'. Distinguishes from sibling tools like create_work_item_relation and list_work_item_relation_definitions.
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?
Implicit usage (list all relations) but no explicit when-to-use or alternatives. Could mention when to use this vs list_work_item_links or relation definitions.
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, so the description's mention of add/remove is consistent. The description adds value by stating that both operations can be performed in a single call, which is a behavioral detail not captured by annotations. No 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 extremely concise: one line for purpose, a condition line, and a parameter list. Every sentence provides essential information, and the structure 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?
The description provides necessary purpose and parameter semantics, but lacks information about return values (no output schema) and edge cases (e.g., what happens if both arrays are empty). For a simple add/remove tool, it is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description includes an Args section explaining each parameter's purpose and the requirement that at least one of add_ids or remove_ids be provided. This compensates for the lack of schema descriptions, though it could be slightly more specific about UUID format.
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 'add or remove' and the resource 'work items on a cycle'. It distinguishes from siblings like list_cycle_work_items and transfer_cycle_work_items by focusing on single-call add/remove operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly requires that at least one of add_ids or remove_ids be provided, giving a clear usage condition. However, it does not elaborate on when to prefer this over siblings like transfer_cycle_work_items or manual calls to separate add/remove endpoints.
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 indicate readOnlyHint=false (modifies data) and openWorldHint=true. The description adds context that the operation is a single call and requires at least one ID array. It lacks details on idempotency or error behavior, but with annotations, 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 two sentences plus a bullet list, very concise. Every sentence adds unique value: the first states the main action, the second gives a constraint, and the list explains parameters. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, no output schema, and moderate annotations. The description covers the core functionality and parameter requirements. It could mention what happens if a work item is already present, but overall it is complete enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description provides a full docstring-style explanation for each parameter (project_id, module_id, add_ids, remove_ids) with types and purposes, adding significant meaning beyond the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it adds or removes work items on a module in a single call. It uses specific verbs ('add', 'remove') and resource ('work items on a module'), and distinguishes from sibling tools like list_module_work_items (list-only) and manage_module_archive (archive).
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 notes that at least one of add_ids or remove_ids must be provided, giving a clear usage constraint. However, it does not contrast with alternatives like other module tools or specify when to use add versus remove.
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 write (readOnlyHint=false) and non-destructive (destructiveHint=false). Description adds behavioral details about page location and lists all parameters, adding 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a clear first line and a bullet-like parameter list. Slightly verbose but each sentence adds value; could be tightened without losing clarity.
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 11 parameters and an output schema mentioned, the description covers the main behavior and parameter purposes. Does not detail return format, but output schema is present. Adequate 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides essential meaning for all 11 parameters (e.g., 'Project name', 'Page content in HTML format', 'UUID of the project. Omit to create a workspace page.'), making it highly informative beyond the bare 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?
Description clearly identifies the action ('Create a page') and distinguishes between creating a project page or workspace-level page based on project_id. This differentiates from sibling tools like update_page or delete_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: include project_id for a project page, omit for workspace page. Does not explicitly state when not to use or list alternatives, but the guidance is sufficient for an agent to decide.
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 indicate readOnlyHint=false and destructiveHint=false, so the tool creates something. The description adds behavioral context beyond annotations: it explains scope resolution, parameter dependencies (e.g., relation_type required for RELATION), and return type ('Returns Created WorkItemProperty object'). No contradictions with annotations. It does not mention side effects like idempotency (idempotentHint=false), but that 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a one-line summary, scope resolution in bullet-like format, and a parameter list. It is fairly long but every sentence adds value given the complexity (15 parameters, scope resolution). It is front-loaded with the main purpose. Could be slightly more concise, but it is efficient for the information density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (15 parameters, scope variations, multiple property types), the description covers essential aspects: scope resolution, parameter dependencies, required combinations, and return type. An output schema exists, so return values need not be detailed further. It is complete enough for correct agent usage, though error conditions or rate limits are not mentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description carries full burden. It provides detailed explanations for all 15 parameters, including type options (e.g., property_type enum values), structure (e.g., settings JSON format, options list of dicts), and usage constraints (e.g., relation_type required when property_type=RELATION). This adds significant meaning beyond the bare 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 starts with a clear verb and resource: 'Create a new work item property.' It explicitly distinguishes from sibling tools like update, delete, list, retrieve by focusing on creation. The scope resolution section further clarifies the purpose by detailing how the property is scoped (type-scoped, project-level, workspace-level), which differentiates it from others.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use which parameters (e.g., omit work_item_type_id for project-level, relation_type required for RELATION type). It also explains required conditions for parameters like settings for TEXT/DATETIME. However, it does not explicitly state when to use this tool versus alternatives, but the sibling context and clear scope resolution serve as implicit 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?
Annotations already indicate non-read-only, non-idempotent, non-destructive. The description adds that creation may cause duplicates (implied by recommending 'resolve_work_item_type'), but does not elaborate on other behavioral traits like permissions or side effects. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise single sentence for purpose, followed by a clear 'Args' section listing parameters. No fluff; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters and an output schema present, the description covers essential guidance (usage alternative, parameter meanings). It does not explain return values, but the output schema likely handles that. Missing some behavioral nuances, but overall sufficient for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description lists all parameters with brief explanations (e.g., 'project_id: UUID of the project. Omit for workspace-level type.'). This adds meaning beyond the schema's type-only definitions, compensating for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Create a new work item type.' It also distinguishes from the sibling tool 'resolve_work_item_type' by advising when to use the alternative, making the purpose explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: recommends 'resolve_work_item_type' over this tool for project-scoped types to avoid duplicates. This tells the agent when not to use this tool and suggests a better alternative.
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, indicating a safe read. The description adds context about the return structure (built_in_dependencies and custom_definitions) and the parameter filters. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections and parameter explanations. It is slightly lengthy but front-loads the primary purpose. Could be slightly more concise without losing clarity.
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 annotations and the presence of an output schema (not shown but referenced), the description covers purpose, parameters, and return structure. It lacks mention of pagination or error handling, but overall sufficient for a listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% description coverage, but the description fully explains both parameters: is_default and is_active, including their purpose (filtering custom definitions). This compensates entirely for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it lists every relation type usable with create_work_item_relation, and distinguishes between built_in_dependencies and custom_definitions. It also advises the user to match wording before creating a relation, differentiating from related tools like list_work_item_relations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when to use this tool (before creating a relation) and explains the two categories and their management tools (create/update/delete_work_item_relation_definition). However, it does not explicitly contrast with sibling tools like list_work_item_relations, which list actual links.
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?
Beyond annotations (readOnlyHint=false), the description discloses the automatic end_date setting behavior and that the operation returns True on success. It does not mention potential failure modes or side effects like unarchive reversing end_date changes.
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 (6 sentences), front-loaded with the purpose, followed by preconditions, args, and return. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core behavior, parameters, and return. Minor gaps: unarchive behavior is not elaborated (e.g., does it restore end_date?), and no differentiation from complete_cycle. Still adequate for a simple 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?
With 0% schema coverage, the description provides parameter explanations (project_id UUID, cycle_id UUID, archive boolean meaning) that add meaning beyond the bare schema, though not all edge cases are covered.
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 'Archive or unarchive a cycle', specifying the verb and resource. It distinguishes from sibling tools like list_cycles, create_cycle, etc., by focusing on archive state management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains a precondition (end_date must be past before archiving) and auto-behavior (sets end_date to today if archive=True). However, it does not explicitly differentiate from the sibling complete_cycle tool or specify when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the tool's safety is established. The description adds that it returns a 'Milestone object', which is useful behavioral context beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for purpose, followed by structured Args and Returns sections. Every word adds value, and the purpose 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 retrieval tool with 2 parameters and an output schema, the description covers purpose, parameter meanings, and return type. Nothing is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by specifying each parameter as 'UUID of the project' and 'UUID of the milestone', adding format and purpose beyond the schema's bare string type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Retrieve a milestone by ID', using a specific verb and resource. It distinguishes from siblings like 'list_milestones' and 'create_milestone' by focusing on retrieval with a unique identifier.
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 you have a specific milestone ID, but it does not explicitly contrast with alternatives (e.g., 'list_milestones') or state when not to use this tool. No exclusions or prerequisites 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 indicate readOnlyHint=false (write operation) and destructiveHint=false. The description adds valuable context: the server downloads the file server-side and uploads via a presigned S3 flow. It also notes the URL must be public and not internal. This goes beyond what annotations provide, though it could mention that the operation is not idempotent (consistent with the hint).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a brief intro, a process explanation, then parameter details, and return info. It is concise but includes necessary details. The docstring format is slightly verbose for an MCP tool but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (file upload from URL via S3 flow), the description is fairly complete. It explains the process, parameter details, and return value. The output schema exists, so return values are further documented. Potential missing details like error handling or size limits are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for parameters. The description compensates fully by documenting each parameter in the 'Args' section: project_id and work_item_id as UUIDs, url with examples (GitHub raw, public S3), and name as an optional override with a default. This adds critical meaning beyond the bare 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 specific action: fetching a file from a public URL and attaching it to a work item. It includes the verb 'fetch' and 'attach', and identifies the resource as a work item attachment. This distinguishes it from sibling tools like read_work_item_attachment or delete_work_item_attachment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (when you want to attach a file from a public URL) and includes important constraints: the URL must be publicly accessible and not resolve to a private/internal network. It also gives examples of acceptable URLs. While it does not explicitly state when not to use it or mention alternatives, the context of sibling tools provides implicit differentiation.
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 declare readOnlyHint=true and openWorldHint=true; description confirms read-only nature and adds behavioral details about return structure (grouped_counts, sub_grouped_counts). The description adds value 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?
Well-structured with front-loaded purpose, followed by usage guideline, parameter details, and return format. Every sentence adds value; no unnecessary 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?
Given the complexity of grouping and nested grouping, the description fully explains all parameters and output structure (with output schema details). It is complete for an agent to effectively use the 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?
Schema only describes pql (33% coverage), but description lists supported values for group_by and sub_group_by, and explains pql usage with examples. This compensates for schema gaps, adding significant meaning.
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 counts work items with optional grouping, and distinguishes it from fetching full payloads. It specifies the use case for analytics, 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?
Explicitly says to use for analytics without fetching full payloads, providing a clear when-to-use guidance. It contrasts with list_work_items, but lacks explicit when-not-to-use scenarios or alternatives like search_work_items.
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. The description adds value by detailing the return object (id, name, type) and mentioning the requirement for calling another tool. No contradictions; it supplements the annotations well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three short paragraphs: purpose, Args, Returns. No redundant information, and the structure is clear 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?
Given the tool has few parameters and an output schema, the description is complete. It explains the return fields and connects to another tool, fully covering what an agent needs to 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?
The schema only defines project_id as a string, but the description adds 'UUID of the project', providing type context beyond the schema. With schema description coverage at 0%, this extra detail is helpful for correct parameter usage.
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 estimate configuration for a project.' It specifies the return value (active estimate system with ID) and links to a related tool (list_project_estimate_points), distinguishing it from siblings like create/update/delete estimate 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: use this tool to retrieve estimate configuration, and the returned ID is required for list_project_estimate_points. It doesn't explicitly state when not to use, but the read-only nature and sibling list imply it's not for modification, making it adequately 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 declare readOnlyHint=true (safe read) and openWorldHint=true (possible unknown properties). The description adds value by specifying the return format (single vs list based on property type) and requiring three UUIDs, but does not mention permissions or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a short purpose statement, a helpful tip, and cleanly separated Args and Returns sections. Every sentence serves a purpose, and the key 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?
Given the low complexity (3 required parameters, simple read operation) and the presence of an output schema, the description provides sufficient context: it explains the input, the return type variation, and references a companion tool. No gaps are evident.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by listing each parameter with a brief explanation (e.g., 'UUID of the project'), adding meaning beyond the schema's simple string type. It does not provide constraints or examples, but is adequate for a 3-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the value(s) of a custom property on a work item, with a specific verb and resource. It distinguishes from sibling tools like list_work_item_properties (to find property IDs) and set_work_item_property_value (write operation).
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 directs users to use list_work_item_properties to find the property_id, providing clear context on the prerequisites. It also explains the return type varies by property type, but does not explicitly exclude alternative tools or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, and the description adds value by detailing filter behavior, pagination, and return structure, which goes 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 concise, well-structured with Args and Returns sections, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and the detailed explanation of return values (paginated envelope with member fields), the description is complete and informative.
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?
Despite 0% schema coverage, the description explains the purpose and behavior of key parameters (cursor, per_page, order_by) and filter fields with case-insensitivity and exact match details, adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists workspace members with filtering and pagination, distinguishing it from sibling tools like get_project_members.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on how to use filters, pagination, and sorting, but does not explicitly state when not to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds value by specifying pagination details (next_cursor, prev_cursor), default sorting (by archived_at), and that results are returned in a paginated envelope. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured as a docstring with Args and Returns sections. It is clear and informative, though the PQL example is somewhat lengthy. It front-loads the purpose effectively.
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?
With an output schema present, the description still details the return structure (paginated envelope with total_count, next_cursor, prev_cursor). It covers all parameters and provides enough context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite low schema description coverage (14%), the description provides defaults and meanings for all 7 parameters (project_id, pql, order_by, per_page, cursor, expand, fields). It includes PQL examples and explains sorting syntax, adding significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List archived work items in a project with optional PQL filtering.' It uses a specific verb (list) and resource (archived work items), distinguishing it from siblings like 'list_work_items' (non-archived) and 'search_work_items'.
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 default behaviors and parameter guidance (e.g., 'Omit to list all archived items') but does not explicitly state when to use this tool versus alternatives like 'list_work_items' or 'search_work_items'. The context of archived vs. active is implied.
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?
Annotations already declare readOnlyHint and openWorldHint. Description adds that description_html is null by design and directs to retrieve_page for content, providing useful behavioral context 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with a clear first sentence, followed by explanations and examples. It is efficient but not overly terse.
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 presence of an output schema and the tool's simplicity, the description adequately covers the behavior (metadata only, no content) and parameter usage. It could mention pagination details but is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description explains both parameters: project_id (UUID, omit for workspace) and params (dictionary for pagination/cursor). This adds significant value, though params could be more detailed.
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 lists pages, distinguishes between project-level and workspace-level pages, and differentiates from retrieve_page for content retrieval. The verb 'list' and resource 'pages' are precise.
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?
Description provides clear context: use for listing metadata, omit project_id for workspace pages, and fetch content with retrieve_page. It implicitly guides when not to use (for content), though it could mention search_pages for filtering.
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. The description adds details on pagination (cursor, per_page) and a crucial behavioral note about slug uniqueness, which goes 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 brief yet comprehensive, structured with clear sections for Args and Returns, and front-loads the main purpose. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description covers return values. It explains pagination and a key behavioral note. For a straightforward list tool, it is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explains namespace values, cursor usage ('Prior response's next_cursor'), and a default for per_page. This compensates well for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists role definitions and explains the namespace parameter's effect on which roles are returned. It distinguishes itself from the sibling 'retrieve_role' implicitly by being a list operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context on when to use the namespace parameter (workspace vs project vs both). Does not explicitly state when not to use or compare to alternatives, but the usage 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 declare readOnlyHint=true and openWorldHint=true, so the description's additional details about returning active and available toolsets add useful behavioral context without contradicting annotations. It does not mention any destructive or side effects, which is appropriate given the read-only hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a brief one-line purpose, a paragraph with contextual usage, and a clear 'Returns:' section. Every sentence adds value, with no redundant or vague phrasing.
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 zero parameters, annotations covering safety, and an implied output schema, the description is fully complete. It explains the purpose, selection mechanism, and return format, leaving no gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema description coverage, so baseline is 4 per guidelines. The description does not need to add parameter info, and it correctly omits such, focusing instead on the return structure and env var context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists tool groups (toolsets) that the server knows and which are active. It uses a specific verb 'List' and a resource 'tool groups (toolsets)', and distinguishes itself from sibling CRUD tools by being a meta-level discovery tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how toolsets are selected via the PLANE_TOOLSETS env var and provides context for clients to reduce context window usage. While it does not explicitly mention when to use vs. alternatives, the tool is unique among siblings, so the guidance is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds that it returns metadata, not file content, and suggests the download tool. This complements the annotations 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 concise with 4 sentences, front-loading the purpose and return info. Every sentence adds value, and the structure is clear with separate sections for description, args, and returns.
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 simple tool and existence of an output schema and annotations, the description covers the main behavior and parameters. It could mention pagination or empty results, but overall it's complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description carries full burden. It explains both parameters as UUIDs for project and work item, adding context that the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all attachments for a work item' with a specific verb and resource. It also distinguishes from sibling 'get_work_item_attachment_download_url' by noting its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly directs users to 'get_work_item_attachment_download_url' for a downloadable link, providing an alternative. However, it doesn't explicitly state when NOT to use this tool or mention limitations.
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 it modifies the initiative-project relationship (consistent with readOnlyHint=false) and describes the return value. The openWorldHint=true annotation suggests potential side effects, which the description does not contradict.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a one-sentence purpose followed by clear Args and Returns sections. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential information: purpose, parameters, and return value. It does not explain edge cases (e.g., missing initiative) but is adequate for a mutation tool given the annotations and schema presence.
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?
With 0% schema description coverage, the description fully compensates by explaining each parameter: initiative_id is a UUID, action specifies 'add' or 'remove', and project_ids are UUIDs of projects. This adds crucial meaning beyond the schema's type and enum definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (link/unlink) and the resource (initiative projects), and distinguishes from the read-only sibling tool list_initiative_projects.
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 mentions the alternative for reading (list_initiative_projects), providing context for when to use this tool. However, it could further clarify when not to use it or other alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and open-world behavior. The description adds context by listing valid `fields` values, explaining the `expand` parameter, and noting that the return type is a WorkItemDetail object with expanded relationships. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a concise summary followed by formatting notes, then a bulleted list of valid field values, then parameter descriptions, and finally return type. While a bit lengthy, the organization makes it easy to scan.
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 presence of an output schema (not shown but signaled), the description adequately covers the return type. All six parameters are described, including the required one. The description is complete enough for an AI agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the input schema has zero description coverage (0%), the description compensates well by explaining the format for `work_item_identifier`, enumerating valid `fields` values, and briefly describing the other parameters. Some parameters like `external_id` and `external_source` receive only basic descriptions, but overall adds substantial meaning.
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 specifies retrieving a work item by its full identifier in PROJECT-N format. It clearly differentiates from the sibling tool `retrieve_work_item` by emphasizing the identifier format and providing an alternative for extracting project UUIDs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool and when not to: it explains that for obtaining a project UUID from a short identifier, `list_projects()` should be used instead. It also details the required format and valid field values.
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. The description adds conditional behavior (returns different types based on project_id), which is useful beyond annotations. No additional behavioral traits like auth or rate limits are needed for such a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with three sentences plus Arg/Returns. The first sentence immediately states the action. No wasted words, and the structure is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter) and the presence of an output schema, the description provides sufficient information. It specifies return types and conditions, making it complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explains the parameter: 'UUID of the project. Omit for workspace features.' This adds meaning beyond the schema, making it very clear.
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 feature flags' and distinguishes between project-level and workspace-level based on the presence of project_id. This differentiates it from sibling tools like update_project_features and update_workspace_features.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the parameter (with project_id for project features, without for workspace features). It does not explicitly mention when not to use, but the context of sibling tools provides alternative update 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 openWorldHint=true, covering safety and variability. The description adds specific return fields (base_url, edition, version, compat_reference, unavailable_features) and the behavioral benefit of avoiding 404 errors, enriching transparency 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and well-structured: purpose sentence, usage guideline, and return format. It is front-loaded with the core action. Could be slightly trimmed in the return dict list, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, has output schema), the description fully covers what the tool does, why to use it, and what it returns. It is self-contained and leaves no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are 0 parameters, so baseline is 4. The description adds no parameter info because none exist, but it is not expected to. It correctly focuses on the tool's output and purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get edition/version info and known API limitations of the connected Plane instance.' It uses a specific verb ('Get') and resource ('edition/version info and known API limitations'), distinguishing it from siblings that operate on projects, work items, etc.
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?
It explicitly advises to 'Use this to understand up-front which tool families are unavailable... instead of discovering them through 404 errors.' This provides a clear when-to-use and a rationale for using before other tools, with no ambiguity.
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?
The description fully discloses behavior: default active cycles, pagination mechanics, status filter details, and return envelope structure. This adds significant value beyond annotations (readOnlyHint, openWorldHint) and does not contradict them.
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 structured with a clear purpose sentence followed by a bullet-like parameter list. It is slightly verbose but well-organized and front-loads key 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?
Given the 6 parameters and the presence of an output schema, the description covers purpose, parameters, pagination, and return envelope. It does not cover error handling or rate limits, but the annotations and sibling context provide adequate completeness.
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?
With 0% schema description coverage, the description provides detailed explanations for all 6 parameters, including defaults, accepted values for status, cursor format, and ordering syntax. This significantly compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'cycles in a project', with a default scope of active cycles. This differentiates it from siblings like 'list_work_items' or 'list_projects'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the default behavior and parameter options for filtering (archived, status), which guides when to use non-default options. However, it does not explicitly state when not to use this tool or recommend alternatives among siblings.
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 openWorldHint=true. The description adds behavioral context: returns paginated envelope with results, total_count, next_cursor, prev_cursor. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Structured with Args and Returns, each parameter explained in one line. No fluff, every sentence adds value. Appropriate length for 8 parameters.
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 output schema exists, return values are explained via 'Returns' section. Covers all parameters, pagination, filtering, and dependencies like project_id and cycle_id. Fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 13%, but the description explains all 8 parameters in detail, including PQL examples and pagination semantics, adding significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List work items in a cycle with optional PQL filtering', specifying the verb (list), resource (work items in a cycle), and distinguishing from siblings like list_work_items which may not be cycle-specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on optional parameters like pql, order_by, pagination, and hints at using get_pql_reference for complex queries. Does not explicitly exclude alternatives, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint. Description adds behavioral details: pagination mechanism (cursor, per_page), ordering, and the difference between active and archived modules. 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?
Concise, well-structured with separate Args and Returns sections. Every sentence adds value, no fluff. Front-loaded with the core 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?
Covers all parameters and return format (paginated envelope with results, total_count, next_cursor, next_page_results). Output schema exists but description summarizes it adequately. With annotations, no gaps.
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?
Input schema has 0% description coverage, so the description fully compensates by providing clear semantics for all 5 parameters: project_id, archived, cursor, per_page, order_by. Each parameter is explained with type and usage notes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'List modules in a project' – specific verb and resource. Distinguishes from sibling list tools (e.g., list_work_items, list_cycles) by focusing on modules. The description also clarifies default behavior (active modules) and the use of the archived parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: used to list modules in a project, with options like archived filter and pagination. Does not explicitly state when not to use or compare to alternatives, but the purpose is unambiguous and the parameter descriptions guide correct invocation.
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?
Annotations already provide readOnlyHint and openWorldHint. The description adds substantial behavioral context: scope resolution fallback logic, efficiency advice, result structure (including fields like id, display_name, property_type, options), and a PQL workflow. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for scope resolution, result fields, and PQL workflow. It is verbose but each section adds value. Front-loaded with purpose. Slightly long but effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple parameter combinations, return structure, and PQL integration), the description covers scope rules, result fields, and a workflow example. Output schema exists, so return values are not required, but description still lists fields. Highly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains the effect of project_id and work_item_type_id combinations on scope. The 'params' parameter is not explained (it's a generic catch-all), but the overall parameter usage is well-covered. A minor gap but still strong.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'List custom work item properties,' a specific verb and resource. It then details scope resolution rules for different argument combinations, clearly distinguishing the behavior from sibling property-related tools like list_work_item_property_options and retrieve_work_item_property.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: prefer no args for workspace-wide fetch, and outlines a clear PQL workflow. It explains when to use each argument combination but does not explicitly state when not to use the tool or list alternatives, though the context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it explains that detach only removes association, not the property itself, and that the call is single. While annotations indicate openWorldHint, the description does not cover potential side effects or error conditions, but it aligns with the readOnlyHint being false.
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, starting with the core purpose, then key conditions, then a clarifying note about detach behavior, followed by an args section. Every sentence adds value, and the structure is logical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema, the description covers input requirements, parameter semantics, and return value. It does not miss critical information needed for an AI agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining each parameter: project_id, work_item_type_id, attach_ids (Property UUIDs), detach_ids (Property UUIDs). It also adds the constraint that at least one of attach_ids or detach_ids must be provided, which is not 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 tool attaches or detaches properties on a work item type in a single call. The verb 'attach/detach' and resource 'properties on work item type' are specific and distinguish it from sibling tools that manage properties or work item types individually.
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 usage conditions: at least one of attach_ids or detach_ids must be provided, and clarifies that detach does not delete the property. It implicitly tells when to use this tool (managing associations) but does not explicitly state when not to use it or compare with alternatives like creating/deleting properties.
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 non-read-only, non-idempotent, non-destructive behavior. The description adds context about the relationship creation process and return of created objects, which is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear summary and well-organized paragraphs, though slightly long; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all necessary aspects: prerequisites (list definitions), parameter handling, and return type, making it complete for a complex tool with 6 parameters.
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?
With 0% schema description coverage, the description fully explains each parameter in the Args section, including usage differences between relation_type and definition fields, adding significant meaning.
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 'relate' and the resource 'work item to targets', and distinguishes itself from sibling tools like remove_work_item_relation and list_work_item_relations.
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 instructs to call list_work_item_relation_definitions first and explains how to handle built-in vs custom relations, providing clear guidance on when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses the read-only nature (consistent with readOnlyHint), pagination behavior, optional expansions, field selection, and the return envelope structure. It adds value beyond annotations by explaining PQL usage and UUID resolution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear Args and Returns sections, but is slightly lengthy due to extensive PQL guidance. It is front-loaded with the main purpose and could be trimmed slightly, but remains effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, output schema exists), the description covers all aspects: required params, optional filters, pagination, expansions, and return values. It is complete and provides sufficient context for correct agent usage.
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?
With only 13% schema description coverage, the description compensates fully by documenting all 8 parameters in the Args section, including default values, constraints (per_page 1-100), and detailed PQL syntax with examples. This adds significant meaning 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 lists work items in a module with optional PQL filtering. It specifies the required parameters (project_id, module_id) and distinguishes from sibling tools like list_work_items which lists all work items without module scoping.
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 detailed guidance on using PQL with examples, references to other tools (list_projects, get_pql_reference), and pagination with cursor. However, it does not explicitly state when not to use this tool versus alternatives, though the module context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description adds detailed behavioral context: pagination with cursor, default per_page, total_count semantics, sparse fieldset behavior (null means not requested), and external system filtering. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, usage guidance, args, returns) and is front-loaded with core purpose. While lengthy, each sentence adds value, and the bullet points improve readability. Minor redundancy in field descriptions but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, pagination, filtering, sparse fields, external system integration) and the presence of an output schema, the description covers all necessary aspects: input parameters, return structure (results, total_count, cursors), and behavioral nuances. It is sufficiently complete for agent usage.
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 low schema description coverage (11%), the description provides extensive parameter details: pql examples, order_by syntax, per_page range, cursor usage, expand comma-separated relations, fields list with null behavior, and external_id/source pairing. This adds significant meaning 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 lists work items with optional PQL filtering, and distinguishes it from siblings by explaining how to scope results (workspace-wide vs single project) and how to resolve UUIDs using other list tools. This provides specific verb+resource scope differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to omit or include project_id, and instructs the agent to call relevant list tools for UUID fields. It also references get_pql_reference for complex queries. However, it does not explicitly differentiate from search_work_items or other filtering tools, leaving some ambiguity.
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?
Annotations only indicate mutation (readOnlyHint=false) and open world. Description goes far beyond: explains workspace vs project mode handling, automatic feature enabling, exact matching, no duplication. Covers behavior annotations cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with paragraphs and bullet points. Front-loaded with purpose. Slightly verbose (e.g., repeats 'create it if missing' three times) but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (mode detection, creation vs import), the description covers all relevant behavior. Output schema exists so return value explanation is sufficient. No gaps for a tool this intricate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage but description fully explains both parameters: project_id as UUID of the project, name as work item type name with examples. Adds meaning beyond type info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (resolve), resource (work item type), and outcome (find or create and make usable). It distinguishes from siblings like list_work_item_types or create_work_item_type by positioning itself as a combined deterministic operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use: before calling create_work_item to get type_id. Contrasts with manual alternative (combining multiple tools). Lacks a 'when not to use' statement, though context implies it replaces multiple steps.
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?
Annotations indicate mutation, idempotency, and non-destructiveness. Description adds important behavioral details: upsert semantics, multi-value replacement, and value type mappings. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured, starting with a clear action sentence, then covering upsert behavior, value types, and parameters. Slightly verbose with the code block for types, but overall efficient and 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?
Given the tool's complexity (6 parameters, 4 required, output schema exists), the description covers all needed aspects: purpose, behavior, parameter details, and return type hint. It handles multi-value and type variations comprehensively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates with detailed value type explanations for the 'value' parameter and lists all parameters with brief descriptions in the Args section. This adds significant meaning beyond the bare schema structure.
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 'Set (create or update) the value of a custom property on a work item' with specific verb and resource. It distinguishes from siblings like get_work_item_property_value and delete_work_item_property_value by specifying the upsert nature and value types for custom properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on when to use the tool (creating or updating custom property values) and includes value type mappings. However, it does not explicitly mention when not to use it or point to alternative tools for reading or deleting property values, which would enhance guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by detailing the behavioral implications of status values (e.g., converting to active work item, requiring duplicate_to or snoozed_till). It also clarifies that work_item_id must be the issue field from IntakeWorkItem response, not the intake work item ID, a critical nuance.
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 moderately sized but well-structured with a general statement, a list of status values, an args list, and a returns line. It is clear and organized, though slightly lengthy; could be trimmed without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, conditional logic) and presence of an output schema, the description covers essential behaviors: status effects, parameter requirements, and the return type. It is complete for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining each parameter's meaning and conditional requirements (e.g., snoozed_till needed for status=0, duplicate_to for status=2). It adds value beyond the raw 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 updates an intake work item, including triage status. The status values are detailed, and it differentiates from sibling tools like create_intake_work_item and retrieve_intake_work_item by focusing on update operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the effect of each status, guiding when to use (e.g., converting to active work item, marking duplicate, snoozing). It does not explicitly list alternatives or when not to use, but the context is sufficient for agent decision-making.
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 this is a write operation (readOnlyHint: false) and not destructive (destructiveHint: false). The description adds valuable context about the ToolError when the feature is disabled, which is behavioral beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with a one-line summary, then Args, Returns, and Raises sections. It is concise—every sentence adds necessary information without redundancy. No extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, feature flag dependency, output schema exists), the description covers all necessary usage aspects: creation, parameter explanation, return value, error handling, and fallback. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description provides clear, concise explanations for all 7 parameters in the Args section. Each parameter's meaning and format (e.g., ISO 8601 for dates, enum values for state) are described, adding significant value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Create a new initiative in the workspace.' and distinguishes from sibling tools like list_initiatives, retrieve_initiative, etc., by specifying the creation action. The description also includes a fallback behavior when the feature is disabled, further clarifying its unique role.
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 describes when to use this tool and when not to: if the workspace's initiatives feature is disabled, the agent should instead create an 'Initiative' work item. The error message is said to contain exact steps, providing clear guidance on alternative actions.
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?
Annotations already indicate read-only and open-world. Description adds concrete details: return format (dict with 'detail' and 'reference'), behavior of detail parameter (full vs brief). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise, front-loaded with purpose, then usage, then parameter/return details. Every sentence is informative with no 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?
Given simple single-parameter tool with existing output schema, the description covers purpose, usage, parameter behavior, and return structure. Complete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so description fully explains the single parameter. Clearly defines the two enum values and their meanings (comprehensive vs compact reference), adding 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?
Clear verb 'Return' and specific resource 'PQL syntax reference'. Explicitly lists the sibling tools that use PQL filters, distinguishing its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to call the tool ('when composing pql filter for...'), providing clear context. Lacks explicit 'when not to use' or alternative tools, but the directive is sufficient.
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?
Annotations indicate readOnlyHint=true (read-only). The description adds detailed behavioral context beyond annotations: filterable, paginated, case-insensitive contains for string filters, exact match for role_slug, and pagination envelope in returns. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a one-line summary, optional filters grouping, and an Args section with each parameter's role. It is concise, front-loaded, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (filtering, pagination), the description covers input, filters, pagination mechanics, and output format (paginated envelope with members, total_count, next_cursor, next_page_results). No gaps.
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 the context signal indicating 0% schema coverage, the description explicitly lists all parameters with their behavior (e.g., 'case-insensitive contains', 'omit for first page', '1-1000, default 100', sort prefix '-'). Adds significant meaning beyond the bare 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 starts with 'List members of a project (filterable, paginated)', clearly stating the action, resource, and capabilities. It distinguishes from sibling tools like 'get_workspace_members' which lists workspace-level members.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the use of optional filters with AND logic and cursor-based pagination. It implicitly guides when to use (to list project members), but lacks explicit when-not guidance or direct comparison to similar tools like get_workspace_members.
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. The description adds that the URL is presigned for ~1 hour and requires no Plane authentication, which provides useful behavioral context beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with a clear title, a short paragraph, and labeled Args/Returns sections. Every sentence is informative without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of annotations and an output schema (implied by the return description), the description covers purpose, prerequisites, behavior, parameters, and return format completely. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description compensates fully by naming each parameter and specifying they are UUIDs. This adds meaning beyond the raw schema types.
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 gets a presigned download URL for a work item attachment, using a specific verb and resource. It distinguishes itself from sibling tools like read_work_item_attachment, upload, delete, and list by focusing on URL generation.
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 instructs the user to 'Use list_work_item_attachments first to get attachment IDs and names,' providing clear when-to-use guidance. It also notes that the URL is time-limited and requires no authentication, aiding correct invocation.
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?
Discloses behavioral traits: removal applied first, silent skip for already-assigned users, and no full list replacement. Beyond annotations (readOnlyHint=false, openWorldHint=true), it clarifies side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Efficiently structured: summary sentence, then parameter list, behavior notes, and return value. No unnecessary words, front-loaded with key action.
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?
Complete given complexity: mutation tool with output schema noted, parameter semantics covered, behavioral nuances explained, and no missing context for selection among siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds full meaning for each parameter (UUID types), explains optionality and defaults, and describes combined usage. Schema has no descriptions, so description fully compensates.
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 adds or removes a single assignee without replacing the full list, distinguishing it from sibling tools like update_work_item that might modify other aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear instructions on providing parameters and order of operations (removal before addition). Lacks explicit alternatives for full list replacement, but context is adequate.
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?
The description adds significant behavioral insight beyond annotations: it details the order of operations (removal first), idempotency (silent skip for already-attached), and the return type. Annotations only indicate mutability and potential side effects, so the description enriches transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence purpose, then a paragraph on usage, followed by a clear list of parameters and return type. All information is front-loaded, and no sentences are extraneous.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers essential behavior (order of operations, idempotency) and parameter meanings. It does not elaborate on error cases or prerequisites, but given the output schema exists and the tool is straightforward, it is adequately complete for an agent to use 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 description lists each parameter with a brief description (e.g., 'UUID of the project,' 'UUID of the label to add'), which adds meaning not present in the schema. However, the coverage is moderate—no validation details or constraints are mentioned, but it sufficiently explains the data expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Add or remove a single label on a work item without replacing the full list,' which clearly identifies the verb (add/remove) and resource (label on work item) and distinguishes it from sibling tools like update_work_item that replace the full list.
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 clear usage instructions: 'Provide add_label_id, remove_label_id, or both. If both are given the removal is applied first, then the addition. Already-attached labels in add_label_id are silently skipped.' This explicitly covers when to use each parameter and the behavior when both are provided.
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?
The description adds behavioral details beyond annotations, such as that removing a built-in dependency and a custom relation are independent (removing one leaves the other intact). This aligns with annotations (destructiveHint=true, idempotentHint=true) and does not contradict 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?
The description is concise: a brief summary, a behavioral note, and a clear args list. It is front-loaded with the primary purpose and structured for easy scanning. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 required parameters and no output schema. The description explains the action, behavior, and all parameters thoroughly. It also references list_work_item_relations for additional context, making it complete for a removal tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by explaining each parameter's meaning and usage, especially is_dependency (True for built-in dependency, False for custom relation). This provides essential context that the schema alone does not.
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 ONE relation between two work items' and distinguishes between built-in dependencies and custom relations. Among siblings like create_work_item_relation and list_work_item_relations, this tool's purpose is distinct and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to set is_dependency True or False and references list_work_item_relations for context. It does not explicitly state when not to use or list alternatives, but the context is clear enough for correct usage.
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 annotation, the description adds valuable behavioral details: truncation behavior with max_length, the response fields content_truncated and total_content_length, and the difference between project and workspace pages. 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 well-structured with a clear purpose statement, followed by contextual details, and then an Args/Returns format. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 params, output schema exists), the description covers retrieval behavior, truncation, and the distinction between page types. It is complete for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides explicit and detailed semantics for all three parameters: page_id, project_id, and max_length. It explains their purposes and effects, fully compensating for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a page by ID including its content. It specifies the resource (page) and action (retrieve) and distinguishes between project and workspace pages, differentiating it from sibling tools like list_pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use project_id for project pages and implies use of page_id. It does not explicitly contrast with alternative tools like list_pages or search_pages, but being the only retrieve_page tool, the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant behavioral context beyond annotations: explains no server-side API, client-side filtering, performance implications of search_content, and the 30-page cap. No contradiction with readOnlyHint and openWorldHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (description, args, returns). Every sentence is informative and concise. No redundant or vague phrasing.
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?
Provides all necessary context: purpose, limitations, input semantics, output format, and edge cases (Community Edition). The return format is described in detail, complementing the output 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?
With 0% schema description coverage, the description fully compensates by explaining each parameter's semantics, including the special case for project_id (workspace pages vs. Community Edition). Adds meaning beyond the raw 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 searches pages by title (and optionally content) with a case-insensitive substring match. It distinguishes from sibling tools like 'list_pages' and 'search_work_items' by specifying the exact resource and operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on when to use: for searching pages by title/content. Notes the client-side limitation and the cap on content search, but does not explicitly mention alternatives (e.g., using 'list_pages' for a full list).
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?
Annotations indicate readOnlyHint=true and openWorldHint=true, and the description adds valuable behavioral context: returns image objects or strings depending on file type, raises ValueError for unsupported types or size limits. 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?
Well-structured with clear sections (purpose, supported types, unsupported types, args, returns, raises). Front-loaded with main action and file type details. No redundant sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all necessary aspects: supported/unsupported file types, size limits, return types, error conditions. Without an output schema, the description fully explains return values. For a fetch tool, it is comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description compensates by stating each parameter's role ('UUID of the project/work item/attachment'). Although not deeply detailed, it clarifies what each ID refers to, which is sufficient given their intuitive names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch an attachment's content so the LLM can read or analyze it' and lists supported/unsupported file types. It explicitly references the sibling tool 'get_work_item_attachment_download_url' for unsupported types, differentiating its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use (supported file types) and when-not-to-use (unsupported types, with alternative tool named). Also includes size limits and error handling, giving clear guidance on usage boundaries.
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?
Annotations already declare readOnlyHint and openWorldHint; description adds pagination behavior, trimmed field list, sort order with '-' prefix for descending, and return envelope structure. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: one-line summary, list of trimmed fields, parameter descriptions, return format. Every sentence adds clear value without redundancy. Well-structured with bullet-like formatting.
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 tool complexity (pagination, trimmed fields, 3 optional params), output schema exists, and description covers all: parameter defaults, pagination envelope, and referral to sibling for full details. Complete and self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description fully explains each parameter: cursor (omit for first page), per_page (range 1-1000, default 1000), order_by (sort field with prefix for direction). Adds critical meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'List projects in a workspace (lite, paginated)' with specific verb and scope. Distinguishes from sibling 'retrieve_project' by noting trimmed fields and directing to that tool for full detail.
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 to use this tool (listing projects with trimmed fields) and when to use alternative ('For full detail use retrieve_project'). Also explains pagination usage with cursor and per_page.
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?
Annotations include readOnlyHint=true and openWorldHint=true. Description complements by confirming read-only search behavior, listing matched fields, and indicating return type (WorkItemSearch object). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured: starts with purpose and guidelines, then parameter descriptions. All sentences add value; no fluff or repetition.
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?
With 6 parameters, an output schema, and many sibling tools, description covers search scope, parameter semantics, and return type. No gaps remain for an intelligent agent to misinterpret.
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 0% schema description coverage, the description provides detailed explanations for all 6 parameters, including 'query' (matched fields), 'expand', 'fields', 'external_id', 'external_source', and 'order_by'. Adds clear meaning beyond JSON 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?
Description clearly states it searches work items by text across a workspace, matching on name, sequence id, and project identifier. Explicitly distinguishes from 'list_work_items' for structured filtering, making purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: use for free-text search; for structured filtering (priority, state, assignee, dates, etc.) use 'list_work_items' with PQL. Also specifies matched fields, helping agent decide when to invoke.
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:

[![plane-ce-mcp MCP server](https://glama.ai/mcp/servers/Bl4nk44/plane-ce-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Bl4nk44/plane-ce-mcp)

Score Badge

Copy to your README.md:

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

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