ya-tracker-mcp

Server Quality Checklist

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

Latest release: v0.8.2
Disambiguation3/5
With 135 tools, many have overlapping purposes (e.g., create_issue, import_issue, create_from_preset; list_links vs. list_external_links). The entity-prefixed naming (issue vs. entity) helps, but the sheer volume and subtle differences (e.g., sync_directory vs. sync_all_directories) create ambiguity.
Naming Consistency4/5
Most tools follow a verb_noun pattern (list_*, get_*, create_*, update_*, delete_*). Exceptions like issue_changelog, queue_overview, and bulk_list_links break the pattern but are still readable and predictable.
Tool Count1/5
At 135 tools, this is an extreme mismatch for an MCP server, far exceeding the 50+ threshold. Even for a full-featured API, this is overwhelming and likely to confuse agents.
Completeness3/5
Covers a broad domain: issues, queues, entities, boards, sprints, components, filters, dashboards, macros, triggers, and more. However, notable gaps exist: sprints have only list/create (no update/delete), dashboards only create, and components lack delete. Some resources have unbalanced CRUD, so it's not fully complete.
Average 3.2/5 across 135 of 135 tools scored. Lowest: 2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI 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

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, but it only states that the tool updates entities in bulk. It does not mention potential destructive effects, whether the operation is atomic, error handling for partial failures, or any permissions required, leaving the agent completely in the dark about side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The one-sentence description is concise but severely under-specified, similar to a placeholder. It does not earn its place because it provides no useful information beyond the tool name, making it more of a tautology than a helpful, content-rich description.
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 bulk mutation tool with 3 parameters, no annotations, and no explanation of update semantics (which fields are modified, what happens on failure), the description is inadequate. The existence of an output schema reduces the need to describe return values, but the lack of behavioral and usage context makes the tool difficult to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the parameters: entity_type, entity_ids, and comment, with 100% coverage. The description adds no additional semantic context beyond the schema, so it neither helps nor hinders. Since schema coverage is high, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Bulk update multiple entities' essentially restates the tool name 'bulk_update_entities' without adding specificity. It does not mention that it updates projects, portfolios, or goals, nor does it distinguish this tool from sibling bulk operations like 'bulk_update' or 'bulk_move', making it a near-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?
There is no guidance on when to use this tool versus alternatives such as 'update_entity' for single updates or 'bulk_update' for issues. The description does not provide any context, prerequisites, or exclusions, leaving the agent to guess the appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It says nothing about side effects, idempotency, validation, permissions, response behavior, or any constraints. The agent receives no information about what happens when the tool is invoked.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but this is under-specification rather than effective conciseness. The sentence provides no information that is not already in the tool name, so it fails to earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having four parameters, an output schema, and no annotations, the description provides no contextual information about dashboards, usage scenarios, or behavioral expectations. It is completely inadequate for helping an agent understand the tool's role within the broader API.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter has a basic description. The description itself adds no parameter meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a dashboard.' names a clear action and resource (create + dashboard), so it is not a tautology. However, it is extremely vague—it does not clarify what a dashboard is or what creating one entails, and it does not differentiate from sibling tools beyond the resource name. This is a minimal viable statement of 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?
There is no guidance on when to use this tool, what prerequisites exist, what scenarios call for it, or how it compares to alternatives. The description provides zero context for selecting this tool over others in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. "Delete" implies a destructive operation, but the description does not disclose irreversibility, potential cascade effects on related data (e.g., sprints, issues, links), or permission requirements. This is a significant gap for a destructive tool, though it does at least state the primary action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise in word count (three words), but it is under-specified. It fronts the core action clearly but omits critical behavioral context. This is not effective conciseness; it is an underspecified description that could have included important safety details without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations, the description is severely incomplete. It does not explain the consequences of deleting a board, such as whether associated issues or sprints are also deleted, whether the action is reversible, or if any safeguards exist. Although an output schema exists, the description must still convey the tool's impact, and it fails to do so.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter board_id, described as "Board ID" in the schema. The description adds no parameter-level information, but the baseline is 3 because the schema already documents the parameter fully. The description contributes nothing beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description "Delete a board." is essentially the tool name expanded into a sentence. It restates the action and resource without adding any additional detail, making it tautological. It does not specify what a board is, what deletion entails, or how it differs from related board tools beyond the verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, scenarios where deletion is appropriate, or warn against using it for non-destructive operations. There is no context that would help an agent decide between this and other board-related 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?
With no annotations, the description carries the full burden but only states the action 'create' without disclosing side effects, permission requirements, uniqueness constraints, or reversibility. The behavioral expectations beyond the basic mutation are entirely unspecified.
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 brief, but the brevity comes at the cost of omitting important contextual information. It is a single tautological sentence rather than a well-structured concise description, making it neither appropriately informative nor efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description does not explain the entity types (project, portfolio, goal) or relationship semantics beyond what the schema lists. It lacks clarification on handling duplicate links or bidirectional behavior, leaving significant ambiguity for an agent selecting this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters. The description's 'between entities' subtly reinforces the source/target relationship, but it adds no details about valid values or relationships that aren't already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a link between entities' is a direct restatement of the tool name create_entity_link, adding no new information. It fails to distinguish from related tools like link_issues or list_entity_links without relying on the schema.
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 regarding when to use this tool versus alternatives such as link_issues (for issue links) or when not to use it. The description lacks context about prerequisites or typical use cases.
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 merely states 'Create a saved filter' with no mention of side effects, idempotency, potential overwrites, permission requirements, or what happens on duplicate names. This is essentially a tautology of the tool name and provides no behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which makes it concise in word count, but it is under-specified rather than efficiently informative. It is essentially just an expansion of the tool name and fails to include any contextual or behavioral information that would justify its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters (one required), an output schema, and no annotations, the description is too minimal to provide complete context. It does not explain how to use the filter versus query parameters, when to omit them, or what the created filter is used for. The output schema covers return values, but the description still leaves significant gaps in understanding the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all three parameters ('name', 'query', and 'filter'), so the description adds no additional semantic value. Since the schema already documents parameter meanings, the baseline score of 3 is appropriate; the description neither enhances nor detracts from parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a saved filter.' clearly states the action (create) and resource (saved filter), which differentiates it from sibling tools like get_filter and update_filter. However, it is minimal and does not explicitly highlight how it differs from related operations beyond the verb itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as update_filter or get_filter. It does not mention any prerequisites, constraints, or the choice between query and filter parameters, leaving the agent to infer usage from the schema alone.
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 full responsibility for behavioral disclosure. 'Create a priority' gives no information about side effects, idempotency, failure modes, or impact on existing data. It doesn't even explicitly note that it is a mutation, and there is no context about duplicate keys or ordering behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, making it concise, but it is under-specified. It provides no information beyond what the tool name already conveys, effectively being a tautology. This is underspecification, not effective 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?
Despite having an output schema and fully described parameters, the description lacks essential context for a create operation. It doesn't mention whether this is an admin-only action, potential conflicts, or how it relates to other priority tools. The description is too sparse to support correct tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for all three parameters (key, name, order) with descriptions. The description itself adds no parameter information, so it relies entirely on the schema. Baseline is 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a priority. It uses a specific verb+resource and distinguishes from siblings like list_priorities. However, it is minimal and essentially restates the tool name without adding context about what a priority is or any scope constraints.
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. There is no mention of prerequisites, permissions, or scenarios where create_priority is appropriate over other tools. The description offers no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 merely restates the creation action and gives no information about permissions, uniqueness, duplicate handling, return values, or side effects, making it effectively a tautology of the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise, but it under-specifies and largely repeats the tool name. It lacks any supporting structure or detail, so it does not earn its place as a standalone description.
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?
Even though an output schema exists and parameter descriptions are complete, the description omits essential context: what a resolution represents, whether keys must be unique, required permissions, and its relationship to list_resolutions. This is insufficient for correct invocation of a create operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for both parameters ('Resolution key' and 'Localized name'), so the baseline is 3. The tool description adds no further parameter meaning, such as the structure of the localized name object or key 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 'Create a resolution' clearly identifies the action (create) and resource (resolution), distinguishing it from sibling create_* tools. However, it provides no qualifiers or context about what a resolution is, so it is clear but minimally specified.
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 like list_resolutions or create_issue_type. No prerequisites, exclusions, or alternative tool references are provided.
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 'create', implying a mutation, but does not mention permissions, duplicate handling, reversibility, or side effects. This is a significant gap for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence) and front-loaded, but it is arguably under-specified rather than appropriately concise. It states the purpose but lacks any additional structure or context that would make it more useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and three required parameters (including a nested object), the description provides minimal context. It does not explain what a 'status' is in this domain, how the parameters relate, or any expected behavior, leaving the tool incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all parameters (key, name, stype). The description adds no extra parameter meaning beyond what is already structured, warranting the baseline score of 3.
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 'Create a new status.' uses a specific verb+resource and clearly states the tool's action. It doesn't explicitly distinguish from sibling create_* tools like create_issue_type, but the schema's stype parameter (new, inProgress, done) clarifies it pertains to workflow statuses.
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 is provided on when to use this tool versus alternatives such as list_statuses or update tools. There are no exclusions, prerequisites, or conditional usage notes, 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. The only statement is 'Update an existing issue,' which adds nothing beyond the tool name. It does not disclose whether updates replace fields (e.g., tags and followers per schema), whether certain fields are cleared with null, any authorization requirements, or side effects. This is a complete absence of behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and contains no wasteful words, making it concise. However, it is under-specified to the point where the single sentence adds no value beyond the tool name itself. While it is not verbose, it also does not earn its place in a meaningful way, making a middle score appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 17 parameters and no annotations. The description 'Update an existing issue' provides almost no context about what updating entails, how the parameters interact, or any constraints. Even though an output schema exists, the tool's complexity demands a richer description to guide usage. This is completely inadequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with every parameter having a description. The tool description itself adds no parameter information, but it does not need to because the schema already provides detailed meanings for all 17 parameters. Baseline of 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing issue' clearly states the verb (update) and resource (issue), which is specific enough to know the tool's basic function. However, it does not mention what can be updated or distinguish it from sibling tools like transition_issue or move_issue, which also modify issues. It is clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, typical use cases, or exclusions. For example, it does not indicate whether to use this instead of transition_issue for status changes or add_comment for comments. No usage context is provided at all.
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 to rely on, the description carries the full burden of behavioral disclosure. 'Update a macro' reveals no details about side effects, partial updates, overwrite behavior, required permissions, or error conditions. It is essentially tautological.
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 extremely terse and front-loaded with no wasted words, but it is under-specified. While there is no fluff, the lack of substantive content makes it less than ideal; one sentence with no context is not 'appropriately sized.'
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has five parameters, an output schema, and many sibling operations, yet the description provides no context about update semantics, which fields are updatable, whether the body is optional, or how it relates to other macro tools. This is grossly inadequate 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all five parameters. The description adds no additional meaning beyond the parameter names and descriptions, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('a macro'), making the core function identifiable. However, it does not differentiate from sibling tools like create_macro or delete_macro, which also operate on macros.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, such as the macro needing to already exist, nor does it contrast with create_macro or delete_macro.
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 behavior. It only indicates a mutation ('Update'), but fails to mention whether it is a partial or full update, any permissions required, error behaviors, or 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief ('Update a trigger'), but this is under-specification rather than good conciseness. It is front-loaded but fails to include any substantive information, making it less useful than a slightly longer description with relevant context.
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 moderate complexity (6 parameters, including nullable fields) and the presence of an output schema, the description still lacks essential context about update semantics, operational requirements, and non-obvious behavior. Even though return values may be covered by the output schema, the behavioral and usage context is missing, making the tool difficult to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for all six parameters (e.g., 'New name', 'Enable/disable', 'New actions'). The description contributes no additional meaning beyond the schema, so it meets the baseline for high schema coverage without adding extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a trigger.' clearly states the verb and resource, but it is essentially a restatement of the tool name and provides no details about what updating a trigger entails. It does imply a distinct operation from sibling create/get/list tools, but it lacks specific scope or context, making it minimally adequate.
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 like create_trigger, get_trigger, or list_triggers. The description does not mention prerequisites, appropriate contexts, or situations where other tools should be preferred, leaving usage entirely unexplained.
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. 'Create a new queue' merely restates the action; it does not disclose whether the operation is idempotent, what permissions are needed, what happens if the queue already exists, or any side effects. This is a significant gap for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is front-loaded with the action. However, it is under-specified to the point of being terse, which slightly reduces the score from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 9 parameters, 6 required, and no annotations. The description provides no context about what a queue is, how the configuration options work, or what outputs to expect. Even though an output schema exists, the description fails to give any operational context for a tool with this level of complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with detailed descriptions for all 9 parameters, so the baseline is 3. The description adds no parameter information beyond what the schema already provides, thus meeting but not exceeding this baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific verb and resource: 'Create a new queue.' This clearly distinguishes it from queue-related siblings like delete_queue, get_queue, or list_queues. However, it does not elaborate on what a queue is or differentiate it from create_queue_version, so it lacks full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention prerequisites, required fields, or typical use cases. There are many other create_* tools in the sibling list, and no context is provided to help an agent choose this one.
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 must carry the behavioral burden. It only states 'Search projects, portfolios, or goals' with no disclosure of search behavior, pagination, output format, or any side effects. This provides no meaningful transparency about how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but under-specified for a tool with 7 parameters and an output schema. It lacks structural detail and seems more a placeholder than an appropriately sized description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 params, required entity_type, output schema) and no annotations, the description is severely incomplete. It fails to explain search semantics, pagination, or any context beyond the bare resource scope, leaving the agent without sufficient guidance for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-specific meaning beyond the schema's property descriptions, which already fully document each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (search) and the target resources (projects, portfolios, or goals). This distinguishes it from sibling tools like search_issues and search_worklog, which target different entity types.
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 implies usage for searching these entity types but provides no explicit guidance on when to choose this over alternatives, nor when not to use it. No exclusions or alternative tool mentions are given.
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 must explain behavior on its own. It merely restates the operation ('Update') without disclosing partial-update semantics, required permissions, error behavior, or response details.
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 concise at one sentence, but it largely restates the tool name without adding substance. It's not wasteful, but it doesn't fully earn its place by providing additional information.
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 doesn't clarify how updates behave (e.g., whether omitted fields are preserved) or what the response includes, leaving the agent to infer critical details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions (e.g., 'New filter name', 'New query string'), so the schema carries meaning. The description adds no parameter-level context, meeting the baseline for fully covered schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's action and target ('Update a saved filter'). It doesn't distinguish from sibling tools like create_filter or get_filter beyond the verb, but 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?
No guidance is given for when to use this tool vs alternatives. It doesn't mention when to update versus create or get a filter, nor any prerequisites or exclusions.
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 must disclose behavioral traits. It only states the action of creating a board without mentioning permissions, side effects, or response behavior, leaving the agent without critical safety or operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one clear, concise sentence with no redundancy. It communicates the core purpose efficiently, though it is extremely brief.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has seven parameters and an output schema, yet the description is minimal and does not mention configuration capabilities or important usage context. While the schema covers parameters and the output schema covers return values, the description lacks an overview of the tool's role within the broader API.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for all seven parameters, and the description adds no parameter-specific information. Since schema coverage is high, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new board with a specific verb and resource, making it distinct from board-related siblings like list_boards or update_board. However, it lacks any additional context that would help differentiate from similar creation tools like create_from_preset.
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 information is provided about when to use this tool, prerequisites, or alternatives. The description is purely functional and offers no decision-making guidance.
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 entire burden of behavioral disclosure. It simply states 'Create an issue type' with no mention of side effects, idempotency, uniqueness constraints on the key, permissions required, or error behavior. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the primary action. It is not verbose or bloated, which is appropriate for a simple create operation. However, it is so terse that it misses opportunities to add value, but conciseness itself is well-handled.
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 mutation tool with no annotations and only a minimal description, the definition is incomplete. It does not explain key behavioral aspects like key uniqueness, localization requirements, or how this tool fits into the broader issue-type workflow. Although an output schema exists, the lack of any usage or side-effect context makes the tool difficult to use correctly in all scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters ('key' with example and 'name' with localization example), achieving 100% schema description coverage. Per the baseline, the description does not need to add parameter information, and it adds none. The schema is sufficient, so a score of 3 is appropriate.
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 'Create an issue type' clearly states the verb and resource, and it distinguishes from sibling create tools like create_priority or create_status by explicitly naming 'issue type'. However, it is minimal and essentially restates the tool name, providing no additional detail about what an issue type is or how it differs from related concepts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no mention of prerequisites, and no exclusions. The description provides no context beyond the action itself, leaving the agent without information about appropriate use cases or constraints (e.g., whether issue types must be created before issues reference them).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral details, but it only states the basic create action. It does not mention side effects, permissions, validation requirements, or potential conflicts, making the tool's behavior opaque for an unprecedentedly simple description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but merely restates the tool name in sentence form. It does not earn its place by adding substantive information, and the brevity comes at the expense of necessary context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the schema and output schema, the description lacks critical context about the sprint creation process, such as what happens on success, potential errors, or how this fits into broader workflows. The minimal information makes it incomplete for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with names and descriptions for all four required parameters, including date formats. The description adds no additional parameter semantics, so the baseline of 3 is appropriate since the schema carries the burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('sprint'), making the core purpose unambiguous. It is not a tautology, as it forms a complete sentence, but it lacks any contextual scope or differentiator from other create tools, though the resource name is sufficiently distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description simply says 'Create a new sprint' with no mention of prerequisites, exclusions, or typical use cases, leaving the agent without context for selecting it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It implies a read-only operation but does not mention potential errors (e.g., trigger not found), required permissions, or the structure of the returned details. This is a minimal statement without behavioral depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but under-specified. 'Get trigger details' is essentially a repetition of the tool name and does not earn its place by adding useful information. It is more under-specification than clean conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the schema and presence of an output schema, a one-liner could suffice, but the description fails to distinguish this tool from siblings and lacks context about what 'trigger details' include. Agents may struggle to select this over 'list_triggers' or 'get_trigger_logs'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, as both 'queue' and 'trigger_id' have descriptions. The tool description adds no extra semantic meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb 'Get' and resource 'trigger details', indicating a read operation on a single trigger. However, it does not explicitly differentiate from sibling tools like 'get_trigger_logs' or 'list_triggers', and 'details' is vague about what is returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'list_triggers' (for listing) or 'get_trigger_logs' (for logs). The description merely states what it does but not why it's the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It simply states 'Update a comment' with no mention of side effects, permissions, idempotency, return behavior, or other traits, offering no value beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it extremely concise and front-loaded. While it is not verbose, the brevity borders on under-specification, but the lack of wasted words earns a solid 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?
With six parameters, an output schema, and no annotations, a one-sentence description is inadequate for understanding the tool's full scope, including parameter interactions, response formats, and edge cases. The description leaves substantial gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, meaning all six parameters are already well-documented in the schema. The description adds no additional meaning or context for parameters, so the baseline of 3 applies.
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 (update) and resource (comment), making the tool's purpose unmistakable. However, it does not distinguish this from sibling comment tools like add_comment or delete_comment, so it lacks explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as add_comment or update_entity_comment. The description provides no contextual, conditional, or exclusionary information, leaving the agent without direction on appropriate usage.
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 disclosing behavior. It only says 'Delete a link from an issue,' omitting irreversibility, required permissions, side effects, or failure modes. This is insufficient 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core action. However, it is so sparse that it borders on under-specification, though not as extreme as a tautology.
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 should cover safety, reversibility, or error behavior. It lacks these details, making it incomplete given the destructive nature of the operation and the availability of sibling tools that may be confused.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both parameters have descriptive entries in the input schema. The tool description adds no additional parameter context, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific action (delete) and the resource (a link from an issue), clearly distinguishing it from sibling tools like link_issues (create) and delete_external_link (different resource).
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. The name and description imply the action, but there is no explicit context, exclusions, or alternative comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of disclosing behavioral traits. 'Delete a queue' only names the operation but doesn't state permanence, side effects on associated data, permission requirements, or whether the queue can be restored. Since a sibling tool restore_queue exists, the deletion behavior is likely nuanced, but the description provides no such context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no wasted words, but it is under-specified for a destructive operation. It is a single sentence that conveys only the basic action, missing essential context such as reversibility or scope. This is brevity without adequate substance, so it earns a middling 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?
For a delete tool with no annotations, the description is incomplete. It doesn't mention whether the queue is soft-deleted, what happens to associated issues or tags, or how it relates to restore_queue. The output schema may define the return value, but side effects and prerequisites are absent, leaving a significant gap for an agent to safely invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single parameter queue_key with an example, achieving 100% schema_description_coverage. The description adds no additional parameter semantics, but the schema already provides the necessary meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete) and resource (queue), using a specific verb+resource pattern. It distinguishes from sibling tools like delete_queue_tag and restore_queue by explicitly targeting the queue itself. However, it doesn't elaborate on what 'delete' entails beyond the resource name, so it's clear but not fully expansive.
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 delete_queue versus alternatives such as restore_queue or delete_queue_tag. It doesn't mention prerequisites, whether deletion is reversible, or which user roles can perform it. The absence of any usage context means the agent must rely solely on tool name and shared understanding.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states the action (update) without revealing behavioral traits. It doesn't state whether permissions are replaced or merged, whether it requires special authentication, or what side effects occur. Since no annotations exist, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence without fluff. However, it is under-specified for a tool with a complex permission model, so it's not appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of permissions (multiple actions) and lack of annotations, the description is too brief to be complete. It doesn't explain the payload structure, default behavior, or what 'access permissions' entails.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover all parameters with 100% coverage, providing basic descriptions for each. The tool description adds no extra meaning to the parameters, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'update' and resource 'queue access permissions', clearly indicating the tool's function. It doesn't explicitly distinguish from sibling tools like update_queue or get_queue_user_permissions, but the name and description are unambiguous enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. It doesn't mention that this is for modifying permissions as opposed to viewing them, or any prerequisites like being an admin.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Delete a comment' and omits critical details such as whether the deletion is permanent, cascades to related data, or requires special permissions. This is a significant gap for a destructive 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 extremely concise—four words, zero filler. Every word earns its place, and the structure is simple and direct. However, it is so brief that it borders on under-specification, though for the simplicity of the operation this is acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having a full schema and output schema, the description lacks behavioral context for a destructive operation. It doesn't explain side effects, reversibility, or authorization requirements. Given no annotations, this makes the tool risky for an AI agent to invoke without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents both parameters (issue_key and comment_id). The description adds no additional meaning or context beyond what the schema already provides, which meets the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a comment' clearly states the action (delete) and the resource (comment), making the tool's purpose easy to understand. It distinguishes from sibling comment tools like add_comment or update_comment, though it doesn't explicitly differentiate comment types (e.g., issue vs. entity comments).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or scenarios where another tool (e.g., delete_entity_comment) would be more appropriate. The usage is only implicitly understood from the name and description.
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 fails to mention that deletion is likely permanent, any cascading effects (e.g., the with_board option), required permissions, or the impact on associated data. The single sentence is purely functional with no 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 sentence with no filler words, front-loading the core purpose effectively. Every word contributes meaning, making it highly concise and appropriately structured for a simple delete operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool performs an irreversible action and includes a significant optional parameter (with_board) that affects behavior, yet the description provides no context about side effects, usage scenarios, or consequences. Although an output schema exists, the behavioral context is missing, making the description incomplete for an agent to safely invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds no parameter-specific meaning beyond the schema, but the schema already documents entity_id, entity_type, and with_board with sufficient clarity, so no deduction is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the target resources ('project, portfolio, or goal'), which distinguishes it from sibling delete tools like delete_macro or delete_board. However, it is brief and does not elaborate on the scope or any exclusions, so it stops short of a fully exceptional purpose statement.
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, nor any mention of when not to use it. The description only implies usage through the resource types, and no alternative tools are referenced, leaving the agent to infer context from the parameter schema.
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 disclose behavioral traits. It indicates deletion but does not explain consequences like irreversibility, permission requirements, or the directed nature of the link (based on the 'right' parameter). This adds little beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant content. It is appropriately sized for a simple delete operation and front-loads the action verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's apparent simplicity, the description is too minimal to convey the full semantics of deleting an entity link (e.g., directionality, impact on the entity, or relation to other link tools). With no annotations and an output schema not described, the agent is left with insufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description provides no additional meaning beyond what the schema already documents for the three parameters; it does not compensate with extra context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete) and the target (a link from an entity), which aligns with the tool name. However, it does not explicitly differentiate this from sibling tools like delete_link or delete_external_link, though the entity-specific context is implied by the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as create_entity_link or delete_link. The description only states the action without context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavior. It only says 'Get autoaction details' without explaining return values, potential errors, or whether permissions are required. For a getter, the read-only nature is implied but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. It is not overlong, though it veers toward being too sparse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, full schema coverage, and an output schema), the one-line description is minimally adequate. However, it lacks any guidance on selection or behavior, so it doesn't feel fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers both parameters ('queue' and 'autoaction_id') with descriptions. The tool description adds no additional meaning beyond the schema, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'get' and the resource 'autoaction details', clearly indicating a read operation. It is distinct from sibling tools like 'list_autoactions' and 'create_autoaction', though it doesn't explicitly differentiate itself from 'get_autoaction_logs'.
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 list_autoactions or get_autoaction_logs. The description lacks any context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavioral traits. However, 'Get macro details' only restates the tool name and does not disclose whether the operation is read-only, any permission requirements, or side effects. It adds no behavioral context beyond what the name implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no unnecessary words, earning its place by stating the tool's purpose. It is appropriately terse, though it sacrifices informational richness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has a simple two-parameter schema and an output schema, the description is minimally adequate but fails to note the dependency on a queue key or how this differs from related macro tools. It lacks context that would help an agent understand the tool's role within the broader macro management workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters (queue with 'Queue key' and macro_id with 'Macro ID') at 100% coverage. The description does not add any additional meaning, syntax, or format details beyond the schema, so it meets the baseline but provides no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get macro details' clearly identifies the action (get) and resource (macro), distinguishing it from sibling tools like list_macros, create_macro, update_macro, and delete_macro. It is concise and unambiguous, though it doesn't elaborate on the specific scope or return content beyond '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 information about when to use this tool versus alternatives such as list_macros or get_macro with different parameters. There is no mention of prerequisites, exclusions, or alternative tool recommendations, leaving the agent without guidance on 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, but it only states 'Get queue details.' It does not mention read-only behavior explicitly, output format options, expansion behavior, or any potential side effects or permissions. While the verb 'get' implies a read operation, the description lacks substantive behavioral context (e.g., whether the queue_key must exist, what happens on missing keys, or how output_format affects results).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It is front-loaded with the key action and resource. However, it is so brief that it borders on under-specification, but for conciseness alone, it earns a 4 rather than a 5 due to lack of informative content.
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 4 parameters, no annotations, and the large set of sibling tools, a three-word description is insufficient. It does not explain what 'details' include, how the expansion parameter works, or how this tool relates to queue_overview or list_queues. An output schema exists, but the description still fails to provide adequate context for an agent to confidently use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all four parameters (expand, queue_key, output_format, full_description) already documented in the schema. The description adds no additional parameter context, but since the schema already fully covers parameters, a baseline of 3 is appropriate.
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 queue details' uses a specific verb ('Get') and resource ('queue details'), making the primary function clear. It is distinct from siblings like list_queues and get_queue_user_permissions, though it does not explicitly differentiate from potential overlaps like queue_overview. The word 'details' is somewhat vague but acceptable.
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 related tools (e.g., list_queues for listing, queue_overview for a broader view) or any prerequisites. There is no explicit or implicit context that helps an agent choose this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only says 'list all boards' and does not mention caching behavior (use_cache), output format options, pagination, or data volume implications. The schema hints at these but the description adds no behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence, front-loaded with the core action. There is zero wasted text. However, it is so brief that it borders on underspecification, though for a simple list operation this level of brevity is acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are covered elsewhere. The description is minimal but adequate for a basic list operation. However, with no annotations and no mention of caching or output format, there are clear gaps in context, especially since the schema reveals parameters that imply more complex behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, and the schema clearly documents each parameter with descriptions. The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all boards, using a specific verb and resource. It distinguishes from sibling tools like get_board (single board) and list_board_columns by implying a collection of all boards, though it does not explicitly mention alternatives. The scope of 'all boards' is a bit ambiguous but acceptable.
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 lacks any context about whether this should be used for browsing, exporting, or as a precursor to other board-specific operations. There are no exclusions or alternative tool mentions.
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 says 'List fields,' implying a read operation, but does not mention caching behavior (use_cache parameter), output format, side effects, or what 'local fields' means in practice. The phrase 'including local fields' adds a small amount of context but is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words, directly stating the purpose. It is well-structured and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a clear one-liner and complete schema coverage, the description lacks context about how the 'fields' parameter interacts with the returned list and what 'local fields' entails. The tool has 4 parameters, and the description does not help the agent understand their combined behavior or typical use cases, making it incomplete for effective selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for all parameters (queue_key, fields, use_cache, output_format), so the schema carries the parameter semantics. The description adds no additional meaning beyond the schema, earning the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists fields of a queue, specifically including local fields, which conveys a specific verb+resource+scope. It does not explicitly distinguish itself from sibling tools like get_queue or list_global_fields, but the resource and scope are clear enough to differentiate it.
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 get_queue, list_global_fields, or list_field_categories. There is no mention of when to prefer this tool or any exclusions, 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?
No annotations are provided, so the description must carry the full burden, but it only states the basic action. It does not disclose caching behavior implied by the use_cache parameter, response format behavior, error handling, or what happens if the queue does not exist. This is a minimal read operation, but the description adds no behavioral detail beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words. However, it is somewhat terse, lacking any explanatory phrase to aid selection among siblings.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one required parameter and an output schema, so a minimal description can be adequate. Yet with no annotations and no usage guidance, and sibling tools that could be confused with this one, the description is only minimally complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 3 parameters are already documented in the schema with descriptions (100% coverage), so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and identifies the resource as 'tags used in a queue', which clearly indicates a read operation on queue tags. However, it does not explicitly distinguish this from sibling tools like list_queue_fields or delete_queue_tag, so it falls just short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description is purely declarative and lacks context about use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the purpose and does not reveal important behaviors such as whether all sprints are returned, caching implications (despite a use_cache parameter), response format default, or any limitations. This falls short of providing meaningful transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single sentence that clearly states the core operation. It is front-loaded and free of filler, though it may be too brief to fully support the tool's moderately complex parameter set.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and full parameter schema coverage, the description is minimally adequate. However, it lacks contextual details such as what constitutes a 'sprint', whether the list is filtered by state, or how to leverage optional parameters. For a listing tool, this is acceptable but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional parameter semantics; it merely states the overall function. Parameters like fields, use_cache, and output_format are documented in the schema, so the description provides no extra value here.
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 'List sprints of a board' uses a specific verb and resource, clearly indicating the tool lists sprints associated with a board. It distinguishes from sibling tools like list_boards and create_sprint by focusing on sprints, though it does not explicitly contrast with alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description offers only a terse purpose, lacking any mention of use cases, prerequisites, or complementary/exclusionary tools. Siblings like get_board or list_boards are not referenced.
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 behavioral transparency burden. It does not disclose any side effects, permissions requirements, or confirmation behavior. It only states a generic 'update' action without context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. It is front-loaded and easy to parse, though it may be too minimal to convey additional context beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema and a well-covered input schema, so return values and parameter details are already handled elsewhere. However, for a mutation tool with no annotations, the missing usage context and behavioral details make the description incomplete for an agent deciding when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameter descriptions, including details like 'New text', 'Mark as checked/unchecked', and 'New assignee login'. The description itself adds no extra parameter context, but the schema already provides sufficient semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a checklist item' clearly identifies the action and target resource. However, it does not distinguish this from the sibling tool 'update_entity_checklist_item', so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like add_checklist_item, delete_checklist_item, or update_entity_checklist_item. The description only states what it does, not 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.
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 'Update an existing component' without explaining whether updates are partial, destructive, require permissions, or have side effects. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. While extremely brief, it effectively conveys the core purpose without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, the description lacks essential context about partial updates, effects, or safety. The output schema exists and parameters are documented, but behavioral context is missing, leaving the description 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 input schema fully describes all five parameters with individual descriptions, so the tool description adds no extra meaning. Baseline is 3 due to high schema coverage (100%).
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 operation ('Update') and the target resource ('existing component'), which distinguishes it from create_component and get_component. However, it doesn't elaborate on what aspects can be updated, making it slightly less informative than ideal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like create_component or get_component. There are no prerequisites, exclusions, or context indicating appropriate scenarios for use.
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 provide safety profile, and the description only says 'Update,' which implies mutation. It doesn't disclose partial-update behavior, null semantics, permission requirements, or effects on related fields. The parameter names hint at these, but the description itself carries the burden and fails to elaborate.
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?
Single sentence, front-loaded, no fluff. It is concise but perhaps too terse for a 16-parameter mutation tool; still, it earns high marks for brevity.
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 complex mutation tool with no annotations and many optional fields, a one-line description is insufficient. It doesn't discuss update semantics, which fields can be combined, or special behaviors. Output schema exists, so return format doesn't need explanation, but usage context is still missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all 16 parameters have descriptions), so baseline is 3. The tool description adds no parameter-level detail beyond what schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') and resource ('a project, portfolio, or goal'), clearly identifying the affected entity types. However, it doesn't distinguish this tool from related entity mutators like update_entity_settings or update_entity_metrics, so purpose is clear but sibling differentiation is weak.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like update_issue or update_entity_settings. No exclusions or prerequisites. Only the generic capability is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure, but it provides none. It doesn't state whether key results are replaced or merged, whether changes are reversible, or what permissions are required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff, earning high marks for efficiency. However, it is under-specified given the tool's complexity and lack of annotations, so it doesn't achieve 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?
Without annotations and with an output schema that exists, the description still fails to provide behavioral context, usage scenarios, or side effects. It is too minimal for a mutation tool that updates nested items.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters have descriptions in the schema. The description adds no extra meaning beyond that, but the baseline of 3 applies because the schema already handles parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the specific resource ('key results of a goal'), distinguishing it from generic sibling tools like update_entity. However, it doesn't elaborate on what key results are or how they are structured.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like update_entity or update_entity_metrics. It doesn't mention prerequisites, exclusions, or related workflows, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only states 'Update a worklog entry' without explaining whether the update replaces the entry, which fields are affected, if changes are reversible, or any permission requirements. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with zero fluff, making it concise and readable. However, it is so brief that it sacrifices necessary contextual information, though the conciseness itself is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having seven parameters, a rich schema, an output schema, and multiple sibling worklog tools, the description offers no additional context about return values, update semantics, or how it fits into the broader worklog workflow. It is too minimal to fully support tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all seven parameters with meaningful descriptions (e.g., 'New duration in ISO 8601'). The tool description adds no extra parameter semantics, but the schema's thorough documentation meets the baseline for this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Update' and a clear resource 'worklog entry', which distinguishes it from sibling worklog tools like add_worklog, delete_worklog, list_worklog, and search_worklog. However, it lacks detail about what aspects of the worklog can be updated (e.g., comment, duration), so it is clear but not fully 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 such as add_worklog or delete_worklog. It does not mention prerequisites, use cases, or exclusions, leaving the agent to infer the tool's role solely from its name and sibling context.
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 merely restates the operation without explaining key semantics like atomicity, partial success handling, permission requirements, or whether the specified values are applied uniformly to all issues. 'At once' is ambiguous and could mislead about transactional guarantees.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence, front-loaded with the action and resource. There is no redundant wording or unnecessary structure, making it maximally concise while conveying the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (bulk operation, nested values object, output schema) and lack of annotations, the description is insufficient. It does not explain the semantics of bulk updates (e.g., whether all issues get the same values, what happens on partial failure), and while the output schema covers return values, the description omits essential behavioral context that an agent needs to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, including the meaning of 'issues' and 'values' with examples. The description adds no parameter details, but per the rubric, a baseline of 3 is appropriate when the schema already documents all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a bulk update on multiple issues in a single action, using the specific verb 'bulk update' and the resource 'issues.' This distinguishes it from single-issue tools like 'update_issue' and entity-focused bulk tools like 'bulk_update_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 provides no explicit guidance on when to use this tool versus alternatives. It does not mention that it is the recommended choice for updating multiple issues at once, nor does it exclude loops over 'update_issue' or clarify trade-offs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It mentions 'Force sync from API,' implying a side effect of overwriting or updating directories, but does not describe what 'force' means (e.g., ignoring incremental sync, potential data loss, or locking 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 a single, front-loaded sentence that gets straight to the point. It is concise and appropriate for a no-parameter tool, though the phrase 'basic directories' could have been expanded without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and the operational nature of this tool, the description is incomplete. It does not explain what 'basic directories' are, what 'Force' does in practice (e.g., cache invalidation or blocking), or the shape of the output, despite having an output schema.
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 is empty with zero parameters, so the baseline is 4. No parameter descriptions are needed, and the description appropriately adds no unnecessary parameter information.
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 (sync) and scope (all basic directories), distinguishing it from the sibling 'sync_directory' via the 'all' modifier. However, the term 'basic directories' is domain-specific and not defined, leaving some 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 explicit guidance is provided on when to use this tool against alternatives like sync_directory or configure_cache. The word 'Force' implies immediate manual action, but no context is given about typical usage 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?
No annotations are provided, placing the burden on the description. The description only states 'Count issues matching a query' and does not disclose whether the operation is read-only, whether it has pagination limits, or what occurs when the query is null. For a tool that counts, this missing context leaves the agent uncertain about behavior beyond the trivial reading of 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 a single concise sentence with no wasted words. It directly states the tool's function and is appropriately scoped for the tool's simplicity. There is 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?
The tool is simple, has an output schema, and fully documented parameters, so the description does not need to explain return values. However, it omits useful context such as how the 'query' parameter behaves when null (i.e., counts all issues?), and it does not reference sibling tools for comparison. Given the low complexity, a 3 is 'minimum viable' but with clear gaps in usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already well-documented in the input schema. The description adds no parameter-level information beyond what the schema provides. It gives an example query string, but this is part of the schema description. The baseline of 3 is appropriate because the schema carries the full weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Count') and resource ('issues') and states the scope ('matching a query'). It is clear and not a tautology. However, it does not explicitly distinguish itself from sibling tools like 'search_issues', which may also operate on matching 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. It does not state that it should be used instead of 'search_issues' when only a count is needed, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 the action 'Create a new component' without revealing any side effects, required permissions, or consequences. It does not mention whether the component is immediately visible, if creation can be undone, or any other behavioral traits beyond the bare verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that states the core purpose without any wasted words. It is appropriately sized for a simple creation tool, though it lacks any additional structured context (e.g., usage examples or note sections). It is not verbose, but it is also not maximally informative.
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 there are 5 parameters, an output schema, and no annotations, the description is insufficiently complete. It does not provide any behavioral context, usage guidelines, or return value expectations. The existence of an output schema covers return values, but the description remains minimal and does not help the agent understand the full scope of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all five parameters have descriptions in the schema). The tool description adds no additional parameter information, but per the rubric, a high schema coverage sets the baseline at 3. The description does not hinder understanding but also does not compensate for anything missing.
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 'Create a new component' uses a specific verb ('Create') and resource ('component'), clearly distinguishing it from sibling tools like update_component (which modifies) or list_components (which lists). The action is unambiguous and directly matches the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical scenarios, or any exclusions. Sibling tools such as update_component or list_components exist, but the description offers no comparison or context to help an agent choose correctly.
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. It doesn't mention whether this is a read-only operation (though it's implied), nor does it describe any behavioral traits such as pagination, filtering, or return format. The description adds little beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has minimal complexity, and the schema fully documents parameters. However, the description lacks any note about how autoaction logs relate to similar tools like get_trigger_logs, so an agent might not know which log type to query.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the schema ('Queue key' and 'Autoaction ID'), providing complete coverage. The tool description adds no further meaning to the parameters, so it relies on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get autoaction execution logs' uses a specific verb and resource, clearly distinguishing this from sibling tools like get_autoaction or list_autoactions. However, it doesn't elaborate on what constitutes execution logs, so it's clear but not highly detailed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_trigger_logs. The description simply states the function without any context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure, but it only restates the operation. It does not mention response format (text vs json), truncation behavior via full_description, or any other side effects or limitations.
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: 'Get board details.' It contains no filler or redundant information, achieving high clarity in minimal 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?
The tool is simple, has a complete schema, and an output schema is present, which reduces the need to explain return values. However, the description alone does not provide enough context for an agent to know when to choose this over siblings or what output behavior to expect, making it minimally viable but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage for board_id, output_format, and full_description, so the schema does the heavy lifting. The description adds no additional semantic context about how these parameters affect behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('board details'), clearly indicating a retrieval operation. It distinguishes from sibling list_boards by implying single-board retrieval, but it does not explicitly differentiate itself or mention what 'details' encompasses.
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 like list_boards, update_board, or delete_board. The intent to fetch board details is implied by the name and description, but there are no explicit context cues 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 provided, the description carries the full burden of behavioral disclosure, but it only states the basic action. It does not mention that this is a read-only operation, how status is represented, possible outcomes, or error conditions. The lack of additional context leaves the agent uncertain about the operation's behavior beyond the minimal action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no redundant information. It is appropriately concise and front-loaded, making it easy for an agent to quickly understand the tool's core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description is minimally viable. However, it lacks context about how this tool fits into the bulk operation workflow, such as when to use it after bulk_update/bulk_move/bulk_transition. The absence of usage context relative to the large sibling set makes it less complete than ideal.
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 no parameter information, but the input schema has 100% description coverage. Both 'bulk_change_id' and 'output_format' have clear, self-explanatory descriptions in the schema, so the baseline of 3 applies. The description does not need to compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Check the status of a bulk operation' clearly identifies the action (check) and the resource (status of a bulk operation). It distinguishes itself from siblings like get_bulk_failed_issues, which focuses on failed issues rather than overall operation status. The purpose is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. The schema parameter description mentions 'from bulk_update/bulk_move/bulk_transition', which hints at usage context, but the description itself offers no such direction. There is no discussion of prerequisites, alternatives, or 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Get' implies a read-only operation, but the description adds no details about permissions, response structure, or side effects. It is minimal and adds no context beyond the verb.
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, complete sentence with no wasted words. It is front-loaded and effectively conveys the tool's 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?
The tool has an output schema and clearly named parameters, but the description leaves ambiguity about what 'team member' means in this context and lacks usage guidance. It is adequate for a simple getter, but does not go beyond the minimum.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both parameters have descriptions), so the baseline is 3. The description does not add any parameter information beyond what the schema provides, so no additional credit is warranted.
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 indicates a read operation for a specific resource ('team member details'), using a specific verb 'Get'. It distinguishes from siblings like 'list_team' (list all) and 'get_user' (generic user), though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_user or list_team. There is no mention of prerequisites, target audience, 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 provided, the description carries the full burden of disclosing behavioral traits. It only states 'Get trigger execution logs', mentioning nothing about returned data, ordering, pagination, permissions, rate limits, or any side effects. Given the simplicity of a read operation, the description adds minimal 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, concise sentence that immediately states the tool's purpose. There is no unnecessary wording or redundancy. It is appropriately sized for a straightforward getter tool, earning a perfect score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple input schema with 100% parameter coverage and an output schema available, so the description does not need to explain return values. However, the description lacks any context about what 'execution logs' contain, how they are filtered (beyond the parameters), or any limitations. It is minimally viable but leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with each parameter having a clear description ('Queue key', 'Filter by issue key', 'Trigger ID'). The tool description adds no additional semantic value to the parameters, but the baseline of 3 applies because the schema already documents them fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a specific resource ('trigger execution logs'), clearly distinguishing it from sibling tools like get_trigger (which retrieves trigger configuration) and get_autoaction_logs (which retrieves logs for autoactions). It doesn't explicitly compare itself to these siblings, but the resource name itself provides sufficient differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. It simply states the action, leaving the agent to infer usage from the parameter names and sibling context. No explicit 'when to use' or 'when not to use' is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavior. It only says 'Get info,' implying a read operation, but it does not mention any permissions required, data sensitivity, or response structure. This lack of behavioral context is a significant gap, even for a simple getter.
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 directly states the tool's purpose without redundant details. It is appropriately sized for the tool's simplicity and front-loaded with the key action and target.
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 (2 params, one required) and presence of an output schema, the description is minimally viable. However, it lacks usage guidance and behavioral transparency, which are especially important because no annotations exist. The description is adequate but leaves clear gaps for an AI agent deciding between this and similar user-related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for both parameters (user_id and output_format) with 100% coverage. The description adds no extra meaning beyond what the schema already states, so it meets the baseline for well-documented parameters but does not enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get info about a specific user' uses a clear verb ('Get') and resource ('a specific user'), making the purpose immediately understandable. It distinguishes from broader list tools by emphasizing 'specific user,' but it does not explicitly differentiate from siblings like get_myself or list_users, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It neither states explicit use cases nor mentions when not to use it, despite a rich set of sibling tools (e.g., get_myself, list_users, get_team_member) that could easily be confused with this one.
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 burden of behavioral disclosure. It only states 'List all field categories,' which implies a read-only operation but fails to disclose the use_cache behavior (a parameter in the schema) or any side effects. The tool's caching behavior and output format defaults are not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff or redundancy. Every word earns its place, making it exceptionally concise 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 description is adequate for a simple list operation, especially with a full output schema and parameter descriptors. However, it lacks context about what 'field categories' actually are, and it omits any caveats about caching or output format that would help an agent use it correctly. The information is minimally sufficient but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptions for both parameters (use_cache and output_format). The description adds no additional parameter semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all field categories' clearly specifies the verb (list) and resource (field categories), making the tool's purpose unambiguous. However, it does not explicitly distinguish itself from sibling tools like list_queue_fields or list_global_fields, so it misses the highest rating.
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, nor any context about the intended use case. The description gives no mention of prerequisites, exclusions, or scenarios where other tools might be more appropriate.
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. The text 'Remove a task preset' simply restates the tool's function and adds no context about consequences (e.g., irreversibility), error conditions, or side effects. It offers zero information beyond what the tool name already implies, failing to disclose any meaningful 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no filler words, which is concise. However, it is also highly redundant with the tool name and adds no valuable context, so it does not really 'earn its place'. It is neither overly verbose nor sufficiently informative, landing at an average score.
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 delete operation with one required parameter, and the schema fully documents that parameter. However, the complete lack of annotations and behavioral details (e.g., whether deletion is permanent, failure modes) leaves the agent with limited context. It is minimally viable but not rich enough to warrant a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (preset_name is fully documented in the schema), so the baseline is 3. The description itself does not add information about the parameter beyond what the schema already provides. The schema's 'Preset key to remove (from list_presets)' is already self-explanatory.
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 'Remove a task preset' uses a specific verb ('remove') and a clear resource ('task preset'), which unambiguously distinguishes it from sibling tools like add_preset, list_presets, and get_preset. The action is immediately understandable and aligns with the tool name without being a mere tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. However, the parameter description 'Preset key to remove (from list_presets)' implies a prerequisite: the user should first call list_presets to obtain the key. This is an implied usage hint but lacks explicit exclusions or alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden of behavioral disclosure. 'Manually sync' implies a state-changing operation with potential data overwriting, but no side effects, permissions, rate limits, or impact considerations are mentioned. The description is too thin to convey the operational risks.
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 single sentence is concise, front-loaded with the primary action, and avoids redundancy. It earns its place by stating the tool's core purpose, though it lacks supplementary details that would make it more helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a simple schema and existing output schema, the description omits essential operational context. It fails to explain what syncing does, whether it is destructive, when to use it, or how it relates to sync_all_directories. This leaves significant gaps for an agent to safely invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with clear descriptions for both parameters, including examples for 'directory' and a note for 'scope'. The description adds no additional parameter semantics beyond what the schema already offers, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (sync), the resource (a specific directory), and the source (from API). It directly distinguishes itself from the sibling 'sync_all_directories' by emphasizing 'specific', making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like sync_all_directories. There is no mention of prerequisites, exclusions, or scenarios where this tool is preferred. The context is purely implied by the tool's name and description.
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 the core action and fails to mention effects (e.g., whether a checklist is auto-created), error conditions, or any state changes beyond adding an item.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no redundant words. It is front-loaded and immediately states the tool's purpose, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and fully documented parameters, the description lacks usage context and behavioral caveats. For a mutation tool with no annotations, this minimal description is insufficient for an agent to understand when to use it or what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter detail, but the schema already documents each parameter clearly (text, checked, assignee, deadline, issue_key). No additional semantics are needed.
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 'Add a checklist item to an issue' clearly states the specific verb (Add), resource (checklist item), and target (issue). It is distinct from sibling tools like add_entity_checklist_item (which targets entities) and update/delete/list checklist operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., add_entity_checklist_item). There are no prerequisites or exclusions mentioned. Usage is only implied by the name, not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavior independently. It does not explain whether updating overwrites the entire preset or merges fields, nor does it mention any permission requirements or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of a single, clear sentence with no filler words. It is highly concise and immediately communicates the tool's 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 the schema and output schema cover parameters and return values, the description fails to explain the add/update distinction—whether it inserts or replaces an existing preset. Crucial operational context is missing, making the tool difficult to use correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 7 parameters are fully described in the schema, including examples for 'params' and a note about supported fields from create_issue. The tool description adds no additional parameter information beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds or updates a task preset, using a specific verb and resource. This distinguishes it from sibling tools such as create_from_preset (which creates an issue from a preset) and remove_preset.
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 like create_from_preset or when to avoid it. It does not mention any prerequisites or conditions under which an update occurs versus an add.
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 only states the core action (adding a worklog) with no mention of side effects, authentication requirements, or behavior around optional fields like comment or output_format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the key action and target, no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 7 parameters and being a mutation operation, the description provides only the bare action. It lacks context on when to use it, format intricacies, or expected side effects. The output schema exists but does not compensate for missing behavioral guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 7 parameters. The description adds no parameter information, but baseline 3 applies because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Add' and resource 'worklog entry' with target 'issue', clearly distinguishing it from sibling tools like update_worklog, delete_worklog, list_worklog, and search_worklog.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives such as update_worklog or search_worklog. No exclusions, prerequisites, or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden, but it only states the basic creation action and a field-reference tip. It does not disclose side effects, permissions, or behavior beyond creating the autoaction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the primary purpose and followed by a practical tip. 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?
The schema covers all parameters and an output schema exists, but the description lacks usage guidance and does not explain the structure of action dicts. The tip is helpful but insufficient for full context on constructing a valid autoaction.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value with the tip about using {{issue.local.<field_key>}} in action templates, which clarifies how to use the 'actions' parameter beyond the schema's generic 'List of action dicts'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Create an autoaction in a queue' with a specific verb and resource. It does not differentiate from sibling tools like create_macro or create_trigger, but the resource is uniquely identified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as create_macro or create_trigger. The description only mentions a template tip, which is not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention side effects, required permissions, idempotency, or what happens on success/failure. The description only states the core action without any additional 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, clear sentence with no unnecessary words. It is front-loaded and communicates the essential purpose with maximum efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the schema covers parameters and an output schema exists, the description lacks usage guidance and behavioral transparency. For a create operation with no annotations, more context is needed to ensure the agent selects and invokes the tool correctly in ambiguous situations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all 5 parameters (100% coverage), including defaults and requirements. The tool description adds no extra meaning beyond what is already in the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action: 'Create a cycle time widget on a dashboard.' It uses a specific verb ('Create'), a specific resource ('cycle time widget'), and a location ('on a dashboard'), making it clear and distinct from sibling create tools like create_dashboard or create_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?
The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. It merely states the function, leaving the agent to infer usage context from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only indicates a creation operation but fails to mention side effects, permissions, reversibility, duplicate handling, or the meaning of an external link, leaving significant behavioral context unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently communicates the core action, making it appropriately sized for a simple creation tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters and an output schema, the description is too sparse. It doesn't explain relationship values, how origin relates to external applications, or how to use the backlink parameter, leaving the agent without essential context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter already described (e.g., issue_key, relationship, origin, key, backlink). The description adds no parameter-specific meaning beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create an external link on an issue' uses a specific verb (create), resource (external link), and target (issue), clearly distinguishing it from sibling tools like delete_external_link and list_external_links.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as link_issues (for issue-to-issue links) or how to obtain valid origin/key values. The description only states what it does, not when 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, the description carries the full burden of behavioral disclosure, but it only says 'Create an issue from a preset template.' It does not mention required permissions, whether overrides are validated, side effects, or the return value. This is minimal and insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It is front-loaded and achieves high efficiency, making every word earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 params, nested objects, output schema) and lack of annotations, the description is too sparse. It fails to explain what a preset template is, how to choose one, or how this tool relates to create_issue, leaving significant gaps for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage of all parameters, so the baseline is 3. The description adds no additional meaning about the parameters, such as the relationship between input_values and template placeholders, but the schema descriptions already handle parameter semantics well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create), the resource (an issue), and the method (from a preset template), which distinguishes it from the sibling create_issue tool that creates an issue directly. This is a specific verb+resource phrasing with explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like create_issue, how to obtain preset names, or any prerequisites. It simply states what it does without offering usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. However, it only states the action ('create a new issue') without mentioning side effects, required permissions, or return behavior. It does not add value beyond what the tool's name 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 a single, direct sentence with no redundant or extraneous content. It is appropriately front-loaded and wastes no words, maximizing 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 18 parameters, no annotations, and a one-sentence description, the tool lacks sufficient context for an agent to know when or how to invoke it effectively. The output schema exists, but the description does not address required fields, use cases, or integration with other tools, making it incomplete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 18 parameters, so the baseline is 3. The description does not add any parameter semantics beyond the schema, but it does not need to since the schema fully documents each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Create a new issue in Yandex Tracker.' This uses a specific verb ('create') and resource ('issue'), and distinguishes it from sibling tools like update_issue, search_issues, and delete_macro by focusing on the creation 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, such as import_issue or create_from_preset. It lacks any context about prerequisites, typical use cases, or conditions under which another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the behavioral disclosure burden. It only states 'Create a new version' without mentioning side effects, permissions, whether versions are immutable, or how the version state is managed. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, focused sentence directly conveys the operation with no filler or redundancy. It is well-front-loaded 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?
Despite having an output schema, the description is too sparse for a create operation requiring a queue_key and multiple optional parameters. It gives no context about queue relationships, constraints, or invocation semantics, leaving the agent to infer from parameter names alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema documents all 5 parameters with descriptions, achieving 100% coverage, so the baseline is 3. The description adds no extra meaning beyond what the schema already provides, but it does not need to compensate for missing schema info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and clear resource ('a new version for a queue'), distinguishing it from related tools like create_queue or list_queue_versions. It unambiguously states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as create_queue or list_queue_versions. No context about prerequisites, typical scenarios, or when to avoid using it is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The tip about local field references is useful, but it does not mention side effects, permissions, or the automation nature of trigger creation. The description fails to disclose important behavioral aspects of the 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: one sentence for purpose and one sentence for an actionable tip. It avoids any wasted words and is well-structured for quick consumption.
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 schema and output schema provide structural detail, but the description lacks important domain context such as the relationship between triggers and autoactions, how conditions are evaluated, or prerequisites. The tip is helpful but does not fully compensate for the missing conceptual guidance.
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 fully described in the schema (100% coverage), so the baseline is 3. The description adds value by providing a concrete example of how to use local field references within the 'actions' and 'conditions' parameters, which goes beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation (Create) and the resource (a trigger in a queue). It distinguishes itself from siblings like list_triggers and update_trigger by focusing on creation, but does not explicitly differentiate from create_autoaction, leaving some ambiguity about when to use each.
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 this tool should be used relative to alternatives such as update_trigger or create_autoaction. The description only states what it does, leaving the agent without contextual cues for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It merely states the action ('Delete an attachment') without disclosing whether deletion is permanent, requires special permissions, or has side effects—important context for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no unnecessary words. It is appropriately concise 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?
Despite being a simple delete operation, the description is under-specified for a destructive tool. It lacks details on permanence, prerequisites, differentiation from sibling tools, and any caveats, leaving significant gaps especially since no annotations 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 input schema describes all three required parameters (entity_type, entity_id, file_id) with clear descriptions. The tool description adds no parameter-level detail beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Delete), resource (attachment), and scope (from a project, portfolio, or goal). This distinguishes it from similar sibling tools like delete_attachment by naming the specific entity types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance is provided. The description implies usage for attachments on the listed entity types but does not contrast it with the similarly named delete_attachment or other delete 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?
With no annotations, the description carries the full burden of behavioral disclosure. While 'Delete' implies destruction, the description does not state whether the deletion is permanent, whether it cascades to associated data, or what happens if the macro does not exist. The added context 'from a queue' clarifies scope but not side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is immediately understandable. Every word earns its place; no verbose or redundant content. This is an example of efficient, front-loaded prose.
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 destructive operation with no annotations and no output schema details, the description is insufficient. It fails to mention that deletion is permanent, whether confirmation is required, or the outcome of deleting a nonexistent macro. The tool is simple, but the missing behavioral details leave a material gap for an agent deciding to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%—both parameters ('queue' and 'macro_id') are individually described. The description adds no extra semantics beyond restating that the macro is deleted from a queue. Baseline 3 applies because the schema already handles parameter explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and identifies the resource ('a macro') plus the scope ('from a queue'), clearly distinguishing it from sibling tools like get_macro, create_macro, and update_macro. It leaves no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 simply states the action without mentioning any prerequisites, conditions, or exclusions. An agent must infer from the name and context 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. The description only states the basic purpose with no disclosure of behavior such as response format control, description truncation, or that it may expand nested fields. It adds no context beyond the schema already provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-front-loaded sentence that directly states the tool's purpose. Every word earns its place, and there is no waste or redundant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a rich schema and output schema, the description is bare-bones. It lacks any context about when to use this tool among the many issue-related siblings, and it does not mention key behaviors like truncation, output format choices, or the expand parameter. An agent would need to inspect the schema carefully to understand the full scope, but the description itself is insufficient for effective selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema achieves 100% coverage with clear descriptions for all 5 parameters, so the description need not reiterate them. The baseline of 3 applies because the schema already handles parameter semantics, and the description adds no additional meaning beyond what the schema states.
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 'issue details' with the identifier 'by key'. This uniquely differentiates it from siblings like search_issues or list issues, and leaves no ambiguity about what the tool accomplishes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as search_issues, issue_overview, or entity-related tools. The description provides no context for when it should be preferred, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states the basic action and preservation of original metadata, which is already evident from the schema parameters. It does not disclose side effects, idempotency, error behavior, or authentication needs. Since no annotations are provided, this is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no unnecessary words. The core action is front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks context about prerequisites, typical usage scenarios, or error conditions. With no annotations and 5 required parameters, the description is too minimal for a tool likely used in migration/import workflows.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with clear descriptions for all five parameters. The description's phrase 'original timestamp and author' reinforces created_at and created_by but does not add meaningful new information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Import'), the resource ('file attachment'), and a distinguishing detail ('with original timestamp and author'). This separates it from sibling import tools like import_issue, import_comment, and import_link.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No mention of when to choose import_file over import_issue, import_comment, or attachment management tools like list_attachments. The description is purely declarative.
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, but it only states the core function. It omits important behaviors such as caching behavior, pagination, and output format defaults, which are only partially hinted at in the parameter schema. This is a significant gap 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 a single, efficient sentence with no wasted words. It conveys the core purpose clearly and is appropriately sized for a straightforward list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having a rich schema and output schema, the description lacks context about pagination, caching behavior, or how results are returned. It does not explicitly state that it lists all users, and it fails to address important operational details that would help an agent use the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, so the schema already provides the needed semantics. The description adds no parameter-level detail, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List organization users' uses a specific verb 'list' and resource 'organization users', making it clear what the tool does. It is distinct from sibling tools like get_user (which retrieves a single user) and list_team (which lists team members), so 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?
No guidance is provided on when to use this tool versus alternatives like get_user or find_assignee. The description does not mention any exclusions or prerequisites, leaving the agent without direction on choosing this tool over similar list/get options.
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 only states 'List worklog entries' without disclosing behavior such as pagination, default field selection, or performance characteristics. The read-only nature is implied but not explicit, and potential side effects are not addressed.
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, compact sentence with no filler or redundant information. It is front-loaded and easy to parse, achieving maximum 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?
Despite having an output schema and three parameters, the description is too sparse to be fully contextual. It omits details about result limiting, default field behavior, and its relationship to search_worklog, leaving the agent without a complete picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for issue_key, fields, and output_format. The description adds no parameter-specific context beyond the literal list action, warranting the baseline score for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('List') and the resource ('worklog entries for an issue'). It is unambiguous and distinguishes from mutation siblings like add_worklog/update_worklog, as well as broader search_worklog.
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 search_worklog or other list tools. There are no stated alternatives, exclusions, or contextual hints about when this is the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It implies a read operation via 'Get' but says nothing about side effects, output structure, or potential limitations. The mention of 'overview' is vague, and no additional behavioral context is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the verb and resource. It has no redundant or filler words, making it exceptionally concise.
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 overview tool with a complete schema and output schema, the description covers the core purpose and expected results. However, it lacks usage context relative to sibling tools, which slightly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: both queue_key and output_format are fully described in the input schema. The description adds no extra meaning to the parameters, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get an overview of a queue' with specific outputs ('open issues count, top priority issues'). It uses a specific verb+resource and is easy to understand, but does not explicitly differentiate from sibling tools like get_queue or issue_overview.
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_queue, count_issues, or issue_overview. The agent must infer usage context from the description alone, which lacks any exclusions or alternative-noting language.
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 behavioral disclosure burden. It only says 'Update' without explaining whether metric_items replaces existing metrics, whether specific permissions are needed, how partial updates are handled, or any side effects on the entity. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. It is as concise as possible while conveying the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and full parameter descriptions, this is a write operation with no annotations. The description omits critical operational details such as whether metric_items is a full replacement or a merge, the expected item structure, and any entity-type-specific behavior. An agent would need to guess or make assumptions to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already provides basic descriptions for all parameters. The description adds no extra semantic detail beyond what the schema states, particularly about the structure of metric_items or valid values for entity_type beyond the schema's enum-like text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Update') and resource ('metrics'), scoped to project, portfolio, or goal. This clearly distinguishes it from siblings like update_entity or update_entity_settings, which target different attributes.
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 only states what the tool does, with no guidance on when to choose it over alternatives (e.g., update_entity, update_key_results), no prerequisites, and no exclusions. Usage is merely implied by the tool's name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the action ('Update access settings') but does not disclose side effects, whether settings are replaced or merged, required permissions, or the potentially destructive nature of changing access controls. 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, focused sentence that immediately states the action and target. It is front-loaded, easy to parse, and contains no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having complete parameter schemas and an output schema, the description lacks critical behavioral context for a security-sensitive mutation tool. It does not explain whether the update is additive or replaces existing settings, what permissions are required, or what impact it has on users. This makes the description inadequate 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 schema provides descriptions for all four parameters, so the baseline is 3. The description adds no additional meaning beyond grouping acl and permission_sources as 'access settings', which is already evident from the parameter names. It does not enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') and resource ('access settings'), and explicitly lists the supported entity types (project, portfolio, goal). This clearly differentiates it from sibling tools like update_entity (general entity fields) and get_entity_settings (retrieval).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or scenarios where this tool is preferred over update_entity or other permission-related tools. Usage is only implied by the description, 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, and the description does not disclose behavioral traits beyond the basic action. It omits information about permissions, whether the comment is created immediately, or any side effects, which is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It directly states the tool's purpose without fluff, which is appropriate for a simple add operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and does not mention optional parameters like summonees or full_description, nor does it explain when to use this tool. However, the schema covers all parameters and an output schema exists, so the core operation is clear. It lacks behavioral context, but overall it's minimally complete for a straightforward action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is fully described (100% coverage) with parameter descriptions for issue_key, text, fields, summonees, output_format, and full_description. The description adds no additional parameter semantics, but the schema is sufficient, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Add') and resource ('comment to an issue'), clearly distinguishing from siblings like update_comment, delete_comment, and add_entity_comment by specifying the target as an 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?
Provides no guidance on when to use this tool versus alternatives such as add_entity_comment or import_comment. It simply names the action, leaving the agent to infer context from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits, but it only states the basic action. It does not mention required permissions, error handling, or effects on existing checklist items. 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?
A single, well-structured sentence that is front-loaded with the action and resource. No fluff, every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Though concise, the description is adequate for an add operation with comprehensive schema and an output schema. However, it could be more complete by mentioning that it operates on entity checklists or provides an example, especially given the existence of similar tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with descriptions for all six parameters, so the description does not need to repeat them. However, it adds no additional context beyond the schema, such as how entity_type and entity_id relate or the format of deadline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and the resource ('checklist item'), and further specifies the valid target types ('project, portfolio, or goal'), which directly maps to the entity_type parameter. This distinguishes it from sibling tools like 'add_checklist_item' (which likely targets issues) and update/delete variants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'add_checklist_item' or 'update_entity_checklist_item'. The description implies usage through the verb and target types, but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It only states the action without revealing side effects, whether the operation is immediate, persistent, requires special permissions, or affects existing cache entries. For a configuration tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that quickly conveys the tool's purpose. It contains no redundant information and is appropriately sizeable for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has only two parameters with full schema descriptions and an output schema exists, the description is mostly adequate. However, the lack of annotations and behavioral details (e.g., effects of setting TTL to 0, whether changes persist, or authorization requirements) leaves some gaps for a configuration operation. The simplicity of the tool prevents a lower score, but it could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with descriptions for both parameters (ttl and directory), so the baseline is 3. The description itself does not add additional meaning beyond what the schema already provides, but it does not need to since the schema is 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 'Configure TTL (Time To Live) for a specific directory cache' uses a specific verb ('configure') and a clear resource (TTL for a directory cache). It distinguishes itself from sibling tools like get_cache_status and sync_directory by focusing specifically on TTL configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or alternative approaches. The usage context is only implied by the tool name and description, but no explicit direction is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action 'Delete' but does not mention whether deletion is permanent, if cascading effects occur, what permissions are required, or how errors are handled. For a destructive operation, this lack of context is a significant gap, resulting in a score of 2.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 11 words, direct and free of fluff. It front-loads the action and scope, making it immediately understandable. Every word earns its place, with no unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 required params, full schema coverage, and an output schema), the description is minimally viable but lacks guidance on behavioral aspects like permanent deletion and permission requirements. The parameter schema covers the inputs well, but the description does not add enough contextual detail to fully inform the agent, especially considering the sibling tools that add ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the baseline is 3. The description repeats the entity_type values ('project, portfolio, or goal') already present in the schema, adding no new semantic meaning beyond what the structured parameter descriptions provide. It does not explain the relationship between item_id and entity_id, so no bonus is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete a checklist item') and specifies the applicable scope ('from a project, portfolio, or goal'), which differentiates it from the generic sibling `delete_checklist_item`. It is specific and uses a clear verb+resource+scope pattern, but it does not explicitly name the alternative, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for entity-associated checklist items by naming project, portfolio, and goal. However, it provides no explicit guidance on when to choose this tool over the sibling `delete_checklist_item` or any exclusions. The context is present but not fully spelled out, so it earns a 3 for implied rather than explicit 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 disclose behavioral traits on its own. It only states the deletion action and does not mention whether the deletion is permanent, requires permissions, affects external applications, or what errors/response to expect. For a destructive tool this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or repetition. It efficiently conveys the tool's core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool itself is simple with two well-documented parameters and an output schema, so the description doesn't need to explain return values. However, it lacks usage alternatives and behavioral caveats, making it minimally adequate rather than fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters have clear descriptions ('External link ID', 'Issue key'), so the schema carries the semantic weight. The description adds no parameter-specific details, hence the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and resource ('external link from an issue'), clearly distinguishing it from general link deletion tools like delete_link or delete_entity_link. It states exactly what is removed and the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as delete_link or list_external_links/create_external_link. It also does not mention prerequisites, such as whether the link must exist or whether the issue must be accessible.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It only states the action without mentioning destructive consequences, permission requirements, reversibility, or any impact on the queue. The presence of restore_queue in siblings hints at possible restore options, but nothing is 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 a single, clear sentence with no unnecessary words. It is perfectly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, return values need not be explained. However, for a destructive tool with no annotations, the description lacks behavioral context such as whether the deletion is reversible, what happens to associated data, or any prerequisites. It is minimally viable but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters with descriptions 'Queue key' and 'Tag name', but these are minimal. The tool description adds no additional meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a tag from a queue' clearly states the verb and resource, distinguishing it from sibling tools like delete_queue (which deletes the whole queue) and other delete_* tools. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, no prerequisites, and no context about when it is appropriate or inappropriate. It simply restates the action implied by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It merely states the action 'Delete' without mentioning irreversibility, permission requirements, or consequences of failure. The destructive nature is implied by the verb but not elaborated, so transparency is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately conveys the tool's purpose. It contains no redundant or wasted words, making it highly concise. While it is brief, it earns its place for such a straightforward operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimally viable given the low complexity and complete schema. However, for a destructive operation, it would benefit from noting that the deletion is permanent or that appropriate permissions are required. The output schema covers return details, but behavioral context is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (issue_key and worklog_id) clearly described. The tool description adds no additional parameter semantics, so the baseline of 3 applies per the rubric.
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 entry." uses a specific verb (delete) and resource (worklog entry), clearly distinguishing it from sibling worklog tools like add_worklog, update_worklog, and list_worklog. It is concise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that this is for removing a specific logged time entry, nor does it contrast with update_worklog or search_worklog. Given the sibling context, explicit usage direction is lacking.
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 behavior disclosure. It states a read operation ('Get') but does not specify permissions, whether the operation has side effects, error conditions, or the format of the response. The addition of output_format in schema suggests customizable output, but the description does not acknowledge this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately states the tool's purpose. There is no redundant information or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the output schema likely covers return values, the description lacks contextual guidance about when to invoke this tool, such as after a bulk_update/bulk_move/bulk_transition. It also does not mention the output_format parameter, though the schema covers it. The one-liner is adequate but leaves the agent to infer the operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents both parameters: bulk_change_id is described as 'Bulk operation ID' and output_format explains its text/json options. The description adds no additional meaning beyond the schema, so it relies on the schema's coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and clearly identifies the resource as 'issues that failed in a bulk operation.' This distinguishes it from sibling tools like get_bulk_status and bulk_update, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of pairing with bulk operations or that get_bulk_status should be used for overall status, nor any exclusions. Usage is only implied by the word 'bulk operation.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. However, it only restates the tool's function without detailing side effects, pagination behavior, filtering capabilities, or output format. It does not contradict annotations, but it adds minimal context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tight sentence that immediately conveys the tool's purpose without unnecessary words. It is front-loaded and concise, with no filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a rich schema (100% parameter coverage) and an output schema, so the return values and parameters are documented. However, the description lacks usage guidance and does not clarify how this tool relates to entity_changelog or get_issue. It is minimally viable but leaves contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all four parameters, including field, per_page, issue_key, and output_format. The description adds no parameter-level semantics, but with complete schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get issue changelog' with a parenthetical definition 'history of changes,' making the verb and resource explicit. It distinguishes itself from siblings like get_issue and entity_changelog by focusing specifically on issue changelog history.
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. There is no mention of exclusions or when to prefer entity_changelog or get_issue, 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, the description carries the full burden for behavioral disclosure. It does not mention any side effects, error handling, pagination, or required permissions. The only implied behavior is that it is a read-only operation, which is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence, front-loaded and free of any unnecessary words. It is optimally concise for the simplicity of the tool.
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 the description need not explain return values. However, it lacks guidance on parameter nuances or alternatives, and with no annotations it leaves some behavioral uncertainty. It is minimally adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters (issue_key and output_format) with descriptions, so schema coverage is 100%. The description adds no additional semantic value beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and the resource (attachments of an issue). It is specific enough to distinguish from sibling tools like list_entity_attachments, which target entities rather than 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?
The description gives no guidance on when to use this tool versus alternatives (e.g., list_entity_attachments for entities) or any exclusions. It only provides a minimal statement of function with no 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?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only says 'List columns of a board.' It does not mention output format behavior, pagination, side effects, or any other behavioral traits. This is minimal at best.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler or redundancy. It is perfectly concise and well-structured for the simple purpose it serves.
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 an output schema exists to define return values. However, the description lacks usage context and behavioral detail, making it adequate but with clear gaps for an agent needing to decide when and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both board_id and output_format already documented in the schema. The description adds no extra context about parameters, so it meets the baseline but does not enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List columns of a board' uses a specific verb (list) and a clear resource (columns of a board), effectively distinguishing it from sibling tools like list_boards or get_board. It is unambiguous and directly states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusion criteria. It simply states the action without any contextual advice, leaving the agent to infer usage from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states 'List all comments' and does not mention ordering, pagination, depth (e.g., top-level vs. nested), permissions, or any other behavioral traits. As a read operation, it is implicitly non-destructive, but the description adds no context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It efficiently captures the core purpose and earns its place without any filler or unnecessary elaboration.
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, has an output schema, and all parameters are documented. However, the description is minimal and does not mention potential nuances such as whether comments include threaded replies, how results are ordered, or any rate limits. It is adequate but leaves some contextual gaps, particularly around behavioral details that could affect agent expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full documentation for all three parameters (issue_key, fields, output_format) with descriptions and defaults, achieving 100% schema coverage. The tool description itself adds no parameter-related meaning, but the baseline of 3 applies since the schema carries the semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all comments on an issue.' clearly states the action (list), the resource (comments), and the scope (on an issue). It is distinct from sibling tools like add_comment, update_comment, and delete_comment, and also from list_entity_comments, which targets entities rather than 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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that this is for issue comments specifically, nor does it reference related tools such as list_entity_comments or add_comment. The context of sibling tool names helps imply usage, but the description itself offers no exclusions or alternative directions.
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 must carry the full burden of disclosing behavior. It only states that it lists components and provides no information about read-only status, caching implications, pagination, or potential side effects. The 'use_cache' parameter's behavior is also not explained in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action and resource. Every word earns its place; no extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description is adequate but minimal. It covers the core purpose but lacks details about the output schema's contents, potential large response sizes, or when to consider using optional parameters. The presence of an output schema mitigates the need to explain return values, but more context would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has excellent coverage (100%) with descriptions for all three parameters (fields, use_cache, output_format), so the description itself adds no additional parameter semantics. The baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with a concrete resource 'components' and scope 'in the organization,' clearly distinguishing it from sibling tools like get_component, create_component, and update_component.
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_component for a single component or search_entities for filtered searches. The description only states the core functionality.
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. The description does not mention caching behavior, auth requirements, rate limits, or any side effects, and it ignores the use_cache parameter which directly affects behavior. This is a significant gap for a tool that may use local caching.
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 short sentence that immediately states the action and scope, with no unnecessary words. It is well-structured 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?
Given the tool's simple nature, an output schema exists, and the schema already documents both parameters, the one-sentence description is arguably sufficient for basic invocation. However, it lacks any context about caching implications or differentiation from similar listing tools, so an agent might not fully understand when this tool is the best choice or how use_cache affects results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for both parameters, with clear descriptions for use_cache and output_format. As per the rubric, the baseline is 3 because the schema handles parameter meaning well, and the description adds no additional value beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and the resource (all issue types in the organization), making it easy to understand what the tool does. However, it does not explicitly distinguish itself from sibling listing tools such as list_statuses or list_field_categories, so it misses the top score for sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to retrieve all issue types, which gives a basic sense of when to use it. It does not provide explicit alternatives, exclusions, or context about when to prefer this over other list_* tools, leaving guidance minimal but not misleading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for revealing behavioral traits. It does not disclose caching behavior, pagination, or output format options, all of which are present in the schema. This leaves key behavioral nuances unmentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and front-loaded. It avoids unnecessary words and fully conveys the tool's primary purpose with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the schema and output schema enrich the context, the description lacks important behavioral context such as default caching and pagination. It is minimally adequate but leaves gaps that the schema only partially fills.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all four parameters, providing detailed semantics. The tool description adds no extra meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all available queues.' uses a specific verb and resource, clearly stating its function. It distinguishes from siblings like get_queue, create_queue, and list_queue_fields by focusing on listing queues themselves.
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_queue or list_queue_fields. There is no mention of use cases or exclusions, leaving the agent to infer appropriate usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention caching behavior, output format implications, pagination, permissions, or response details. The schema includes use_cache and output_format, but the description adds no context about their effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is clear and to the point, with no unnecessary words. It is appropriately sized for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 well-documented parameters and an output schema. The description covers the core function, but lacks details about behavioral aspects like caching and output format effects. It is adequate but leaves some gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters, with use_cache and output_format having explicit descriptions and defaults. The description adds no additional meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with a clear resource 'issue resolutions' and scope 'in the organization'. This clearly distinguishes it from sibling tools like list_issue_types or list_statuses by naming the specific entity.
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 any exclusions, alternatives, or intended use cases beyond the basic 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?
No annotations are present, so the description carries full burden. It only states the basic action without disclosing output format, pagination, field details, or any side effects. The optional output_format parameter is not mentioned in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single clear sentence with no filler, front-loaded with the verb and resource. Every word contributes to the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter) and presence of an output schema, the description is minimally adequate. However, it lacks usage guidance and any behavioral context, leaving the agent without hints about when to choose this over related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter (output_format) is fully described in the schema (100% coverage), so the description adds no additional meaning. The baseline of 3 applies because the schema handles parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('team members from the team directory'), clearly distinguishing it from sibling tools like get_team_member (single member) and list_users (all users).
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 find_assignee or get_team_member. There is no mention of context, exclusions, or prerequisites.
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 behavioral transparency burden. It only states 'Get,' implying read-only, but does not disclose error behavior, authorization needs, or potential side effects. It adds no 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 a single, front-loaded sentence with no unnecessary words. It is appropriately sized for a simple get-by-ID operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple 2-parameter tool, full schema descriptions, and an output schema, the description plus schema provides enough information for an agent to invoke the tool correctly. It lacks usage and behavioral context, but the core invocation details are covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters, including a default for output_format, so the baseline is 3. The description does not add further parameter meaning, but it is not necessary given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and clearly identifies the resource as 'a saved filter by ID.' This distinguishes it from sibling tools like create_filter and update_filter, and the 'by ID' scope makes the operation precise.
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 like get_preset or list filters. There is no mention of exclusions, prerequisites, or when it should be preferred over other retrieval 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?
With no annotations provided, the description carries the full burden of disclosing behavior. It only states the action ('get') without explaining return values, required permissions for the caller, error handling (e.g., user not found), or any side effects. This is a significant gap for a tool with no structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no redundant words or filler. It front-loads the core purpose without wasting space, making it highly concise 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?
Despite having an output schema and full parameter descriptions, the description lacks contextual completeness. It does not clarify what 'permissions' entails (e.g., list of strings vs. structured objects), nor does it mention the output_format parameter's behavior or any prerequisites. For a tool with no annotations and a broader permission domain, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all three parameters (100% coverage), so the description does not need to add parameter explanations. The description itself adds no additional meaning beyond the schema, earning the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and identifies a clear resource ('user permissions for a queue'). It distinguishes the tool from siblings like 'get_queue' (queue metadata) and 'update_queue_permissions' (modifying permissions).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing user permissions for a queue, but it does not explicitly state when to use it over alternatives or provide any exclusions. There is no mention of alternatives, prerequisites, or context, so guidance is only inferred from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description is the only behavioral disclosure, yet it only mentions the timestamp attribute. It does not disclose whether the import is additive, idempotent, permission-scoped, or how conflicts or duplicate links are handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, and the key differentiator ('original timestamp') is front-loaded. It is maximally concise, although this brevity trades off behavioral detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 required parameters, zero annotations, and no usage context, the single-sentence description is insufficient for an import/mutation tool. It omits validation semantics, conflict handling, and return behavior; the existence of an output schema does not compensate for the missing operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with meaningful descriptions (source/target keys, relationship, created_at, created_by), so the schema carries the semantic burden. The description adds no parameter-level nuance beyond saying 'original timestamp'.
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 ('Import') and resource ('link between issues') plus a distinguishing constraint ('original timestamp'). This clearly differentiates it from the sibling tool 'link_issues', which presumably creates a link with the current timestamp.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance is provided. The word 'Import' and 'original timestamp' imply a migration/backfill context, but the description does not contrast with link_issues, list_links, or other import tools, nor does it state prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Create' implies mutation, but there is no mention of permissions, duplicate-link behavior, relationship direction semantics, or what happens after creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant information. It efficiently communicates the core function.
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 fully described schema and the presence of an output schema, the minimal description is largely sufficient for a simple creation tool. It lacks behavioral and usage context, but the structured data covers parameter semantics well enough to make the description adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes all four parameters, including the relationship enum values and output_format. The description adds no additional parameter meaning beyond the schema, but since schema coverage is 100%, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action and resource: 'Create a link between two issues.' It distinguishes this tool from sibling link-related tools by scoping it to issue links, not entity links or external links.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like create_entity_link or create_external_link. The description does not mention exclusions, prerequisites, or context in which this tool should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full transparency burden. It only states the action, without disclosing behavioral details like default output format, whether all items are returned, or any ordering. The verb 'List' implies read-only but adds no depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence of seven words. It is front-loaded with the action verb and contains 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?
The tool is simple and the description captures the core purpose. Since an output schema exists and parameters are documented, the description need not explain return details. It lacks only usage guidance, but for a straightforward list operation it is adequately 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?
Both parameters are fully described in the input schema (issue_key with an example, output_format with default and allowed values). The description adds no additional parameter semantics, so it meets the baseline for schema coverage of 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List checklist items of an issue' uses a specific verb and resource, clearly indicating the tool's function. It distinguishes itself from sibling tools like add/update/delete_checklist_item by focusing purely on listing items for an 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?
The description provides no context about when to use this tool versus alternatives such as list_entity_checklist_items or other listing tools. It does not mention any exclusions or specific use cases beyond the basic 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?
No annotations are provided, and the description is a bare listing statement. It discloses no side effects (e.g., being read-only), data scope, permission requirements, or return format details beyond the output_format parameter. With no annotation support, the description fails to convey important 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 clear sentence, front-loaded with the verb 'List', and contains zero filler or redundant phrasing. It is appropriately concise for a simple listing tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has an output schema, and the only parameter is fully described in the schema, so the description need not explain return values. The phrase 'registered for issue linking' adds useful context. However, the lack of annotations and absence of any extra usage context mean a small gap remains, but for a list operation the description is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, output_format, is fully documented in the input schema (100% coverage). The description adds no extra semantics about parameter usage, but the schema already handles it adequately, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description specifies 'List external applications registered for issue linking' – a clear verb ('List') and resource ('external applications') with purpose qualifier. This distinguishes it from sibling list_external_links, which focuses on links themselves rather than registered applications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance or mention of alternatives is provided. The description does not explain when to use this tool instead of list_external_links or other listing tools, leaving the agent to infer its 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, the description carries the full burden and provides minimal behavioral disclosure. It does not explicitly state that this is a read-only operation, mention any permissions required, or describe the default output format beyond what the schema already indicates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states exactly what the tool does without any redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with well-documented parameters and an output schema, the description is largely sufficient. A minor gap is the lack of clarification on how external links differ from the sibling 'list_links', but this does not critically impair understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes both parameters with 100% coverage, so the description adds no additional semantic information. It appropriately sits at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('external links of an issue'). It differentiates from sibling tools like 'list_links' by explicitly specifying 'external'.
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 over alternatives. There is no mention of how it differs from 'list_links' or when one might prefer external links over all links.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states the basic operation and fails to mention that this is a read-only action, caching behavior, response format, or any potential side effects or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with zero filler, front-loaded with the action and resource. It is perfectly concise for a simple listing tool and all words contribute meaningful 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 straightforward read-only nature of the tool, the description is largely sufficient. The input schema thoroughly documents parameters and the presence of an output schema covers return values. The only gap is a lack of any caveat about potentially large result sets, but this is a minor omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 even without parameter details in the description. The description adds no parameter information, but the input schema thoroughly documents each parameter, including examples and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and clearly identifies the resource as 'global issue fields', which distinguishes it from sibling tools like list_field_categories or list_queue_fields. It unambiguously states the tool's function without 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. The description implies a read-only listing operation but gives no context about when 'global issue fields' is the appropriate scope, nor does it mention any exclusions or alternative 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 that it lists statuses, but does not mention caching behavior, output format, or any side effects, leaving uncertainties about freshness and response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that is immediately informative. It wastes no words and front-loads 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 simplicity of the tool, the existence of an output schema, and full parameter descriptions, the description is sufficient for basic understanding. However, it could provide a bit more context about default caching or when to use the JSON output format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides complete descriptions for both parameters (use_cache and output_format), achieving 100% coverage. The tool description adds no additional meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list), the resource (issue statuses), and the scope (organization). It is concise and easily distinguishes from sibling tools like list_issue_types or list_priorities.
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_issue_types or list_resolutions. It merely states what it does, leaving the agent to infer the use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only says 'Update an existing board,' which implies mutation but provides no detail on side effects, permissions, partial update behavior, or error conditions. The output schema exists but does not compensate for missing behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly-worded sentence with no redundant information. It is front-loaded and efficient, earning every word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update operation with a complete schema and output schema, the description suffices. It correctly identifies the resource and action. Minor gaps like clarifying that only provided fields are updated prevent a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters (name, board_id, backlog_available, sprints_available) with descriptions. The description adds no additional parameter context, but the baseline of 3 is appropriate given complete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing board.' clearly states a specific verb ('update') and resource ('board'), distinguishing it from sibling tools like create_board, delete_board, and get_board. It is unambiguous and concise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as create_board or update_issue. There is no mention of prerequisites, context, or exclusions, leaving the agent to infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for disclosing behavioral traits. It only restates the action without mentioning irreversibility, required permissions, notification behavior, or how optional params like 'notify' and 'move_all_fields' affect the operation. 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, front-loaded sentence with no wasted words. It efficiently states the core action and destination, making it easy for an agent to parse and understand the tool's primary 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?
The presence of an output schema and full parameter descriptions covers return values and parameter semantics. However, the description omits usage guidance and behavioral context, leaving the agent with insufficient information to distinguish this from similar bulk operations or to anticipate side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter meanings are fully documented in the schema. The description adds no additional semantic value beyond what the schema already provides, such as examples or cross-parameter 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 action (move), the resource (issues), and the target (another queue). It distinguishes from sibling tools like bulk_transition (status change) and move_issue (single issue move) by specifying 'bulk' and 'queue'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the 'bulk' keyword and 'another queue' destination, but no explicit alternatives or when-not-to-use guidance is provided. It does not reference the sibling move_issue for single-issue moves, leaving the agent to infer the scope.
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 itself. It says only 'Bulk transition issues to a new status' and gives no information about partial failures, permission requirements, validation, or whether the operation is atomic. For a mutation tool, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant words, making it highly concise and well-structured. It is slightly under-specified, but this is a conciseness dimension, not a completeness dimension.
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 (bulk operation with optional notifications and field updates) and lack of annotations, the description is insufficient. It does not mention how 'bulk' affects behavior, what happens if some issues fail, or how this differs from single transition tools. An output schema exists, but that does not compensate for missing usage and 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?
Schema description coverage is 100%—all four parameters (issues, notify, values, transition) have descriptions in the input schema. The tool description adds no additional semantic meaning beyond the schema, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'transition' with the resource 'issues' and the scope 'bulk', clearly distinguishing it from sibling tool transition_issue which handles single issues. It unambiguously states 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 word 'Bulk' provides clear contextual guidance that this tool is for transitioning multiple issues at once. However, it does not explicitly name alternatives or exclude single-issue transitions, stopping short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'Create' and does not mention side effects, permission requirements, validation, or response behavior. For a mutation tool with 15 parameters, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It front-loads the core purpose and is 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 that an output schema exists and all parameters are fully documented in the schema, the description is minimally viable by naming the three entity types. However, with 15 optional parameters and no annotations, more high-level context about the entity creation workflow would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter details beyond what the schema already provides; the entity type values are already documented in the entity_type property.
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 'Create' and clearly enumerates the resource scope: 'project, portfolio, or goal.' This distinguishes the tool from sibling creation tools like create_issue, create_queue, or create_sprint.
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 creating a project, portfolio, or goal—but does not explicitly mention alternatives, exclusions, or prerequisites. It relies on the reader to infer that other entity types should be handled by other create_* 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?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It does not mention side effects, permissions, or whether creation may overwrite existing macros, leaving the agent without important safety 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 concise, with the primary purpose stated up front and a single, useful tip that adds practical value. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create tool with four parameters and an output schema, the description is adequate but lacks context about prerequisites like queue existence or potential overwrite behavior. The tip partially compensates, but important behavioral context remains missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes each parameter at 100% coverage, but the description adds a valuable tip about using {{issue.local.<field_key>}} in the body. This goes beyond the schema's generic body description and helps the agent format the parameter correctly.
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 macro in a queue' with a specific verb and resource. This distinguishes the create action from sibling tools like update_macro, delete_macro, and get_macro.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The tip about referencing local fields is useful but pertains to parameter usage, not tool selection 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 carries the full burden of behavioral disclosure. It only restates the action (delete an attachment) without addressing permanence, permissions, or side effects. As a destructive operation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is a single sentence with no redundant words, making it exceptionally concise and easily skimmable. It efficiently states the action and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and relies on the schema for parameter details and an output schema for return values, but it does not compensate for the missing annotations by mentioning the destructive, irreversible nature of deletion or any required permissions. For a mutation tool with no annotations, this is a notable gap, though the core operation is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents both parameters with descriptions (issue_key format and attachment_id source). The description adds no additional parameter semantics, so a baseline score of 3 is appropriate given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Delete' and identifies the resource 'attachment' with scope 'from an issue', clearly distinguishing it from sibling tools like delete_entity_attachment and list_attachments. It is a precise statement of the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for deleting issue attachments but does not explicitly state when to use it versus alternatives (e.g., delete_entity_attachment for entity attachments) or mention that list_attachments provides the attachment ID. No prerequisites or exclusions are provided, leaving usage guidance implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It states the destructive nature but fails to mention whether deletion is permanent, if it affects related data, or any permission requirements. For a delete operation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant wording. It is concise and front-loaded, delivering the core purpose immediately.
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 one-parameter delete tool, the description is minimally adequate. It states the action and target, but lacks guidance on usage context and behavioral details. The presence of an output schema reduces the need to explain return values, so the description is sufficient for a basic understanding but not comprehensive.
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 single parameter 'issue_key' is fully described in the schema with an example, and the description does not add any further meaning. With 100% schema coverage, the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete'), the resource ('entire checklist'), and the scope ('from an issue'). This distinguishes it from sibling tools like delete_checklist_item, which targets a single item.
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 deleting an entire checklist but provides no explicit guidance on when to choose this over alternatives (e.g., delete_checklist_item) or any prerequisites. 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. It only states the action, with no mention of permissions, irreversibility, potential side effects, or error conditions. This leaves the agent without important behavioral context 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?
A single, front-loaded sentence with no filler. It efficiently communicates the tool's purpose without 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 deletion tool with a complete schema and output schema, the description is minimally adequate. However, the absence of behavioral notes (e.g., deletion is permanent, requires certain permissions) and lack of annotations leave gaps that a more thorough description could fill.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents both parameters with clear descriptions (item_id, issue_key), achieving 100% schema description coverage. The description adds no extra parameter-level meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the specific resource ('a single checklist item'), distinguishing it from sibling tools like delete_checklist (which removes an entire checklist) and update_checklist_item.
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 context implies this tool is used when you need to remove one item from a checklist, but it does not explicitly state when not to use it or mention alternatives like delete_checklist for whole-list deletion. The guidance is minimal but not misleading.
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 bears the full burden of behavioral disclosure. It only says 'Get changelog' without revealing read-only nature, pagination behavior, output format details, or content of changelog entries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single well-structured sentence with no filler. It is front-loaded with the action verb and immediately specifies the target resource.
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 output schema and full parameter documentation make the description minimally adequate, but the lack of behavioral context (e.g., read-only, pagination) and absence of usage differentiation leave gaps. Given no annotations, more detail would be expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The tool description adds no parameter semantics beyond mentioning the entity types already described in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('changelog of a project, portfolio, or goal'), clearly stating the tool's scope. It also implicitly distinguishes itself from the sibling 'issue_changelog' by naming non-issue entity types.
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 project/portfolio/goal changelogs but does not explicitly contrast with 'issue_changelog' or other tools. No when-to-use or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. While 'Get' implies a read operation, the description provides no detail on error behavior, auth requirements, or any side effects. It does not add context beyond the verb and resource.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence, front-loaded with the action and resource. Every word earns its place with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (get-by-ID) and an output schema exists, so the description need not explain return values. However, it lacks any context about optional parameters like fields or full_description, and does not clarify when these might be used. For a 5-parameter tool, it is minimally 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?
Schema coverage is 100%, so parameters are already well-documented. The description does not add extra semantics beyond the schema; it simply restates the purpose of entity_id/entity_type. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('project, portfolio, or goal') with an explicit lookup mechanism ('by ID'). This clearly distinguishes it from sibling tools like search_entities or create_entity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (fetch a single entity when you have an ID) but does not explicitly state when to prefer this over search_entities or provide exclusions. It offers no comparison to alternatives, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of explaining behavior. It mentions preserving original timestamp and author, but omits details about permissions, idempotency, side effects on issue timelines, validation of author existence, or error handling. The schema provides some constraints (e.g., created_at interval), but the description adds little beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the core purpose with no filler. It is front-loaded and every word contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema and parameter descriptions provide strong structural context, so the minimal description is acceptable for basic invocation. However, given the presence of the sibling add_comment, more explicit guidance on when to use import_comment would improve completeness. Behavioral gaps (e.g., permissions) also reduce the overall contextual richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already explains each parameter's meaning, including the date constraint. The description adds no new parameter semantics but is not required to compensate given excellent schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Import') and the resource ('a comment'), and the phrase 'with original timestamp and author' distinguishes this from sibling tools like add_comment, which creates a new comment with current metadata. The verb and object are immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when preserving the original timestamp and author is required, but it does not explicitly state when to choose this over add_comment or mention any exclusions. No alternatives are named, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. The verb 'list' clearly implies a read-only operation, and the phrase 'of a queue' adds scoping context. However, it does not disclose behaviors such as error handling for nonexistent queues, pagination, or ordering, so it is minimally transparent but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently communicates the operation and scope. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple one-parameter list operation and an output schema exists, so return-value documentation is not needed. However, the description offers no context on when to choose this over other list_ siblings, making it adequate yet lacking full contextual guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single 'queue' parameter with an example. The description adds no further semantic detail beyond what the schema already documents, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and the resource 'autoactions' with the scope filter 'of a queue'. This clearly identifies the tool's function and distinguishes it from siblings like get_autoaction (singular) and create_autoaction (creation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_autoaction or list_triggers. The description only states the operation, leaving the context of use entirely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states 'List versions of a queue' without disclosing return format, pagination, or potential side effects. Since it's a read operation, the read-only nature is implied, but no behavioral detail is added.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is maximally concise while remaining clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description isn't required to explain return values. However, the description provides no context about what a 'version' is, how versions relate to queues, or when to use output_format. It's adequate for a simple tool but misses enrichment opportunities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, including defaults. The description does not add extra semantics beyond referencing the queue_key, but the schema already provides sufficient context, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (List) and resource (versions of a queue), clearly distinguishing it from sibling tools like get_queue or list_queues. It unambiguously states 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 queue versions) but provides no explicit when-to-use guidance or exclusions. It doesn't mention alternatives or prerequisites, though the sibling create_queue_version hints at 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 only states the basic action and provides no details about the nature of the operation (e.g., read-only, permissions required, pagination, whether inactive triggers are included). This is a significant gap for a list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler words. It is appropriately sized for a simple tool with one parameter, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple and has an output schema (which presumably documents the return structure), the description lacks any contextual guidance on behavior, permissions, or edge cases. It is minimally sufficient but leaves clear gaps, such as what constitutes a 'trigger' in this context and any operational constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full coverage for the single parameter 'queue' with a clear example. The description adds no additional meaning beyond what the schema states, so the baseline of 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List triggers of a queue' uses a specific verb and resource, clearly distinguishing this tool from related siblings like get_trigger (single trigger) and create_trigger/update_trigger. It unambiguously states its 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 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 list triggers for a queue) but provides no explicit guidance on when to choose this over alternatives or when not to use it. It lacks direct exclusions or references to sibling tools, so it only meets the 'implied usage' criterion.
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 fails to disclose side effects, failure conditions (e.g., queue already exists), permissions, or whether associated data is restored. As a mutating operation, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no redundancy. It earns its place, though there is room to add useful behavioral context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and only a terse one-sentence description, important context is missing: what 'restore' entails, whether it is idempotent, and what happens to existing data. The output schema helps with return values, but the description remains incomplete for safe autonomous invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents queue_key with 100% coverage and an example. The description adds no additional meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Restore') on a specific resource ('previously deleted queue'), clearly distinguishing it from related siblings like create_queue and delete_queue. It is unambiguous and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'previously deleted' implies the appropriate use case: after a queue has been deleted and needs to be brought back. It does not explicitly mention alternatives or when not to use it, but the intended context is clear enough for this simple tool.
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 for behavioral disclosure, but it only states the basic search action and provides no context about read-only safety, date handling, pagination, or result format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. Every word contributes to conveying the tool's 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?
The description is minimally adequate for a simple search tool, and the schema fills in filter details. However, it lacks guidance on edge cases, ordering, and how it differs from list_worklog, so completeness is moderate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter has a clear description. The tool description adds no additional parameter meaning beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('search') on a resource ('worklog entries') with a scope ('across all issues'), which distinguishes it from per-issue worklog tools like list_worklog.
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 use when needing to search worklogs globally, but it does not explicitly mention alternatives or when not to use this tool, leaving the agent to infer context from sibling names.
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 'Delete a comment' without mentioning permanence, permissions, or side effects. For a destructive operation, this lacks important context about consequences or requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to meaning, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with three parameters and an output schema, the description adequately covers the purpose and scope. It does not need to explain return values due to the output schema, and the entity types are explicitly listed. Minor gaps exist around permissions or impact, but the tool is simple enough that the description is largely 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?
Schema description coverage is 100%, so the baseline is 3. The description's mention of 'project, portfolio, or goal' maps to entity_type, but the schema already enumerates those values. It adds no meaningful additional semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete) and the resource (comment), with an explicit scope: 'from a project, portfolio, or goal.' This distinguishes it from the sibling delete_comment tool, which likely targets issue comments, by specifying the entity types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for comments on projects/portfolios/goals, but it does not explicitly mention alternatives or exclusions, such as 'use delete_comment for issue comments.' It provides context but no direct guidance on when to choose this tool over related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states the basic function without mentioning return cardinality (single vs. list), matching semantics, or read-only safety. This adds little 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 a single sentence of 10 words, concise and front-loaded with the primary action, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (per context), return values are covered. The tool is simple with optional parameters well-documented in the schema. The description is minimal but adequate for basic use, though it could clarify whether results are singular or multiple.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptive parameter definitions (e.g., area keyword examples). The description adds minimal meaning by linking area to expertise and queue, but this is already implied by the schema, so it does not significantly elevate understanding beyond baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action (Find) and resource (team member), and adds search criteria (area of expertise or queue), distinguishing it from siblings like list_team or get_team_member.
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 finding a team member by expertise or queue, but provides no explicit guidance on when to use this versus alternatives like list_team or get_team_member, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, yet the description does not disclose whether this is a read-only operation, any caching behavior (despite a use_cache parameter), or what 'detailed information' includes. The description solely restates the purpose without 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, front-loaded sentence with no redundant words. It is appropriately concise for a simple getter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and only three parameters fully described in the schema, the description is sufficient for a getter. It lacks some behavioral details (e.g., caching) but these are covered by the schema and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no extra meaning beyond 'by ID', which maps to the required component_id parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('component'), and specifies scoping ('by ID'). This distinguishes it from sibling list_components and create_component tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: you need a component ID to fetch a single component. However, there is no explicit guidance on when to prefer this over list_components or other getters, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description itself must convey behavior. 'List' implies a read-only operation, but it does not disclose pagination, ordering, handling of invalid queue keys, or what exactly is returned. This is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that leads with the action and clearly names the resource and scope. There is no superfluous information, making it appropriately concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with one parameter and an output schema, so the description does not need to explain return values. It adequately states the action and scope, though it could explicitly mention 'all macros' or note that a valid queue is required, but these are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a description for the only parameter ('Queue key (e.g. "DEV")'), covering 100% of parameters. The description's phrase 'of a queue' merely echoes the schema and adds no additional meaning beyond it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and identifies the resource as 'macros' scoped to 'a queue'. This clearly distinguishes it from sibling tools like get_macro, which would retrieve a single macro, and create_macro/update_macro/delete_macro.
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 get_macro (for a specific macro) or the other macro-related tools. It only states what it does without giving context, exclusions, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It implies a read-only listing operation and mentions that descriptions are included, but does not disclose potential pagination, sorting, or scope limitations. The simplicity of the tool mitigates this, but richer behavioral context would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is appropriately front-loaded with the action and resource.
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 operation with an output schema and only one optional parameter, the description is largely sufficient. It could mention that this lists all presets available to the user, but the provided information is adequate given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides full coverage (100%) for the single parameter output_format, including its default and allowed values. The description adds no additional meaning about this parameter, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('available task presets'), and clarifies the scope ('with their descriptions'), distinguishing it from siblings like get_preset (single preset) and add_preset/remove_preset (management).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_preset, create_from_preset, or add_preset. The description states only what it does, not when it is the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It merely says 'Update a comment' without disclosing behavioral traits such as whether it overwrites the existing text, permission requirements, reversibility, or side effects. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded, with no wasted words. It clearly communicates the tool's purpose in a concise manner.
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 output schema, and fully documented parameters, the description is adequate. It could be enhanced with a note about updating existing comments vs creating new ones, but it is not necessary for a basic update operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-level detail beyond what the schema already provides; it simply lists the entity types which match the entity_type schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a comment on a project, portfolio, or goal' clearly states the verb (update), resource (comment), and specific scope (project/portfolio/goal). This distinguishes it from the sibling update_comment (likely for issue comments) and other comment tools like add_entity_comment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the entity types mentioned, but there is no explicit guidance on when to use this tool vs alternatives or exclusions. It doesn't state 'use this instead of update_comment for entity comments' or provide when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose safety/behavioral traits. It only states the action and resource, omitting any details about permissions required, whether the comment is immediately visible, how 'summonees' mentions are processed, or what the response contains. This is a 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, efficient sentence that front-loads the core purpose. Every word adds value, with no redundancy or 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 tool is relatively simple, has an output schema, and all parameters are documented. However, the description lacks context about prerequisites (e.g., entity must exist) and behavioral outcomes (e.g., whether summonees are notified), leaving some gaps for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes all parameters. The description's phrase 'project, portfolio, or goal' restates the entity_type description without adding new semantic meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Add') and clearly identifies the resource types ('project, portfolio, or goal'). This distinguishes it from the sibling 'add_comment' tool, which likely targets issues, by explicitly naming the entity types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: when commenting on a project, portfolio, or goal. It does not explicitly mention alternatives or exclusions, but the entity types in the description differentiate it from the issue-comment sibling 'add_comment'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions preserving timestamps and author, but for a mutation tool it fails to disclose important traits such as key conflict handling, permission requirements, or whether existing issues with the same key are overwritten. This is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action, and contains no filler words. It earns its place by conveying the core purpose and the key distinctive behavior.
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?
Although the schema is rich and an output schema exists, the description is very sparse for a tool with 16 parameters and no annotations. It lacks context about import semantics, such as duplicate key behavior or prerequisites, but the schema compensates for parameter understanding, making it minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each of the 16 parameters clearly documented (e.g., created_at as 'Original creation time'). The description adds little beyond reinforcing the 'original' nature of created_at and created_by, which is already present in the schema. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Import') and resource ('an issue'), and clarifies the distinctive behavior of preserving original timestamps and author. This clearly distinguishes it from siblings like create_issue, which would normally set these fields to the current time and user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case of importing an issue with original metadata, providing clear context. However, it does not explicitly state when to avoid this tool or mention alternatives like create_issue, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'List comments' and gives no details about authentication, pagination, ordering, response size, or explicit confirmation of no side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. Every word contributes necessary scope information, and it is appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With the input schema and output schema present, basic invocation details are covered. However, the description gives no guidance on how this differs from list_comments or any behavioral expectations, leaving some usage context incomplete for a 4-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters (entity_type, entity_id, fields, output_format) are already well documented. The description adds no parameter-specific meaning beyond restating the entity types already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), the object ('comments'), and the scope ('project, portfolio, or goal'). This specific resource/entity-type framing distinguishes it from sibling tools like list_comments, which likely targets issue comments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context by specifying the entity types (project, portfolio, goal), implying when to use this tool. It doesn't explicitly name alternatives or exclusions, but the scope is unambiguous.
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 only restates the tool's action ('List links') without adding contextual details like read-only safety, pagination, sorting, or the nature of 'links.' This adds little beyond what the tool name suggests.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose. Every word earns its place, and there is no unnecessary verbosity or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the presence of a complete input schema, and an output schema, the description covers the essential purpose. However, it lacks disambiguation from sibling tools like list_links and does not clarify what 'links' include, 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with descriptions for all three parameters (entity_id, entity_type, output_format). The description adds no additional parameter meaning beyond what the schema already provides, so it remains at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('List links') with a defined resource scope ('project, portfolio, or goal'). This differentiates it from sibling tools like list_links (which likely handles issue links) and list_external_links (external URLs), avoiding ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description identifies the exact entity types the tool applies to, giving clear context for when it should be used. It does not, however, explicitly mention alternatives or exclusions, such as using list_links for issues or list_external_links for external links.
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 fully disclose behavioral traits. It merely restates the basic function without mentioning user-specific transitions, permission dependencies, or how the output relates to transition_issue. This misses an opportunity to add transparency beyond the obvious read-only nature of listing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action and resource. It is fully concise and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, with well-documented parameters and an output schema. However, the description does not connect to transition_issue or note that returned transition IDs are used for performing transitions. Without annotations, this leaves a minor gap, but it is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already contains full descriptions for both parameters (issue_key and output_format), so the description adds no extra semantic value. With 100% schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists available status transitions for an issue. It uses a specific verb (list) and resource (status transitions), and it distinguishes itself from siblings like transition_issue (which executes a transition) and list_statuses (which lists all statuses).
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 usage context—checking which transitions are available for a specific issue before performing one. It provides clear context without explicitly naming alternatives or exclusions, which is sufficient for a simple list tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure. It conveys that the tool searches issues and adds a nuance about local field prefixing, but it doesn't elaborate on read-only safety, pagination behavior, or how query and keys interact. This is adequate but minimal 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 exceptionally concise: two sentences, the first stating the core purpose and the second a useful tip. No filler or repetition; it is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 well-documented parameters and an output schema, so the description mainly needs to add behavioral context. It provides a valuable tip about query syntax, leaving only minor gaps such as not mentioning alternatives or clarifying the relationship between keys and query. Overall, it is complete enough for informed invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides clear descriptions for all 8 parameters (100% coverage). The description adds extra semantic value by explaining how to search by local fields with a queue key prefix, which enriches the query parameter meaning beyond the schema example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (search) and resource (issues), and mentions both query language and filters. It doesn't explicitly distinguish from similar tools like count_issues or search_entities, but the scope is evident and the tip adds precision.
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 searching issues and provides a helpful tip for local field queries, but it does not explicitly state when to prefer this tool over alternatives like count_issues, search_entities, or get_issue, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action and scope. It does not disclose update semantics (partial vs full), null-value behavior, required permissions, or side effects, leaving significant 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 a single clear sentence (12 words) that front-loads the action and scope. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema covers parameters and an output schema exists, but the description alone does not clarify behavioral nuances such as whether null clears fields or whether updates are partial. This is adequate but has clear gaps given the tool's optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the schema; parameter details like 'New text' are solely in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (update), resource (checklist item), and scope (project, portfolio, or goal). It distinguishes from sibling tools like update_checklist_item by specifying the entity context.
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 by listing applicable entity types, implying use for entity-level checklist items. However, it does not explicitly exclude alternatives like update_checklist_item or give when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 indicates a read operation but does not disclose potential failure modes (e.g., unauthenticated access) or detail the response shape beyond what an output schema might provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It quickly communicates the tool's purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature (no required params, output schema exists), the description provides enough context to select and invoke the tool. It clearly defines the resource and purpose, and the schema covers parameters and return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter output_format is fully described in the schema (100% coverage), so the description does not need to add much. The schema's explanation of 'text' vs 'json' is sufficient; the description adds no extra 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 'Get current authenticated user info' states a specific action (get) and resource (current authenticated user info). It clearly distinguishes itself from sibling tools like get_user and list_users by focusing on the authenticated user.
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 use case is implied by the phrase 'current authenticated user'—you use this to retrieve your own info. However, it does not explicitly mention alternatives like get_user for other users, so guidance is not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. The verb 'Get' clearly signals a read-only operation, and the listed fields (params, template, rules) indicate the expected response content. It does not mention output format details, but those are covered by the schema's output_format parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It immediately states the action and the specific content returned, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter read tool with an output schema and full schema description coverage, the description is mostly complete. However, it lacks explicit context about when to use this tool versus related preset tools, which prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters already have informative schema descriptions (preset key source and text/json formats). The description adds no additional parameter semantics, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' with a specific resource 'preset details' and enumerates the returned content (params, template, and rules). This clearly distinguishes it from sibling tools like list_presets (which lists presets) and create_from_preset (which creates from a preset).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as list_presets or create_from_preset. The schema mentions 'Preset key (from list_presets)', but that is not part of the description, so the description itself provides no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It indicates a read-only operation ('Get') and lists included components, which adds context. However, it does not disclose permissions, potential errors, or any limitations of the aggregate view, so transparency is only partially addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, direct sentence that immediately states the tool's purpose and scope. Every word earns its place; it is front-loaded and concise.
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 adequately covers the tool's complexity by listing the five major data types included. Input schema is clear and output schema is present, so return values are handled externally. No significant gaps remain for an aggregate read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with both parameters (issue_key and output_format) already documented. The description adds no additional parameter semantics beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (Get) and resource (issue) with a clear scope: comprehensive overview including status, comments, links, checklist, and worklog. It clearly distinguishes from sibling tools like get_issue or list_comments by aggregating multiple aspects.
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 this when you need a broad overview of an issue rather than calling multiple separate endpoints. However, it does not explicitly name alternatives or state when not to use it, leaving usage guidance only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. The verb 'List' implies a read-only operation, and the resource scope is clear, but it discloses no additional behavior such as permissions, pagination, or response details. For a simple list tool this is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It states the action, resource, and scope directly, making it highly concise and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a straightforward list operation and an output schema exists, the description covers the essential purpose and scope. It does not explain how entity_id maps to the entity type, but the schema's required fields and entity_type description sufficiently fill that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description only restates the entity types already present in the entity_type parameter description and does not add any extra meaning to entity_id or output_format beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('attachments') scoped to project, portfolio, or goal, which clearly differentiates it from the sibling list_attachments that likely targets issues. It adds concrete entity types beyond the tool name, making purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: call this when you need attachments of a project, portfolio, or goal. However, it provides no explicit guidance on when not to use it or which alternative tool (e.g., list_attachments) to use for other entity types, leaving usage mostly inferential.
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 only states the action and does not disclose permissions, pagination, or what 'links' includes. For a list operation, it is safe to assume read-only, but the description gives minimal 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 sentence that is front-loaded and contains only essential information. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with an output schema, the description is adequate. It does not define 'links' explicitly, but sibling names and the schema cover enough context. Could be more complete with pagination or permissions, but not critical for this operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are documented. The description adds the phrase 'all links' implying no filtering, but this is marginal. Baseline 3 applies since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'List all links of an issue.' It clearly distinguishes from siblings like list_entity_links and list_external_links by scoping to issue links.
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?
Usage is implied by the name and description: use this for issue links, not entity or external links. There is no explicit mention of alternatives or exclusions, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states exactly that it lists all issue priorities, which is transparent and implies a read-only operation. It does not mention caching behavior or output specifics, but these are covered in the input schema and output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It front-loads the action and resource clearly.
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 a fully documented schema and an output schema present, the description is adequate. It could mention caching implications, but overall it provides sufficient context for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents both parameters (use_cache and output_format) with clear descriptions, achieving 100% schema coverage. The description adds no additional parameter meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'issue priorities', scoped to 'the organization'. This distinguishes it from sibling list tools like list_issue_types or list_statuses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose is straightforward, so when to use is implied. However, there is no explicit guidance on alternatives or exclusions, though none seem necessary for this simple listing tool.
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 bears the full burden of behavioral disclosure. It indicates the action is state-changing but does not mention permissions, failure modes, side effects, or response contents. The prerequisite hint is helpful but insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, purposeful sentences: the first states the action, the second provides the essential prerequisite. No filler, repetition, or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward transition tool with full parameter schema coverage and an output schema, the description supplies the crucial prerequisite step. It could mention exclusions like bulk_transition for multiple issues, but overall 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and each parameter has a description. The description reinforces that transition_id comes from list_transitions but adds no significant semantic beyond the schema, matching the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Execute a status transition') on a specific resource ('an issue'), distinguishing it from sibling tools like update_issue, move_issue, and bulk_transition. The verb+resource structure is explicit and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear procedural instruction: call list_transitions first to obtain the available transition IDs. This tells the agent how to prepare for using the tool, though it does not explicitly contrast with alternative bulk transition or move tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It clearly states what information will be displayed (TTL, last updated, record count), and the verb 'show' implies a read-only operation with no side effects. However, it does not explicitly state whether the status is actively refreshed or merely reads cached metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys all essential information and wastes no words. It is appropriately concise for a simple status tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, one optional parameter, full schema coverage, and the presence of an output schema, the description is complete enough. It captures the purpose and key details without needing to explain return values or edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the single parameter (output_format) with format details for 'text' and 'json'. The description adds no extra meaning beyond confirming the tool displays status, which is already implied. Baseline 3 is appropriate since schema coverage is 100%.
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: showing cache status for directories, specifically TTL, last updated, and record count. It uses a specific verb and resource, and distinguishes itself from sibling tools like sync_directory or configure_cache by being purely informational.
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 checking cache status but does not explicitly mention when to use it over alternatives or mention exclusions. No when/when-not guidance is provided, though the read-only nature is apparent.
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 for behavioral disclosure. 'Get' implies a read-only operation, but it does not specify permissions required, return format details (though output_format is in schema), or any side effects. This is 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 a single, concise sentence that front-loads the core purpose. No fluff or redundant information, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with output schema available, the description is adequate. It covers the essential purpose and entity scope, but lacks explicit guidance on distinguishing from get_entity or handling output_format choices. Still, overall completeness is good.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description states the entity types which mirrors the schema's enum, adding no extra meaning beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' with a clear resource 'access settings' and scopes it to 'project, portfolio, or goal', which precisely distinguishes it from sibling tools like get_entity (general entity retrieval) and update_entity_settings (modification).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool is for retrieving access settings of specific entity types, giving enough context to choose it over alternatives. However, it does not explicitly mention when not to use it or name alternatives like update_entity_settings, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 the parallel fan-out behavior and the compact combined result structure. However, it does not mention potential rate limiting, failure behavior, or whether the operation is read-only (though 'fetch' implies that). It provides some behavioral context but not comprehensive coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the purpose, then usage context. Every sentence earns its place; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters and an output schema, and the description covers the primary use case, differentiates from list_links, and provides an example. The output schema handles return value expectations. The only minor gap is not explaining the 'compact' parameter's impact on output, but that is covered in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any parameter-specific meaning beyond the schema, but the schema itself thoroughly documents each parameter. No further compensation needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb ('Fetch') and resource ('links'), and clearly states the scope ('multiple issues in a single call'). It also distinguishes from the sibling tool list_links by noting it avoids N separate calls, which provides sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use this instead of calling list_links N times' and gives an ideal use case ('my tasks' flows). This gives clear when-to-use guidance, though it doesn't explicitly say when not to use (e.g., for single issues), but the implication is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the disclosure burden. It explicitly warns that "local field values are lost when moving to another queue," which is a critical behavioral consequence. It does not cover permissions or reversibility, but the warning adds significant transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with the primary action first and the warning second. Every word earns its place; no redundant or vague content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential purpose and the most important side effect for a move operation. The output schema and fully described input schema cover the remaining details, so the description is adequately complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents all parameters (queue, issue_key, fields, output_format, full_description). The description adds no parameter-specific detail beyond the purpose, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource-destination construction: "Move issue to another queue." It clearly distinguishes this from sibling tools like transition_issue (status change), update_issue (field edits), and bulk_move (multiple issues).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the tool's use case (moving an issue to another queue) and includes a warning about losing local field values. It does not explicitly name alternatives or exclusions, but the purpose is specific enough to guide selection.
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:

[![ya-tracker-mcp MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/imdeniil/ya-tracker-mcp/badges/card.svg)](https://glama.ai/mcp/servers/imdeniil/ya-tracker-mcp)

Score Badge

Copy to your README.md:

[![ya-tracker-mcp MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/imdeniil/ya-tracker-mcp/badges/score.svg)](https://glama.ai/mcp/servers/imdeniil/ya-tracker-mcp)

shields.io Endpoint

For READMEs with an existing badge row. Append &style=flat-square (or any other shields.io style) to match the rest, and &metric=tools, &metric=maintenance or &metric=claim to badge a different dimension.

[![ya-tracker-mcp MCP server — quality and maintenance score on Glama](https://img.shields.io/endpoint?url=https%3A%2F%2Fglama.ai%2Fmcp%2Fservers%2Fimdeniil%2Fya-tracker-mcp%2Fbadges%2Fshields.json)](https://glama.ai/mcp/servers/imdeniil/ya-tracker-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/imdeniil/ya-tracker-mcp'

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