plane-mcp

Server Quality Checklist

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

Latest release: v0.1.1
Disambiguation3/5
Most tools are clearly separated by resource type (labels, states, issues, etc.), but `get_issue_using_readable_identifier` and `get_issue_details_by_readable_id` overlap heavily, both retrieving issues via readable identifiers with only slight input differences. This ambiguity could cause an agent to pick the wrong one.
Naming Consistency4/5
The majority of tools follow a consistent verb_noun pattern (e.g., list_labels, create_issue, delete_cycle). Minor deviations like `get_issue_details_by_readable_id` and singular/plural mismatches (delete_module_issue vs add_module_issues) prevent a perfect score.
Tool Count2/5
With 49 tools, the server is far above the 25+ threshold, making it unwieldy for agents to discover and select tools. Even for a broad project management domain, the count feels excessive and could benefit from consolidation.
Completeness4/5
The tool set provides full CRUD for issues, labels, states, issue types, modules, cycles, and worklogs, covering core workflows well. Some gaps exist, such as no update/delete for projects and no single-project getter, but these are minor and workable.
Average 3.5/5 across 49 of 49 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies mutation ('Update') but does not explain whether partial updates are supported, what happens to unspecified fields, or any side effects. It also doesn't disclose error behavior or permission requirements, leaving the agent with significant uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise: a single sentence followed by a structured argument list. It avoids verbose explanation, making it easy to scan. However, the parameter list is largely redundant with the schema, which prevents a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, no annotations, no enums) and the presence of an output schema, the description is minimally complete. It fails to explain whether omitted fields are left unchanged, what the shape of the updated issue is, or whether all fields are optional beyond the two required IDs. This is a significant gap 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 description coverage is 0%, so the description must compensate. It lists each parameter with a one-line phrase like 'Updated issue name' or 'Updated state UUID,' which merely echoes the schema's titles and adds the word 'Updated.' It fails to explain the meaning of 'state UUID,' valid priority values, or the formatting of labels/assignees. This is insufficient for an 8-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Update an existing issue.' This is a specific verb+resource pairing that distinguishes it from siblings like create_issue and delete_issue. However, it doesn't elaborate on the scope or unique aspects of updating an issue, 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?
No guidance is provided on when to use this tool vs alternatives. There is no mention of prerequisites, scenarios where other tools (e.g., create_issue) would be more appropriate, or any exclusions. The description simply states the action without contextualizing it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only lists parameters and does not mention side effects, required permissions, or any constraints, making this a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, front-loading the purpose, followed by a clean parameter list with no unnecessary text. Every piece of information serves a direct purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists and parameters are fully described, the description lacks behavioral context, usage scenarios, or potential pitfalls typical for a create operation. It is essentially a parameter listing with no guidance on how the state fits into the broader system.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to all five parameters, including the UUID format for project_id, allowed group values, and hex color note. This compensates for the 0% schema description 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?
Clearly states 'Create a new state.' with specific verb and resource, distinguishing it from sibling CRUD tools like get_state, update_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 Guidelines1/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, prerequisites, or exclusions. It doesn't mention alternatives or any context beyond the bare command 'Create a new 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?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only says 'Delete a label' without mentioning whether the delete is irreversible, if permissions are needed, or if there are side effects on issues or other linked data. This is a significant gap for a destructive mutation.
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, front-loaded with the one-line purpose, and has a clear arrow list for parameters. Every sentence is functional with no fluff. However, it might be slightly too terse given the lack of other context, but for conciseness and structure alone, it's well-organized.
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 this is a delete operation with no annotations, the description should provide more context such as irreversibility, required permissions, or effects on related data. It also does not mention what the return value or output looks like (though an output schema exists). The description is minimal and does not fully cover the operational context a delete tool requires.
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 mostly restates the parameter names and adds 'UUID identifier', providing minimal extra meaning over the schema (which only has titles). Since schema description coverage is 0%, the description does compensate partially by clarifying that both parameters are UUIDs, but it doesn't explain the relationship between project_id and label_id (e.g., the label must belong to the project) or any validation constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Delete a label.' It identifies the specific resource (label) and the action (delete), which distinguishes it from sibling delete tools for other resources like states and issue types. However, it doesn't mention any nuances like whether the delete is permanent or if there are any cascading effects.
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 vs alternatives or any prerequisites. It simply states the action and parameters. For a destructive operation, it should mention that the label must exist, the project context is required, and consider exclusions (e.g., cannot delete if issues are associated). The lack of such context makes it hard for an agent to decide when or how to safely invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Update' without explaining whether it performs a partial or full update, what happens on error, whether it returns the updated cycle, or any permission requirements. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with a short opening sentence and a bullet-like Args list. It is efficient and front-loaded, but the parameter list is essentially a repeat of the schema titles, so it could be more compact without losing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, the description omits crucial behavioral details like partial vs full update and return semantics. While an output schema exists, the description doesn't clarify how the update operates, making it incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists all six parameters with brief explanations, adding the date format (YYYY-MM-DD) and clarifying that IDs are UUIDs. Since schema description coverage is 0%, this is the sole documentation for parameters, though the explanations are mostly restatements of the property 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 opens with 'Update an existing cycle.' which clearly states the verb (update) and resource (cycle), and distinguishes it from create/delete/list/get. However, it lacks any additional context about scope or constraints that would fully differentiate it from other update tools, though the resource name is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 create_cycle or delete_cycle. There is no mention of prerequisites, conditions, or exclusions, leaving the agent without explicit decision support.
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?
With no annotations, the description bears full responsibility for disclosing behavioral traits. It merely says 'Delete a module' without mentioning irreversibility, permissions, cascading effects on module issues, or failure conditions. This is a significant gap for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—one sentence plus an Args list—and front-loads the action. Every line earns its place without unnecessary 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?
An output schema exists, so return values are covered, but the description omits essential usage context for a deletion tool: permanence, prerequisites, side effects on related entities, and error conditions. For a destructive operation, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only titles and types, so the description's 'Args' section adds the semantic that both are UUID identifiers. This adds some meaning beyond the schema, but it doesn't explain the relationship between project_id and module_id or how to obtain valid values.
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'—a specific verb and resource. This distinguishes it from sibling deletion tools like delete_issue, delete_cycle, and delete_worklog by naming the exact resource 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?
The description provides no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. It only states the action, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavioral traits. It does not mention that deletion is permanent, whether it cascades to associated issues, or any permission requirements. The word 'Delete' implies destruction but no further transparency is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, with no superfluous text. It states the action and parameters directly.
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 delete tool with no annotations, the description is incomplete. It does not state the return value, irreversibility, or constraints on deleting a state that may be in use. The output schema exists but does not compensate for missing behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args section adds meaning beyond the schema by clarifying that project_id and state_id are UUID identifiers, which is additional to the basic string types. However, it does not explain the relationship between them or any validation 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 uses a clear verb and resource, 'Delete a state,' which is unambiguous and distinguishes it from siblings like create_state and update_state by the action taken.
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 update_state, nor any prerequisites or consequences. It only states 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Delete a cycle' without explaining whether the operation is permanent, cascades to associated issues, requires specific permissions, or has other side effects. This is a significant gap for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, with a single sentence and a two-item args list. There is no fluff, but it also under-delivers on useful context. It is appropriately sized for a simple tool, though a note about permanence would be valuable without hurting conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no schema descriptions, and a destructive operation, the description leaves critical gaps about what happens to the cycle's issues, whether the action is reversible, and any preconditions. The presence of an output schema reduces the need for return-value details, but the behavioral context is still insufficient for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal semantics by identifying both parameters as UUID identifiers of the project and cycle, which is slightly more informative than the schema's generic type/title. However, it does not explain the relationship between project_id and cycle_id or the need for both. Given the 0% schema description coverage, this partial compensation is adequate but not thorough.
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 a cycle, using a specific verb+resource formulation. This distinguishes it from sibling delete tools (e.g., delete_cycle_issue) by specifying the resource type. 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 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 vs alternatives like update_cycle or delete_cycle_issue. It does not mention prerequisites, side effects, or exclusions, leaving the agent without directional context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral side effects, such as whether issues are removed from the source cycle, whether permissions are required, or the result of the operation. The mutating nature is implied by the name but not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: a single clear action sentence followed by a compact argument list. Every sentence earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and an output schema not shown, the description should clarify the behavioral scope and outcomes. It leaves ambiguity about whether the transfer is a move (removing from source) or a copy, and whether it applies to all issues or a selection. For a mutation tool, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions (0% coverage), so the description compensates by labeling each parameter (e.g., 'cycle_id: The UUID identifier of the source cycle') and clarifying the roles of source and target. It adds meaning beyond the bare schema fields, though it does not specify any constraints beyond UUIDs.
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: 'Transfer issues from one cycle to another.' It identifies the resource (cycle issues) and the operation (transfer), distinguishing it from siblings like add_cycle_issues or delete_cycle_issue. However, it does not specify whether all issues or a subset are transferred.
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 only lists arguments without contextual cues, prerequisites, or exclusions. An agent would not know if this is preferred over manually adding and deleting issues.
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?
With no annotations, the description needed to disclose side effects (e.g., whether deletion is permanent, what happens to associated issues, required permissions), but it only states 'Delete an issue type' providing no behavioral context beyond the action itself.
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 a one-line purpose followed by a clear Args section. No superfluous content is present, and the structure front-loads the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple, the description is incomplete for a destructive operation: it omits any caveats, permissions, or consequences of deletion. The presence of an output schema explains return values but does not compensate for missing behavioral and 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?
The schema has no descriptions, but the description clarifies each parameter as 'UUID identifier of the project' and 'UUID identifier of the issue type', adding meaning beyond the schema's generic titles of 'Project Id' and 'Issue Type Id'.
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 an issue type, using a specific verb and resource. It distinguishes from sibling CRUD operations like create_issue_type, update_issue_type, and get_issue_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 is provided on when to use this tool, any prerequisites, or alternatives. It only states the action without any contextual cues about appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the basic action and gives parameter names; it does not disclose response details, error behavior, authentication needs, or any other behavioral traits. This is minimal, falling short of the expected transparency for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise: a one-sentence summary followed by two parameter lines. It is front-loaded with the purpose and contains no redundancy or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple get-by-IDs operation, and an output schema exists, so the description need not explain return values. However, the description lacks any context to differentiate it from similar sibling tools (e.g., readable-identifier variants) and provides no usage scenario, making it minimally complete rather than fully.
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 adds value by explaining that both parameters are 'UUID identifier' strings, providing format context beyond the schema's generic 'string' type. This is useful but could include more detail (e.g., where to obtain these IDs).
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 'Get details of a specific issue' clearly states the verb ('Get') and resource ('details of a specific issue'). However, it does not distinguish this from sibling tools like get_issue_using_readable_identifier or get_issue_details_by_readable_id, so it earns a 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description does not mention exclusions, prerequisites, or scenarios where other issue-fetching tools would be more appropriate, which is a clear gap given the many similar sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action without mentioning read-only status, pagination, ordering, or potential limitations. The verb 'Get' implies a read operation, but there is no explicit disclosure about side effects or data scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one clear sentence followed by a simple Args section. It is front-loaded with the main purpose and contains no fluff or redundant details, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an output schema, but the description lacks essential context such as when to use it, behavioral expectations, and any filters or ordering. With no annotations, the minimal description is insufficient for an agent to fully understand the tool's behavior and prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal meaning beyond the schema by clarifying that project_id is a UUID identifier. However, the coverage is 0% per context signals, and the description does not provide additional context like how to obtain the project_id or any constraints. It is marginally helpful but not substantial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('all cycles') with a clear scope ('for a specific project'). It distinguishes from sibling tools like get_cycle, list_cycle_issues, and list_states by clearly indicating it lists cycles for a project, not a single cycle 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 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, such as get_cycle for a single cycle or list_cycle_issues for issues within a cycle. No exclusions or alternative suggestions 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?
No annotations are provided, so the description carries the full burden. It discloses the basic read-only nature via 'Get', but does not mention potential pagination, error behavior, or any side effects or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with no redundant fluff. The Args section is clearly formatted and each sentence serves a 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?
With an output schema present, return values are handled. For a simple list operation with two parameters, the description is sufficient, but it lacks explicit usage guidance and behavioral detail, making it only minimally 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%, and the description compensates by explaining that project_id is the UUID of the project containing the module and module_id is the UUID of the module. This adds relationship context beyond the bare property 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 the tool gets all issues for a specific module, using a specific verb and resource. It does not explicitly distinguish this from sibling tools like list_project_issues, but the module focus is clear.
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 exclusions, and no prerequisites beyond the required parameters. The description only states what it does, not why or when to use it.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Delete an issue' without mentioning irreversibility, required permissions, potential cascading effects, or any other side effects. This is critically under-transparent for a delete operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a one-line purpose statement followed by a clean argument list. No unnecessary words or repetition; everything 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?
The tool is simple with two clear parameters and an output schema. However, the description lacks essential context for a destructive operation, such as irreversibility or permission requirements. This is a meaningful gap despite the tool's 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?
The description adds meaning by specifying that both parameters are UUID identifiers and clarifies the role of issue_id as 'the issue to delete'. This compensates for the 0% schema description 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 'Delete an issue' with a specific verb and resource. This distinguishes it from sibling tools like create_issue, get_issue, and update_issue.
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, when not to use it, prerequisites, or alternatives. For a destructive operation, this is a significant omission.
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?
With no annotations, the description carries the full burden of disclosing side effects, permissions, reversibility, and return behavior. It only restates the action ('Remove an issue from a module') without any context beyond the verb itself. The second sentence 'Unassign module from issue' adds no behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but the second sentence is a redundant restatement of the first. It could be more concise by merging into one sentence, yet the Args structure is clean and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-param mutation with an output schema, the description covers the core purpose and parameter meanings. However, it lacks behavioral transparency (e.g., whether the issue itself is deleted) and usage guidance, leaving gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the Args section in the description compensates by explaining the semantic role of each ID (project containing the module, module containing the issue, issue to remove). This adds meaning beyond the schema's bare property titles, though it lacks format or value 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 uses a specific verb ('Remove') and resource ('issue from a module'), clearly distinguishing it from siblings like delete_module, delete_issue, and add_module_issues. The phrasing is unambiguous about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you want to remove an issue from a module) but does not explicitly state when to use it over alternatives or mention related tools like add_module_issues. No exclusions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only says 'Get details' without disclosing behavioral traits such as required permissions, error behavior, side effects, or return format. It implies a read operation but does not explicitly state safety or any special conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise: a one-sentence purpose followed by a clear Args section. Every piece of information is relevant, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-id tool with two parameters and an output schema, the description covers the essential aspects: purpose and parameter semantics. It is largely sufficient for an agent to invoke the tool correctly, though it lacks contextual tips about related tools or prerequisites.
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 provides no descriptions for project_id or module_id (0% coverage). The description compensates by adding 'The UUID identifier of the project' and 'The UUID identifier of the module', giving meaning the schema lacks. This is valuable but not exhaustive (e.g., no mention of relationship constraints).
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 states 'Get details of a specific module', which clearly identifies the action (get details) and the resource (specific module), distinguishing it from list_modules that lists all modules. However, it does not explicitly name alternatives, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus other get_ tools or list_modules. The description lacks any usage context, prerequisites, or exclusions, leaving the agent without 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?
No annotations are present, so the description carries the burden of conveying behavioral traits. 'Get details' implies a safe read-only operation, but it does not disclose error behavior, permission requirements, or what exactly constitutes 'details.' The description adds minimal context beyond 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a front-loaded purpose sentence followed by a clean parameter list. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (per context signals), the description does not need to explain return values. It adequately documents the two required parameters, making the tool invocable. It lacks usage context and parameter depth, but for a simple getter, it is functionally 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 renames both parameters with brief explanations ('The UUID identifier of the project' and 'The UUID identifier of the state'), adding the fact that they are UUIDs. However, this is only slightly more informative than the schema's titles and types, and it does not clarify their relationship or required formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get details') and the resource ('a specific state'), making it easy to identify the tool's purpose. It does not explicitly distinguish from sibling getter tools like get_label, but the resource name is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as list_states for retrieving multiple states. It also lacks any mention of prerequisites or contexts in which 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?
With no annotations, the description must disclose behavioral traits, but it does not. It fails to specify whether the update is partial (only provided fields) or full replacement, what happens if the label does not exist, whether permissions are required, or what the response contains. 'Update' implies mutation but leaves critical side effects and error behavior undisclosed.
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. It opens with a one-sentence purpose, then lists each argument with a brief explanation. Every word earns its place; there is no redundancy or filler. The format is scannable and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, the description is incomplete. It does not explain update semantics (partial vs full replacement), success/failure behavior, or required permissions. The output schema exists, so return details are covered elsewhere, but the lack of behavioral context and usage guidance leaves significant gaps for an agent deciding to invoke this 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?
Despite the schema having no property descriptions (0% coverage), the description's Args section provides meaningful explanations for each parameter: 'project_id: The UUID identifier of the project', 'name: New name for the label', 'color: New color hex code for the label'. This adds value beyond the bare schema titles. However, it does not clarify nullability semantics or whether omitted fields are left unchanged.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a clear verb+resource statement: 'Update an existing label.' This immediately distinguishes it from siblings like create_label, delete_label, get_label, and list_labels by explicitly indicating modification of an existing resource. No ambiguity or tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites (e.g., label must exist), when to prefer it over create_label or get_label, or any exclusions. The description only states the action without contextual or conditional advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only says 'Update an existing state' and lists fields, but does not disclose partial-update behavior, required permissions, side effects, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear summary sentence followed by a compact argument list. No filler or redundant content; every line is purposeful.
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 six parameters and no annotations, the description is under-specified for a mutation tool. It omits key details such as whether optional fields default to null and whether omitting a field preserves its current value, and it provides no 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?
Schema description coverage is 0%, but the description compensates by explaining each parameter: project_id and state_id as UUIDs, 'new name', 'new group' with allowed enum-like values, 'new description', and 'new color hex code'. This adds meaningful 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 'Update an existing state,' using a specific verb and resource. This distinguishes it from sibling tools like create_state, get_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 is provided on when to use this tool versus alternatives. It does not mention checking if a state exists first, nor when to prefer create_state or delete_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?
No annotations are provided, so the description carries full burden. It does not disclose whether issues are appended or replace existing issues, whether duplicates are allowed, or any side effects. A mutation tool with zero behavioral details is inadequate for 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 brief and front-loaded, with a clear one-sentence summary followed by a compact Args list. Every part earns its place, avoiding unnecessary wording.
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 three-parameter tool, the description covers the core purpose and parameters, and an output schema is present so return values need not be explained. However, missing behavioral details (e.g., replace vs. add) and usage guidance leaves gaps for an agent selecting and invoking 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?
Although schema coverage is 0%, the description provides meaningful parameter semantics: project_id identifies the containing project, cycle_id identifies the target cycle, and issues is an array of UUIDs. This compensates well 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 explicitly states 'Add issues to a cycle' – a specific verb and resource combination. This clearly distinguishes it from sibling tools like delete_cycle_issue, transfer_cycle_issues, and list_cycle_issues.
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 (e.g., transfer_cycle_issues). The description simply states the action without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Create a new issue' and lists parameters, but does not disclose side effects, permissions, validation behavior, idempotency, or response characteristics. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a structured Args list. Every parameter is listed succinctly without fluff, making it easy to scan and parse. No redundant information is included.
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 all parameters and includes an output schema, so return values are handled. However, it lacks broader context such as required permissions, error conditions, or behavioral caveats. For a tool with 7 parameters and no annotations, this is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description compensates well by explaining each parameter: project_id is a UUID, description is HTML, priority lists allowed values (urgent, high, medium, low, none), and assignees/labels are UUID lists. This adds meaning beyond the raw schema, though some semantics (e.g., state_id meaning) remain thin.
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 issue in a project' with a specific verb and resource, distinguishing it from sibling tools like update_issue, delete_issue, and get_issue. The action and target are 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 for when to use this tool versus alternatives. The description does not mention prerequisites, exclusions, or related tools, leaving the agent to infer usage solely from the 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the action ('create') and lists parameters, with no disclosure of side effects, permissions, idempotency, duplicate handling, or validation behavior. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded with the primary action. The Args list is a clean, structured way to present parameter information without redundant prose. 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?
For a simple create tool with an output schema, the description covers the basic purpose and parameters adequately. However, it lacks usage guidelines and behavioral context, which are important for an agent to decide when to invoke it and what to expect. Not fully complete but not severely deficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters are described in the Args block, adding meaning beyond the schema's bare type/title (e.g., 'UUID identifier of the project', 'hex code for the issue type'). This compensates for the 0% schema description coverage. However, some descriptions are terse (e.g., 'Icon identifier') and could be more precise.
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 issue type', a specific verb+resource that distinguishes it from sibling tools like get_issue_type, update_issue_type, and delete_issue_type.
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 'create' and the resource type, but there is no explicit guidance on when to use it versus alternatives (e.g., when you need a new issue type vs. an existing one). No exclusions or prerequisites mentioned beyond parameter requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It states 'Create a new label' but does not mention that this is a write operation requiring appropriate permissions, whether duplicate labels are allowed, what happens on failure, or any side effects. The parameter list adds no behavioral context beyond their definitions.
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, consisting of a one-line purpose followed by a structured Args block. Every line adds value — the purpose sentence is front-loaded, and the parameter explanations are brief yet informative. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple CRUD create operation with an output schema, the description covers the basics: what it does and what each parameter means. However, given the lack of annotations, it does not address permissions, error conditions, or relationship to other label operations (like update_label). It is minimally viable but lacks the richer context that would make it 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's Args list is the sole source of parameter meaning. It provides clear, human-readable definitions for all four parameters: project_id as a UUID, name as the label's name, description as the description, and color as a hex code. This goes beyond the schema's types/defaults and effectively compensates 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 begins with 'Create a new label', which is a specific verb+resource statement that clearly distinguishes this tool from siblings like list_labels, get_label, update_label, and delete_label. 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that update_label should be used for modifying existing labels, nor any prerequisites or conditions for creating a label. The absence of usage context leaves the agent to infer from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose behavioral traits on its own. It only says 'Remove an issue from a cycle' without stating whether this is destructive/irreversible, whether it affects the issue's existence elsewhere, or what the output looks like. The description does not add meaningful context beyond what the tool name already implies.
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 one action sentence followed by a parameter list. Every element serves a purpose, and the main action is front-loaded. There is no redundancy or unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the core purpose and parameter semantics, and the presence of an output schema means return values need not be explained. However, it lacks usage guidelines and behavioral transparency, which are important for a mutation tool with no annotations, leaving the description only minimally 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%, but the description compensates with an Args list that explains each parameter: project_id, cycle_id, and issue_id are all clearly defined as UUID identifiers of their respective entities. This adds meaning beyond the schema's bare type declarations.
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 with a specific verb and resource: 'Remove an issue from a cycle.' This distinguishes it from sibling tools like delete_cycle (which deletes the entire cycle) and add_cycle_issues (which adds issues to a cycle).
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 delete_issue (which deletes the issue entirely) or transfer_cycle_issues (which moves issues between cycles). It does not mention prerequisites or exclusions, leaving usage context ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'Get details' and lists arguments, but does not mention whether the operation is read-only, error handling, ownership constraints, or any side effects. The description adds little beyond the function name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with a one-line purpose and a simple args list. No wasted words, 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get operation, the description covers the basic purpose and parameters, but lacks usage guidelines and behavioral transparency. The presence of an output schema mitigates the need to describe return values, but the description still feels incomplete because it does not provide context on when to use this tool or what prerequisites exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal value over the schema by stating that project_id and cycle_id are UUID identifiers, which clarifies the expected format but does not explain their relationship or how to obtain them. Given 0% schema coverage, this basic clarification is helpful but insufficient to fully compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'details of a specific cycle', distinguishing it from list_cycles and other cycle operations. It is concise and specific, leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly mention when to use this tool versus alternatives like list_cycles or list_cycle_issues. However, the phrase 'specific cycle' implies it is for fetching a single cycle, so usage context is weakly implied but not detailed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. However, it only restates the basic operation and does not disclose any behavioral traits such as read-only guarantees, potential side effects, or handling of non-existent issues. The 'get' verb implies non-mutating behavior, but this is not explicitly stated or elaborated.
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 one sentence stating the purpose and a simple Args list. Every part is necessary, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, so return values are covered. However, the description lacks any usage guidance or behavioral context (e.g., ordering, pagination, empty results), and given the absence of annotations, it is minimally viable but leaves gaps for an agent trying to decide when to use it.
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 includes an 'Args' section that explains each parameter ('project_id: The UUID identifier of the project', 'issue_id: The UUID identifier of the issue'), adding meaningful context beyond the schema's type and title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action: 'Get all comments for a specific issue.' This is a specific verb and resource, and it distinguishes the tool from siblings like add_issue_comment (adds comments) and get_issue (retrieves issue details).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions or reference sibling tools like add_issue_comment or get_issue, leaving the agent to infer usage purely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool returns project_id, issue_id, current state, and other details, which is useful. However, it does not mention error behavior, permissions, or edge cases, leaving moderate transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with a clear purpose. The args block is somewhat redundant with the schema but adds useful examples, and the overall length is appropriate.
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 read tool with an output schema, the description is mostly adequate. However, the lack of clarification relative to the nearly identical sibling 'get_issue_using_readable_identifier' is a notable completeness gap, and error conditions are not addressed.
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 no description for the parameter (0% coverage), so the description's Args section adds meaning by explaining the readable ID format and providing examples. This compensates 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 tool gets full issue details using a readable ID, with a concrete example. However, it does not differentiate from the sibling tool 'get_issue_using_readable_identifier', which appears to serve the same purpose, so it 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use when you have a readable ID. But there is no explicit guidance on when to use this tool versus the overlapping sibling 'get_issue_using_readable_identifier' or 'get_issue', nor any exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden of behavioral disclosure. It states 'Get' which implies a read-only operation, but it does not explicitly confirm no side effects, does not mention permissions, rate limits, or any other behavioral context beyond the bare 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: a one-sentence summary plus an Args list for the single parameter. Every element is useful and front-loaded, with no filler.
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 one-parameter tool with an output schema, the description is minimally viable. However, it leaves ambiguities such as the unit of the total (seconds? hours?), whether it aggregates across all issues, and whether any filters apply. It is not rich enough to fully understand the tool's behavior without additional assumptions.
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% since the schema properties lack descriptions. The description compensates by explaining project_id as 'The UUID identifier of the project to get total worklogs for', adding type specificity 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 'Get total logged time for a project', which is a specific verb+resource combination. The scope ('total' and 'project') distinguishes it from sibling tools like get_issue_worklogs that operate at the issue level.
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 get_issue_worklogs or create_worklog. There is no mention of prerequisites, typical scenarios, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden, but it only states that an update occurs and lists parameters. It does not disclose whether the operation is a partial update, whether omitted optional fields are reset to null, what validation is performed, or what the response contains.
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 appropriately sized: one clear action sentence followed by a structured Args list. Each parameter line is short and directly useful, with no fluff or repetition of schema information beyond the parameter name itself.
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 parameter list is complete and an output schema exists, so return values are covered. However, the description does not explain update semantics such as whether only provided fields are changed, which is a notable gap for a mutation tool with no annotations.
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 Args block supplies per-parameter meaning that the schema lacks, such as identifying project_id and module_id as UUIDs and specifying the YYYY-MM-DD format for date fields. This compensates for the 0% schema description coverage, though some descriptions like 'Updated status' are thin.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Update an existing module', a specific verb-resource pair that clearly indicates this tool modifies an existing module. This distinguishes it from sibling tools like create_module, delete_module, get_module, and the various update_* tools for other 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?
The description offers no guidance on when to use this tool versus alternatives such as create_module for new modules or delete_module for removal. No prerequisites, exclusions, or context are provided beyond the bare update action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden. It only restates the operation and does not disclose whether adding issues is idempotent, whether it replaces or appends to existing assignments, or any permission or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded, with two action sentences and a clean parameter list, avoiding any redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose and all parameters, and an output schema exists. However, it omits behavioral details like idempotency and error handling, which would enhance completeness for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args block provides clear explanations for all three parameters, including their UUID nature and roles, fully compensating for the 0% schema description 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 states 'Add issues to a module. Assign module to issues.' with a specific verb and resource. It clearly distinguishes this operation from siblings like delete_module_issue and list_module_issues by naming the add action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It simply states the action without any context about typical use cases 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only says 'Get information' without specifying what fields are returned, whether authentication is required, or how errors are handled. The output schema may cover return values, but the description adds little transparency beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one clean, front-loaded sentence with no unnecessary words or repetition. It efficiently conveys the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters) and the presence of an output schema, the description is mostly adequate. However, it could briefly indicate what kind of 'information' is returned (e.g., profile fields) to be fully self-contained, so it falls just short of a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so per the rubric the baseline is 4. The description does not need to explain any parameter semantics since there are none, and there is no gap to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and identifies a clear resource ('information about the current authenticated user'). It is unambiguous and naturally distinguishes from sibling tools like get_workspace_members or get_projects, which address 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?
The description gives no guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. It only states the basic function, leaving the agent to infer 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It says 'Get all worklogs' but does not mention whether the operation is read-only (implied by 'get'), whether results are paginated/ordered, or what happens if no worklogs exist. The lack of any behavioral traits beyond the basic function is insufficient for complete transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: a single purpose statement followed by clear parameter definitions. Every sentence earns its place, and there is no redundant or filler content. The structure is clean and easily scannable.
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 presence of an output schema covers return-value details, and the parameter semantics are well explained. However, the description lacks usage guidelines for distinguishing from sibling worklog tools, and offers no contextual caveats (e.g., pagination, ordering, permissions). It is adequate for a basic getter but not fully complete given the surrounding tool cluster.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema. The schema only provides field names and titles ('Issue Id', 'Project Id'), while the description explicitly explains that project_id is 'The UUID identifier of the project containing the issue' and issue_id is 'The UUID identifier of the issue to get worklogs for'. This fully compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get all worklogs for a specific issue', using a specific verb ('Get'), resource ('worklogs'), and scope ('specific issue'). This distinguishes it from sibling tools like 'get_total_worklogs' which aggregates totals, and 'create_worklog' which writes, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'get_total_worklogs' or 'create_worklog'. The description does not mention any prerequisites, exclusions, or alternative tools, leaving the user 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?
No annotations are provided, so the description carries the full burden. It discloses only the action and arguments, but omits behavioral traits such as required permissions, side effects (e.g., notifications), HTML sanitization, or return behavior. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a single purpose sentence followed by a clear parameter list. Every sentence adds value, and no unnecessary information is provided.
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 mutation with three parameters, the description covers the purpose and parameters adequately. However, the presence of an output schema and absence of annotations mean the description could provide more context about expected behavior or side effects. It is functional but lacks some contextual depth.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema contains only field titles with no descriptions (0% coverage). The description compensates by explaining each parameter: project_id and issue_id are UUIDs, and comment_html is HTML content. This adds meaningful semantic 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 states the exact action 'Add a comment to a specific issue' with a clear verb and resource. This clearly distinguishes it from sibling tools like get_issue_comments (read) and create_issue (issue creation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use it when you want to add a comment to an issue. However, it provides no explicit guidance on when not to use it, nor does it mention alternatives like get_issue_comments for reading comments. The context is clear but lacks exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the operation ('create') without mentioning permissions, idempotency, required conditions, or what happens on failure. This is a mutation tool with no safety-relevant context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the main purpose. The Args list is efficiently formatted, with each line contributing useful parameter info. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter creation tool with no annotations, the description provides the essential parameter meanings but omits usage context (when to use vs alternatives), lifecycle considerations, and expected output (though output schema exists). It is adequate but has notable 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%, but the description adds meaning by specifying that project_id is a UUID, start/end dates use YYYY-MM-DD format, and identifies optional parameters. This goes beyond the schema's type-only definitions and provides useful 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 'Create a new cycle in a project' with a specific verb and resource. It distinguishes from sibling tools like list_cycles, get_cycle, update_cycle, and delete_cycle by indicating this is the creation 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 implies usage by saying 'in a project' but does not explicitly state when to use this tool versus alternatives (e.g., update_cycle for modifications). There is no exclusion or alternative guidance, but the CRUD context makes it somewhat clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only lists parameters and restates the obvious 'create' action, with no mention of side effects, permission requirements, idempotency, or response behavior. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise and well-structured: a one-sentence purpose followed by a bulleted Args list. There is no redundancy, and each line provides either parameter meaning or format. This is efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The presence of an output schema covers return values, and all parameters are described, providing a basic level of completeness. However, the tool has 6 parameters including a required project_id, yet the description lacks any context about prerequisites or side effects, leaving some ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description compensates by documenting all six parameters with useful semantics: project_id as UUID, date formats, optional flags, and lead as a UUID. This adds meaning beyond the bare schema properties, though it could be more detailed about relationships.
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 with a specific verb and resource: 'Create a new module in a project.' This distinguishes it from sibling create tools for other entities like labels, states, and issue types. The resource type 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 intended usage is implied by the tool's name and action, but the description provides no explicit when-to-use guidance, prerequisites (e.g., project must exist), or alternatives. It simply states the creation action without contextual boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden of disclosing behavior. It does not mention permissions, side effects, or response behavior, offering only the obvious 'create' action. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus an Args list, with no wasted words. It is front-loaded with the core action and structured for easy parameter reading.
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 create tool with an output schema present, the description is adequate. However, it lacks any mention of workspace context, prerequisites (e.g., required permissions), or uniqueness constraints on identifier, leaving some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to all parameters, especially explaining that identifier is typically 5 uppercase characters. This compensates for the zero schema description coverage and provides useful guidance 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 'Create a new project,' using a specific verb and resource. This distinguishes it from sibling tools like create_issue or create_label, which target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: use when you need to create a project. However, there is no explicit when-not-to-use or mention of alternatives, leaving the guidance minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It fails to mention whether deletion is permanent, whether permissions are required, or any side effects. This is a significant gap for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single one-line purpose followed by a clear parameter list. No unnecessary words or filler, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward delete operation with an output schema present, the description covers the essential purpose and parameters. However, the lack of behavioral transparency (e.g., permanence, permissions) slightly detracts from completeness because annotations are absent and cannot compensate.
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 descriptions for all three parameters, specifying that project_id is the project containing the issue, issue_id is the issue containing the worklog, and worklog_id is the worklog to delete. This hierarchy clarifies the relationships beyond the schema's simple type definitions, compensating for 0% schema description 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 'Delete a worklog' uses a specific verb and resource, clearly distinguishing it from sibling delete tools like delete_issue or delete_label. It accurately conveys the tool's function without ambiguity.
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 prerequisites or exclusions mentioned. The description simply states the action, leaving the agent with no contextual hints for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not mention side effects, error behavior, or what happens if the issue is not found. The description only explains parameter mapping, not runtime 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 description is reasonably concise but contains slight redundancy, repeating the FIRST-123 example twice. It is well-structured with an Args section, making it easy to scan.
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 and presence of an output schema, the description covers the basic purpose and parameters. However, it misses usage differentiation from a very similar sibling tool and lacks any behavioral details, which are important for a complete picture.
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%, so the description must compensate. It does so effectively by explaining the mapping between readable identifiers and the two parameters, with concrete examples (e.g., FIRST-123 → project_identifier=FIRST, issue_identifier=123).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a specific issue using its readable identifier,' with a specific verb and resource. It explains the readable identifier format, but does not explicitly distinguish from the closely named sibling tool 'get_issue_details_by_readable_id'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: when you have a readable identifier like FIRST-123. However, it does not explicitly state when not to use it or compare with alternative tools such as 'get_issue' or 'get_issue_details_by_readable_id'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral burden. It only restates the purpose ('Get details') and parameter formats, without disclosing return behavior, error cases, or read-only nature. The description adds no behavioral context beyond the obvious.
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 purpose sentence followed by a compact arg list. It is front-loaded with the action and contains no redundant or filler 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?
For a simple getter with an output schema, the description covers the core action and parameter meanings. However, it lacks explicit usage context (e.g., when to prefer list_labels) and does not mention error handling or not-found behavior. It is adequate but has clear 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%, and the description compensates by explaining both parameters as 'UUID identifier' for project and label. This adds meaningful format context that the schema's bare property titles lack, though it doesn't elaborate further on 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 'Get details of a specific label,' which is a specific verb (get) and resource (label). The word 'specific' distinguishes it from sibling list_labels, creating clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a single label via the required project_id and label_id, but it does not explicitly contrast with list_labels or mention when to use alternatives. Usage guidance is only implied, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. The word 'Get' clearly indicates a read-only operation with no side effects. However, it does not disclose any additional context such as ordering, pagination, or error behavior, but for a simple list operation this may be sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no wasted words. The purpose is front-loaded, and the parameter explanation is clear and to the point. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, list operation) and the presence of an output schema, the description is fairly complete. It describes the purpose and parameter clearly. It could benefit from a note on differentiating from get_module, but it is adequate for the complexity.
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 description coverage is 0%, so the description must compensate. It provides an Args section explaining that project_id is the UUID identifier of the project, adding meaning beyond the bare schema type. This adequately 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets all modules for a specific project, using the specific verb 'Get' and resource 'modules'. It does not explicitly differentiate from sibling tools like get_module, but the use of 'all' distinguishes its list behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need all modules for a project) but provides no explicit guidance on when not to use it or alternatives. There is no mention of sibling tools or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only states it 'gets all issues.' It does not disclose pagination behavior, rate limits, permissions, or what the response looks like, leaving significant behavioral ambiguity.
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, front-loaded with the main purpose, and contains no filler. The Args block is structured and directly useful for mapping the parameter.
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 (one parameter, no nested objects) and presence of an output schema, the description is minimally viable. However, it lacks usage guidance and behavioral details like pagination, making it 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 only says project_id is a string with 0% schema description coverage. The description compensates by explaining it is 'The UUID identifier of the project,' adding meaningful semantic 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 'Get all issues for a specific project' with a specific verb, resource, and scope. It distinguishes itself from sibling tools like get_issue (single issue) and list_module_issues/list_cycle_issues (scoped to modules/cycles).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need all issues for a project) but gives no explicit guidance on when not to use it or alternatives such as get_issue for a single issue. No exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Update' and lists parameters. It does not mention whether the update is partial (only provided fields) or a full replacement, what happens when passing null for optional fields, required permissions, or any side effects. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core statement, followed by a compact list of parameters. Every line provides necessary information—there is no filler or redundancy. The structure is clear and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and all parameters, and since an output schema exists, return values need not be explained. However, it lacks behavioral details such as partial-update semantics, error handling, or prerequisites (e.g., the issue type must exist). For a simple update tool, this is adequate but not rich enough to fully prepare the agent for edge cases.
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, but the description compensates by explaining each parameter's role, e.g., 'project_id: The UUID identifier of the project' and 'name: New name for the issue type.' This adds meaning beyond the schema's types, distinguishing ID fields from update fields. However, some descriptions (like 'icon: New icon identifier') are vague, so it is not a perfect 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Update an existing issue type.' It uses a specific verb ('update') and resource ('issue type'), and the modifier 'existing' distinguishes it from 'create_issue_type' and 'delete_issue_type' in the sibling 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 phrase 'existing issue type' implies this tool is for modifying already-created issue types, which gives some context. However, it does not explicitly mention when not to use it or point to alternatives like 'create_issue_type' or 'delete_issue_type.' The usage guidance is implied 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?
No annotations are provided, so the description must disclose behavioral traits. It simply states 'Update an existing worklog' and lists parameters, without explaining partial vs. full update semantics, whether null values clear fields, permissions required, or reversibility. This is insufficient for a mutation tool; the behavior beyond the basic operation remains opaque.
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 purpose sentence followed by a clean list of arguments. Every line earns its place, with no fluff or redundant repetition. Structure front-loads the main action and then details parameters, making it easy to scan.
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 purpose and parameters, which is a minimal viable baseline for a CRUD tool. However, it lacks usage guidelines, behavioral edge cases, and preconditions (e.g., the worklog must already exist, correct permissions). Given the tool's mutation nature and absence of annotations, the description leaves several contextual gaps that an agent would need to resolve.
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 does—each parameter gets a one-line explanation, including units for duration ('hours') and context for the IDs. However, it leaves ambiguity about optional parameters (e.g., whether null means 'ignore' or 'set to null'), and the 'Updated' prefix on duration/description/started_at could be clearer. Overall, it adds meaningful 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 action: 'Update an existing worklog.' This is a specific verb+resource pair that distinguishes it from sibling tools like create_worklog and delete_worklog. There is no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage—when you need to modify an existing worklog—but provides no explicit guidance on when to use this tool versus alternatives (e.g., create_worklog for new entries, delete_worklog for removal). No exclusions or conditional scenarios are mentioned, leaving the usage context mostly inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. The verb 'get' implies a read-only operation, but the description does not disclose error handling, authentication requirements, or any side effects. However, the presence of an output schema covers return structure, and the operation is intuitively safe.
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 one purpose sentence and a clean Args block. Every line adds value, and the parameter documentation is well-structured for quick scanning. 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?
This is a simple tool with two required parameters and an output schema that documents return values. The description covers purpose and parameter semantics sufficiently. The lack of usage guidance is a minor gap but not critical given the clarity of the resource name.
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 identifies both parameters as 'UUID identifier' of the project and issue type, respectively, adding clarity beyond the bare string type in the schema. This clarifies expected format and role, though it does not provide examples or 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 'Get details of a specific issue type' with a specific verb and resource. It distinguishes from sibling tools like create_issue_type, update_issue_type, and delete_issue_type. The word 'specific' implies retrieval by identifier, matching the provided parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of exclusions, prerequisites, or related tools. Since there is no list_issue_type sibling, it is unclear if this is the only way to retrieve issue type details or how it compares to other getters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It does not mention authorization requirements, idempotency, effects on existing worklog totals, or potential error conditions. It only lists parameters, leaving the agent unaware of key 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: one sentence stating the purpose plus a structured args list. Every line is informative with no redundant or verbose wording, and the key action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward create operation with five parameters, the description covers all parameter semantics and provides necessary context. It doesn't describe return values or error handling, but an output schema exists and this is a simple tool, making it nearly complete though slightly lacking in permission/validation context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description fully compensates by explaining each parameter, including 'duration in hours (e.g., 2.5 for 2 hours 30 minutes)' and 'started_at: Optional timestamp when work started (ISO 8601 format)'. This adds significant meaning beyond the schema titles.
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 worklog for an issue' with a specific verb and resource. It is distinct from sibling worklog tools like update_worklog, delete_worklog, and get_issue_worklogs, so the agent can easily distinguish 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating a worklog but does not explicitly mention when to use it versus alternatives such as update_worklog or delete_worklog. There is clear context for what it does, but no explicit exclusions or alternative 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?
With no annotations provided, the description carries the full burden. It clearly states the operation is a read ('Get all states'), which inherently implies no destructive side effects. However, it provides no additional behavioral context such as pagination, ordering, or potential errors. The scoping to a project is a useful constraint, but beyond that, the behavior is minimally 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 front-loaded: a single clear sentence stating the purpose, followed by a compact argument explanation. Every word earns its place, with no filler or repetition. The structure is efficient and easy to parse.
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 tool with one parameter and an existing output schema, the description covers the essential purpose and parameter semantics. It does not discuss return structure (covered by output schema), but it lacks context on expected behavior like whether 'all states' means unfiltered or paginated. Given the low complexity, this is nearly complete, though a note on result size or ordering would elevate it.
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 provides only a type and title for project_id with zero description coverage. The description compensates by documenting the parameter in the Args section: 'The UUID identifier of the project to get states for.' This adds crucial semantic meaning (that it's a UUID and what it identifies), going well beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Get all states for a specific project.' This clearly distinguishes it from sibling tools like get_state (which retrieves a single state) and from other list operations on different resources. The scope constraint 'for a specific project' further clarifies 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that get_state should be used for a single state or that other list tools (e.g., list_labels) are for different resources. While the purpose is implied, there is no explicit when/when-not or alternatives, leaving the agent to infer usage from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'Get' implies a read-only operation, but it does not explicitly state safety, permissions, or potential pagination/limitations. The description discloses the basic behavior but leaves some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence purpose followed by a compact Args section. Every sentence serves a purpose, with no redundant or irrelevant 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 tool's simplicity, the description covers the essential purpose and parameter semantics. The presence of an output schema handles return value details. It lacks explicit safety or usage exclusions, but overall it is sufficiently complete for a straightforward list operation.
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 no parameter descriptions (0% coverage), but the description compensates by explaining both parameters clearly: project_id as the UUID of the containing project and cycle_id as the UUID of the cycle. This adds valuable 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's function with a specific verb and resource: 'Get all issues for a specific cycle.' This distinguishes it from siblings like list_project_issues or get_cycle by explicitly targeting issues within a cycle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need issues for a cycle) but does not explicitly mention alternatives or exclusions. It lacks guidance on how it compares to similar tools like list_project_issues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral transparency burden. 'Get' implies a read-only operation and 'all projects' clarifies scope, but it doesn't disclose potential pagination, authentication requirements, or error behavior. It is minimally adequate but lacks richer behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short, front-loaded sentence that conveys all essential information without redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter list tool with an output schema, the description is fully sufficient. It states exactly what the tool returns (all projects for current user), and the output schema covers return structure. No additional context is needed for correct 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 tool has zero parameters, so the input schema is effectively complete. The description adds no parameter details because none are needed; the baseline of 4 applies since no params exist to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') with a clear resource ('all projects') and scope ('for the current user'). It clearly distinguishes from sibling tools like create_project and list_project_issues by indicating it retrieves the overall project list.
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: when you need all projects for the current user. It doesn't explicitly mention exclusions or alternatives, but the context is clear enough given the sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. The verb 'get' implies a read-only operation, but the description does not explicitly state safety, permissions, or any side effects. It provides minimal additional behavioral context beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and resource. It contains no fluff or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool with an output schema, the description is complete—it states the scope ('current workspace') and what is returned ('all members'). No further context appears 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?
The tool takes zero parameters, and the input schema confirms this. The description reinforces that no configuration is needed. Since there are no parameters to explain, the description is fully adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('get') and resource ('all members in the current workspace'), clearly distinguishing it from sibling tools like get_current_user or get_projects. 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case—when you need the full membership list of the current workspace—but it does not explicitly state when to avoid using it or mention alternative tools. This gives clear context but lacks direct exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses the core behavior ('list all labels') but adds no details about pagination, ordering, error handling, or read-only nature. As a simple list operation, this is minimally 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: one clear sentence followed by a structured Args block. No unnecessary words or repetition, and the purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with an output schema, the description adequately explains the purpose and the parameter. It does not mention potential edge cases or return details, but these are either implicit or covered by the output schema. It is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an Args section that explains project_id as 'The UUID identifier of the project,' adding meaningful context beyond the schema's type and title. This fully documents the only parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all labels for a project,' using a specific verb (list) and resource (labels) scoped to a project. This distinguishes it from sibling tools like get_label, which retrieves a single label, and other label-specific 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 about listing all labels for a project, which differentiates it from get_label and other label tools. However, it does not explicitly state when to use this tool over alternatives or mention any exclusions, so it falls short of the full 5.
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-mcp MCP server](https://glama.ai/mcp/servers/mikey-semy/plane-mcp/badges/card.svg)](https://glama.ai/mcp/servers/mikey-semy/plane-mcp)

Score Badge

Copy to your README.md:

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

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