MCP Atlassian

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Tools are mostly distinct with detailed descriptions differentiating overlapping operations (e.g., search vs project issues vs board issues). A few similar get_issue_* enrichment tools (dates, SLA, development info) could be confused, but their descriptions clearly separate them.
Naming Consistency5/5
All tools follow a consistent snake_case pattern of {domain}_{verb}_{object}, with domains 'jira_' and 'confluence_' and verbs like get/create/update/delete/search. Batch operations use a consistent 'batch_create' prefix, and specialized tools use clear suffixes (e.g., _sla, _dates, _development_info).
Tool Count2/5
With 98 tools, the server is far beyond the typical 3-15 well-scoped range. While the Atlassian domain is large, many tools are highly niche (e.g., jira_get_issue_sla, confluence_get_page_views), and the set could be trimmed or split into separate Jira and Confluence servers to reduce cognitive load.
Completeness5/5
The tool set covers the Jira and Confluence lifecycles comprehensively: CRUD for issues, pages, projects, sprints, versions, attachments, comments, users, permissions, and much more. It includes advanced features like SLA metrics, development info, restrictions, templates, and history/diffs, leaving few significant gaps for its stated domain.
Average 3.9/5 across 93 of 98 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 135 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only include destructiveHint: false, which is minimal. The description 'Create a new Confluence page.' adds no behavioral details beyond what the tool name implies. It does not disclose things like content format handling, mutual exclusivity of content and content_file, or whether the page is immediately published. With such sparse annotations, the description carries the burden and fails to provide 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, which is efficient. However, it is under-specified for a complex tool with 12 parameters. It lacks structure and any additional context, making it minimally viable but not appropriately sized for the tool's complexity.
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 and output schema provide rich structured information, the description fails to add contextual completeness. It does not mention when to use this tool versus create_page_from_template, nor does it hint at content handling nuances. The tool is a create operation with many options, and the sparse description leaves the agent without key decision-making 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 covers 100% of the parameters with detailed descriptions, so the baseline is 3. The tool description itself does not add any parameter semantics; it just says 'Create a new Confluence page.' Since schema descriptions are already thorough, the lack of addition is acceptable but not a bonus.
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 and resource: 'Create a new Confluence page.' This clearly states the action and object. However, it does not distinguish itself from sibling tools like confluence_create_page_from_template, which also creates a page, so it doesn't fully address 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 such as creating from a template or copying a page. There is no mention of prerequisites, exclusions, or context in which this tool is preferred. The usage must be inferred entirely from the 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?
The description adds no behavioral context beyond the annotation destructiveHint: true. It does not disclose what the update overwrites (e.g., entire page content vs. individual fields), whether version history is preserved, or any permission/side-effect details. With a destructive flag already present, the description still fails to add informative context such as 'replaces the entire page body' or 'creates a new version'.
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 wasted words, but it is under-specified for a tool with 13 parameters and complex options like mutually exclusive content/content_file. It is not verbose, but it is barely more informative than a tautology; this leans toward under-specification rather than 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?
Given the tool's complexity (13 params, output schema, sibling tools like update_page_section and move_page), the description is far too sparse. It does not mention key usage prerequisites (e.g., required page_id and title, content replacement semantics, or interactions with other tools). The excellent output schema and rich parameter descriptions mitigate some gaps, but the description itself fails to provide enough context for confident 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%, meaning every parameter is already documented in the input schema with detailed descriptions. The description itself contributes no parameter-level meaning beyond what the schema provides. Baseline 3 is appropriate because the schema does the heavy lifting and the description does not add extra semantic 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 'Update an existing Confluence page' clearly states a specific action and resource, making the tool's core purpose obvious. However, it does not differentiate from the closely named sibling tool 'confluence_update_page_section', which could easily be confused with it. The verb+resource is clear but sibling differentiation is absent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., 'confluence_create_page', 'confluence_update_page_section'). There is no mention of scenarios where this should be preferred, no exclusions, and no alternative tool names referenced. The agent is left to infer usage solely 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?
The description adds no behavioral context beyond the destructiveHint annotation. It does not explain what happens to the issues (e.g., movement within the sprint, potential overwriting of previous sprint assignments) or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that wastes no words. It is appropriately sized for a simple tool, though it is minimal in 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?
Given the simple two-parameter tool and the presence of an output schema, the description is minimally adequate. However, it lacks nuances like prerequisites (e.g., issues must be in the backlog) or potential edge cases, making it only marginally 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% for both parameters (sprint_id and issue_keys). The description adds no additional meaning beyond what the schema already provides, so baseline 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 'Add issues to a Jira sprint' uses a specific verb and resource, clearly stating the action. It is distinct from sibling tools like jira_create_sprint or jira_move_issues_to_backlog, though it doesn't add extra scoping 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?
No usage context is provided. The description does not mention when to use this tool versus alternatives, such as whether it is appropriate for adding issues from the backlog or if other tools like jira_transition_issue should be used first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what the annotations already provide (destructiveHint: true). It does not mention potential side effects like workflow constraints, required fields, or that the status change is irreversible. With only a one-sentence description and no additional context, the agent is left unaware of important behavioral traits beyond the fact that the operation is destructive.
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 wasted words. It is appropriately concise and front-loaded, stating the core action immediately. However, it could include a bit more detail without becoming verbose, so it doesn't reach a perfect 5 but remains well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the rich input schema and output schema, the tool has nuanced behavior: transitions can require fields, comments have special rules for internal-only projects, and prerequisites like fetching available transitions. The description provides none of this context, leaving the agent to rely entirely on schema descriptions. Given the complexity, a more complete description is needed to adequately prepare the 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?
Schema description coverage is 100%, so the baseline is 3. The input schema provides rich descriptions for all parameters, including examples for fields, comments, and transition_id usage. The tool description itself adds no parameter-level meaning, but the schema compensates fully, so this dimension meets the minimum viable threshold.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Transition a Jira issue to a new status.' It uses a specific verb ('transition') and resource ('Jira issue'), which distinguishes it from generic update tools. However, it does not explicitly differentiate from sibling tools like jira_update_issue or jira_move_issue, relying on the domain-specific term 'transition' to carry that weight.
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 does mention nothing about needing to call jira_get_transitions to obtain valid transition IDs. While the input schema for transition_id includes this instruction, the description itself offers no usage context, leaving the agent without explicit decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description states the core action but does not disclose batch-specific behaviors such as validation-only mode (validate_only parameter), partial success handling, or concurrency implications. Annotations only provide destructiveHint=false, which is consistent but doesn't add further 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?
One sentence, zero redundancy. However, while concise, it omits any usage guidance that could be included in a similarly short form.
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 batch creation tool with a validate_only option and potential partial failures, the description is insufficiently complete. It doesn't mention the validation feature or how batch creation contrasts with single-issue creation, leaving the agent without key 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?
Input schema describes both parameters in detail, including an example for the issues array and default for validate_only. The description adds no parameter information, but the schema's high coverage means 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 the specific verb 'Create' with the resource 'multiple Jira issues' and 'batch', clearly distinguishing from single-issue creation (jira_create_issue) and batch version creation (jira_batch_create_versions).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. The sibling list includes jira_create_issue for single issues, but the description doesn't direct users to choose one over the other, nor mention any prerequisites or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include destructiveHint=false, but no readOnly hint. The description adds no behavioral context beyond that—no mention of idempotency, permissions, validation, or the special handling of comments for internal projects. This leaves the agent without useful transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with zero filler. It is extremely concise and well-structured, even if it lacks depth.
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 5 parameters, 3 required, an output schema, and 100% schema description coverage. The description is minimal but the schema handles many details. However, it lacks differentiation from other link tools and omits usage context like comment restrictions, so it is adequate but with 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 baseline is 3. The description itself adds no parameter semantics; all meaning comes from the schema, which is already thorough.
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 'Create a link between two Jira issues,' which is a specific verb and resource. However, it does not differentiate from sibling tools like jira_link_to_epic or jira_create_remote_issue_link, so it earns a 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is provided. The description does not mention alternatives, exclusions, or prerequisites. Although the schema's comment parameter note suggests jira_add_comment as a fallback, the description itself provides no 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?
The only annotation is destructiveHint=false, which the description does not contradict. However, the description adds no behavioral detail beyond the obvious act of creation – no mention of side effects, permissions, or what happens on duplicate names, etc.
Agents need to know what a tool does to the world before 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, 'Create Jira sprint for a board,' with zero filler words. It is front-loaded and easy to parse, though under-specified in other dimensions.
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 rich input schema (100% coverage) and presence of an output schema, the description's job is minimal. However, it lacks usage context or alternative tool guidance, making it merely adequate for a simple create 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 describes all 5 parameters with 100% coverage, so the schema carries the semantic weight. The description adds no parameter-specific information, 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 clearly states the tool creates a Jira sprint for a board, using the specific verb 'create' and naming both the resource (sprint) and target (board). It is distinct from sibling tools like jira_update_sprint or jira_get_sprints_from_board by the action verb, though it doesn't explicitly call out those 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 like jira_update_sprint or jira_get_sprints_from_board. The description is purely definitional and does not mention prerequisites, scenarios, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With only destructiveHint=false in annotations, the description adds little beyond stating the mutation itself. It does not mention response format, permissions, whether the comment is appended to existing ones, or any side effects. The description is essentially a restatement of the tool's basic function, offering minimal 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 that directly states the purpose without any redundancy or extra fluff. It is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool (two well-documented parameters, an output schema present, no nested objects), the one-line description is mostly sufficient. However, it falls short on clarifying the distinction from reply/inline comment tools and lacks usage guidance, but these are minor given the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both page_id and body, so the structured schema fully documents the parameters. The tool description itself adds no extra semantics, which is acceptable given the baseline of 3 when schema coverage is high.
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 'Add a comment to a Confluence page' clearly identifies the action (add) and the resource (Confluence page), which is specific. It implicitly distinguishes from siblings like 'reply to comment' or 'add inline comment' by using the generic 'add a comment', but it does not explicitly state that it adds a top-level comment, so it doesn't fully disambiguate from all sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like confluence_reply_to_comment or confluence_add_inline_comment. There are no contextual tips or exclusions mentioned, leaving the agent to infer usage from the simple action 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?
The description adds no behavioral context beyond the action itself. Despite annotations declaring destructiveHint=false, there is no information about authentication requirements, rate limits, or side effects such as the comment becoming visible to viewers. For a mutation tool, this leaves significant gaps in 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, front-loaded sentence with zero wasted words. It conveys the core purpose in the most concise form possible, earning a top score for structure and conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of a comprehensive input schema (100% coverage) and an output schema (indicated), the one-line description provides adequate context. It identifies the action and resource, and the schema supplies parameter details. However, it stops short of mentioning sibling tool distinctions, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with detailed documentation for each parameter, especially 'public' and 'visibility'. The description itself does not add parameter semantics, but the schema already carries the full burden, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add a comment to a Jira issue' clearly states the action (add) and the resource (comment on a Jira issue), using a specific verb+resource structure. It distinguishes from sibling tools like jira_edit_comment by the verb, though it does not explicitly compare 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?
No guidance is provided on when to use this tool versus alternatives such as jira_edit_comment for modifying comments. The usage context is only implied by the tool name and description, with no explicit exclusions or alternative references.
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 only annotation is destructiveHint: true. The description adds no behavioral context beyond that, such as potential side effects, permissions, fallback behavior for raise_on_behalf_of, or the meaning of strict_on_behalf. There is no contradiction, but the description is a bare statement that contributes no additional insight.
Agents need to know what a tool does to the world before 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 well-structured and front-loaded with the action and target. However, it may be too minimal for the tool's complexity, but within this dimension it is 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?
This tool has 7 parameters, 3 required, and an output schema, yet the description provides only a one-line summary. It lacks context about when to use it, how it interacts with JSM, or what happens on failure. The existing schema and annotation help, but the description is insufficient for an agent to choose 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 description coverage is 100%, so the schema fully documents all parameters. The description adds no extra meaning or usage examples. Baseline 3 is appropriate since the schema carries the 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 'Create a Jira Service Management customer request' clearly states the verb (create), resource (customer request), and domain (Jira Service Management). This distinguishes it from sibling tools like jira_create_issue, which creates a regular Jira issue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention JSM-specific context, prerequisites (like service desk or request type), or contrast with jira_create_issue. The name implies usage but the description itself is silent.
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?
Given the destructiveHint annotation, the description adds no new behavioral context. It does not mention irreversibility, required permissions, or any side effects on linked issues or associated data. The word 'existing' implies the issue must exist, but this is trivial and does not materially enhance understanding beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently communicates the core purpose. It is appropriately sized for the tool's simplicity, though it could have included more behavioral context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter and a destructive annotation, the description is minimally viable. However, it lacks important context about consequences and prerequisites, which would be expected for a destructive action even with annotations. The presence of an output schema reduces the need to explain return values, but overall completeness is only 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 covers the sole parameter issue_key with a pattern and example, providing full semantic clarity. The description adds no additional meaning beyond the schema, so the baseline of 3 applies without any extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and resource ('Jira issue'), clearly distinguishing it from sibling tools like jira_update_issue or jira_get_issue. The title and description are consistent, and the full sentence 'Delete an existing Jira issue' leaves no ambiguity about the operation.
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, prerequisites, or potential consequences (e.g., permission requirements, cascading deletions). The description only states the action itself, leaving the agent with no contextual guidance 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?
The description states 'Edit an existing comment', but adds no behavioral details beyond what the annotation already provides (destructiveHint: true). There is no mention of permissions, whether the edit replaces or merges content, idempotency, or potential side effects. The annotation already flags destructiveness, but the description fails to add any extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words. It is front-loaded with the action and subject. It earns its place by stating the core purpose, though it omits any supplementary context that could be useful (e.g., mention of visibility parameter). Still, it is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with 4 parameters and an output schema, the description is minimal but functional. The schema and destructiveHint annotation cover parameter details and safety, but the description lacks any broader context such as typical use cases, relationship to add_comment, or consequences. Given the tool's simplicity, it barely reaches a minimum viable level, but there is room for improvement.
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% description coverage for all four parameters, so the baseline is 3. The description itself does not elaborate on the parameters, but the schema already provides sufficient detail (e.g., body is 'Updated comment text in Markdown format', issue_key has a pattern, visibility has an example). No additional meaning is added by the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Edit' with a clear resource: 'an existing comment on a Jira issue'. This clearly distinguishes it from sibling tools like 'jira_add_comment' by specifying 'existing', and from other issue-level edit tools like 'jira_update_issue' by targeting comments specifically.
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 any prerequisites, exclusions, or scenarios. The only implied usage is from the tool name and description, but there is no explicit context such as 'Use this when you need to modify a comment' or mention of alternatives like jira_add_comment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint=true already signals that the operation is destructive, so the description does not need to repeat that. No additional behavioral traits are disclosed, such as irreversible state changes or permission requirements, but the annotation covers the key risk profile. The description neither contradicts nor enriches the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the core action. It contains no irrelevant information. While it could be more informative, it is appropriately sized for a simple update operation and avoids verbosity.
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 high schema coverage and presence of an output schema, the description's minimalism is partially justified. However, it lacks any contextual cues about how this tool fits into a workflow, such as differentiating from sibling sprint tools or explaining the impact of destructive updates. The description is barely adequate for an agent to choose 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?
Schema description coverage is 100%, so the schema fully documents all six parameters. The description adds no semantic meaning beyond the schema; it does not clarify formats, defaults, or interactions between parameters. Baseline of 3 is appropriate because the schema carries the load.
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 jira sprint' uses a specific verb and resource, clearly indicating the tool updates a sprint. However, it does not distinguish this from related sibling tools like jira_create_sprint or jira_add_issues_to_sprint beyond the obvious 'update' action, and it omits what aspects of the sprint are updatable.
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 context is provided about prerequisites, when updating a sprint is appropriate, or what to avoid. The description simply states what it does without any situational 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?
Given the readOnlyHint annotation, the description adds no extra behavioral context. It does not disclose that pagination parameters (limit/start_at) mean 'all' issues may not be returned in a single call, nor does it describe the response structure. No contradiction with annotations, but no added value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence, 'Get all issues for a specific Jira project,' with no redundant wording. It is front-loaded 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?
With annotations confirming read-only behavior and an output schema presumably documenting return values, the description is minimally adequate. However, it lacks guidance on differentiating from similar issue-listing tools (board, sprint, queue), and it does not mention pagination, so it is not fully complete for a tool with many siblings.
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 clear descriptions for project_key, limit, and start_at. The tool description adds no additional parameter semantics beyond what the schema already documents, 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 ('Get') and the resource ('all issues for a specific Jira project'), which distinguishes it from related tools like jira_get_board_issues (board scope), jira_get_queue_issues (queue scope), and jira_search (cross-project search).
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 the result is scoped to a single project or that jira_search should be used for broader queries, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only restates the core action and adds no behavioral context beyond the destructiveHint annotation. It does not mention side effects like removing the page from its old parent, impact on child pages, or permission requirements. It is consistent with the annotation, but adds no extra transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of 10 words with no redundancy. Every word carries meaning, making it optimally 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?
Given the tool's simplicity, complete parameter schema, output schema, and destructiveHint annotation, the description sufficiently conveys the core function for invocation. However, it lacks guidance on when to use it vs. alternatives, 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 description coverage is 100%, so the schema already documents all parameters. The description only echoes the destination concept ('new parent or space') and adds no additional meaning beyond the parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Move') and resource ('a Confluence page') with a clear destination ('to a new parent or space'). This distinguishes it from sibling tools like copy_page, delete_page, or update_page within the same family.
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., copy_page for duplication, or update_page for editing). There are no mentions of prerequisites, exclusions, or context for choosing it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint=false only indicates the tool is not destructive. The description adds that it creates a 'fix version,' which clarifies the mutation type and resource, but it does not disclose other behavioral aspects such as permission requirements, uniqueness constraints, or side effects. While it adds some light context beyond annotations, it lacks richer behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that wastes no words. It effectively conveys the essential purpose without any filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the full input schema (100% coverage), an output schema, and the simple create operation, the description plus structured data are largely sufficient for correct invocation. However, it does not mention sibling differentiation (batch vs single) or any additional context like where the version appears, but these are not critical for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% description coverage for all 5 parameters, including format patterns for project_key and date formats. The description adds no additional parameter meaning, so the baseline score of 3 is appropriate because the schema already carries the full semantic 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 states a clear verb and resource: "Create a new fix version in a Jira project." This distinguishes the action (create) and object (fix version) well. It does not explicitly differentiate from the sibling tool jira_batch_create_versions, but the singular "a new" implies a single version, so it is not fully distinguished.
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 jira_batch_create_versions or jira_update_version. The description simply states what the tool does, leaving the agent to infer usage context without any exclusions or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating a safe read operation. The description's 'Get' aligns with this. However, it adds little beyond the scope, such as pagination behavior or field filtering, relying on the schema for details.
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 redundant information. It is appropriately brief for a simple retrieval tool, though it could be slightly more informative.
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 100% schema coverage, and the presence of an output schema, the description is minimally sufficient to convey the basic action. However, it lacks usage context and behavioral details, making 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?
All four parameters have descriptions in the schema (100% coverage), so the schema fully documents parameter meanings. The description does not add any additional semantic detail about how the parameters interact or what the sprint_id looks like.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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' with the resource 'jira issues' and the scope 'from sprint', which clearly identifies its function. It distinguishes itself from sibling tools like jira_get_board_issues by specifying the sprint context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as jira_get_board_issues (for issues from a board) or jira_search (for arbitrary queries). The description only states the action without any contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals a safe read operation. The description adds the 'by state' filter context but does not disclose pagination behavior, default limits, or potential edge cases. It is consistent with the annotation, adding modest value without contradicting it.
Agents need to know what a tool does to the world before 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 purpose. Every word earns its place, and there is no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple read-only nature, full schema coverage, and presence of an output schema, the description is mostly complete. However, it lacks usage guidance for distinguishing between related sprint/board tools, which leaves a minor contextual gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with descriptions for all parameters. The description only repeats the 'state' aspect and does not add further 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.
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 names the resource ('jira sprints from board') with a filter ('by state'). It clearly states what the tool does, but does not explicitly differentiate it from related sprint tools like jira_get_sprint_issues or jira_get_board_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. The description lacks any context about when to choose this over other sprint/board-related tools, and there is no mention of 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?
The description only states the action and adds no extra behavioral context. The annotation destructiveHint already signals mutation, but the description does not disclose additional traits like whether it replaces existing epic links, idempotency, or side effects. With annotations present, it fails to add value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the action and resource. Every word is informative, with no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with full schema coverage, an output schema, and destructiveHint annotation, the minimal description is mostly sufficient. The only gap is lack of explicit differentiation from generic link tools, but the epic-specific scope mitigates this.
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 detailed descriptions and examples for both issue_key and epic_key. The description adds no extra parameter semantics, but the schema fully documents the parameters, 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 'Link' with a clear resource scope: 'an existing issue to an epic.' It clearly distinguishes itself from sibling tools like jira_create_issue_link by specifying the epic relationship, and includes no ambiguity about the operation.
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 jira_create_issue_link or jira_remove_issue_link. The description simply states what it does without contextualizing its use case, prerequisites, 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?
The description adds no behavioral context beyond what the destructiveHint annotation already provides. It doesn't mention that the action is irreversible, whether special permissions are needed, or any limitations (e.g., remote links). Since the annotation already indicates destructive nature, the description fails to add further transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly conveys the tool's purpose without any unnecessary words, filler, or repetition. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one well-documented parameter and an output schema, the description is largely sufficient. The core action is clear, and the annotation covers the destructive nature. However, it lacks any usage guidance or additional behavioral details, which prevents a perfect score given the potential for ambiguity with 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 schema provides 100% coverage for the single parameter link_id with a clear description: 'The ID of the link to remove.' The tool description does not add any additional meaning beyond the schema, so the baseline score of 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Remove a link between two Jira issues.' This specifically distinguishes it from sibling tools like jira_create_issue_link and jira_link_to_epic, which perform related but different operations. The verb 'remove' and resource 'link' are 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. There is no explanation of how to obtain the link_id or when to prefer this over other link-related tools. The single sentence is purely functional and lacks usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description doesn't need to cover safety. It does add the 'fuzzy match' behavior, which is a useful context beyond the schema. However, it doesn't explain the refresh mechanism or potential latency, so it's moderate.
Agents need to know what a tool does to the world before 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 concise sentence that communicates the core functionality without any filler. It is front-loaded with the verb and resource, and the fuzzy-match detail is valuable. Perfect for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only 3 optional parameters and a well-defined schema, and an output schema exists. The description covers the primary purpose but omits details like result ordering or the impact of refresh. However, given schema richness, it's reasonably 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?
All three parameters (limit, keyword, refresh) have fully described schema entries covering their semantics, defaults, and empty-keyword behavior. The description itself adds no parameter-specific information, so with 100% schema coverage, 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 clearly identifies the tool as a search operation over Jira fields, using 'Search' as the verb and 'Jira fields' as the resource. It mentions 'fuzzy match' which gives a specific behavioral nuance, but it does not explicitly distinguish from sibling tools like jira_get_project_fields, though the name helps.
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 about when to use this tool versus alternatives. The description is a single sentence offering no context about use cases or exclusions. The parameter schema does add a note about empty keyword behavior, but that's in schema, not the 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?
The description adds no behavioral detail beyond the readOnlyHint annotation. It does not mention what the response contains (e.g., content, metadata), whether all versions are accessible, or any constraints. Since the annotation already indicates a safe read, the description adds little extra transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately conveys the tool's purpose. There is no redundant information or unnecessary detail.
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 simple tool and existence of output schema and annotations, the description is minimally adequate. However, it lacks explicit usage differentiation and behavioral details, making it less complete than it could be for agents choosing among many Confluence 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?
Schema description coverage is 100%, with each parameter (page_id, version, convert_to_markdown) documented in the schema. The tool description itself adds no additional parameter semantics, 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 'Get a historical version of a specific Confluence page,' using a specific verb and resource. It distinguishes itself from sibling tools like confluence_get_page (current version) and confluence_get_page_diff (diff between versions).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: use when you need a historical version. However, there is no explicit guidance on when to use this tool versus alternatives like confluence_get_page for current content, 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?
With only 'destructiveHint: false' in annotations, the description carries the full burden of disclosing behavioral traits. It states the creation action but does not mention possible partial failures, idempotency, validation rules, or any side effects. It adds minimal value beyond the annotations themselves.
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 that is easily scannable and avoids unnecessary words. It does not waste space, though it could benefit from slightly more detail about the batch behavior 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?
As a batch operation, the tool has inherent complexity (e.g., handling of multiple versions, potential partial failures) that is not addressed. The presence of an output schema may cover return values, but the description alone leaves gaps in understanding the operational context, especially given minimal 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 coverage is 100%, so the detailed parameter descriptions for 'project_key' and 'versions' already do the heavy lifting. The description adds no additional parameter semantics, which is acceptable per the baseline but no extra credit is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 ('Batch create') and a clear resource ('versions in a Jira project'). It distinguishes itself from the sibling tool 'jira_create_version' by emphasizing the batch/multiple aspect, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating multiple versions at once, providing clear context for when to use this batch tool. However, it does not explicitly mention when to prefer the singular 'jira_create_version' or alternative approaches, so it falls just short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (destructiveHint: false only). The description discloses the write action and the optional Epic/parent linkage, but does not add behavioral details like idempotency, required permissions, or response behavior. This is a gap given the sparse annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the core action and a key capability without 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?
The description is brief but the schema is rich and output schema exists. However, it lacks guidance on prerequisites (e.g., knowing project key) and fails to distinguish from batch creation, so it is not fully complete for the complexity of 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 covers all 7 parameters with detailed descriptions and examples (100% coverage). The description adds a pointer to Epic link/parent, which is already covered in additional_fields examples, so no significant added value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new Jira issue, with optional Epic link or parent for subtasks. This distinguishes it from sibling tools like jira_link_to_epic and jira_create_issue_link, which operate on existing issues.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context (single issue creation, optional Epic/parent) but does not explicitly compare to alternatives like jira_batch_create_issues or jira_link_to_epic. It implies use for a single issue but lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already signals the operation is safe. The description adds useful context that results are limited to projects accessible to the current user and that archived projects can be included via the parameter. However, it does not disclose other behavioral traits such as pagination, sorting, or the effect of the include_archived default, so it provides only modest additional value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is front-loaded with the action and resource. Every word contributes to understanding the tool's purpose and scope, with no unnecessary fluff. This is exemplary conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and an output schema, the description is complete. It selects the tool's scope (all accessible projects) and the presence of an output schema means return values are already defined elsewhere. Given the low complexity and rich structured metadata, no additional description is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single parameter (include_archived) with a default and description, achieving 100% schema description coverage. The description adds no additional parameter semantics beyond what the schema already provides. Therefore, the baseline score of 3 is appropriate 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving all Jira projects accessible to the current user. It uses a specific verb ('get') and resource ('all projects') with a clear scope ('accessible to the current user'). While it distinguishes from some siblings by emphasizing 'all' and user accessibility, it does not explicitly contrast with similar tools like jira_search_projects, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention that jira_search_projects might be better for filtering or searching projects, nor does it state any exclusions or prerequisites. There is only an implied usage context from the tool's name and description, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already signals the read-only nature, and the description does not contradict this. However, the description adds no behavioral context beyond the annotation, such as pagination behavior, result limits, or data aggregation details. With annotations covering the safety profile, this is adequate but not enriched.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that immediately states the tool's purpose. It is front-loaded and contains no filler, wasting zero 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 moderately complex (8 parameters, dual pagination modes, display name option), but the description only states the core function. The rich input schema and presence of an output schema compensate, yet the description misses an opportunity to summarize key capabilities like token-based pagination or field selection options, leaving the agent to discover these from parameter docs.
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 all 8 parameters, including examples and defaults for jql, limit, expand, fields, start_at, page_token, projects_filter, and use_display_names. The description itself adds no additional parameter 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 'Search Jira issues using JQL' uses a specific verb and resource, clearly distinguishing this broadly applicable search tool from sibling tools like jira_get_issue (single issue) and jira_search_assignable_users (user search). It also explicitly names the query language, leaving no ambiguity about its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool instead of related search tools (e.g., jira_get_project_issues, confluence_search). It does not mention use cases, exclusions, or alternatives, leaving the agent to infer appropriate usage solely from the name and JQL reference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint=true already signals destructive behavior. The description adds 'existing' to imply the page must exist, but does not disclose whether deletion is permanent, affects child pages, or requires specific permissions. Minimal additional context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence that immediately conveys the purpose with no filler, redundancies, or unnecessary detail. Perfectly concise 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?
For a simple delete operation with one parameter, an output schema, and a destructive annotation, the description is nearly sufficient. It could mention reversibility or side effects, but given the tool's low complexity and the presence of structured metadata, the description is 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 documents the single parameter 'page_id' with a clear description. The tool description adds no additional parameter semantics beyond what the schema provides, so it remains at the schema-coverage baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action 'Delete' and the resource 'existing Confluence page,' making it unambiguous and distinguishing it from sibling tools like update or move. It is specific and clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'confluence_move_page' or 'confluence_delete_attachment.' It does not mention any prerequisites, exclusions, or context for deletion, leaving the agent without explicit 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?
The description is consistent with the readOnlyHint annotation (a read operation). It adds minimal context beyond the annotation by specifying that it returns both pages and folders. No additional behavioral details (e.g., pagination behavior, default content inclusion) are disclosed, but given the annotation coverage this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence conveys the tool's core purpose with no filler. The description is front-loaded and every word contributes to understanding the tool's 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 that the output schema exists, annotations are present, and parameter schema is comprehensive, the description is sufficient for a straightforward read-only retrieval tool. It could mention that child folders are included based on include_folders, but this is already captured in the schema. The description provides enough context for basic 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 schema provides 100% coverage for all 7 parameters with descriptions, so the baseline is 3. The tool description adds no parameter-level meaning beyond what the schema already provides, such as clarifying the relationship between include_content and convert_to_markdown, but the schema itself is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('child pages and folders of a specific Confluence page'). It differentiates from siblings like 'confluence_get_page' (which retrieves a single page) and 'confluence_get_space_page_tree' (which retrieves the full space tree) by focusing specifically on children of a given page.
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 explicit guidance on when to use this tool versus alternatives such as 'confluence_get_space_page_tree' or 'confluence_get_page'. The description does not mention any context, prerequisites, or exclusions, leaving the agent to infer usage 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already marks this as a safe read operation, so the description doesn't contradict. It adds no extra behavioral context (e.g., filter combination logic, ordering, or auth requirements), but the absence of such detail is acceptable given the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that delivers all essential information without filler. It is front-loaded with the verb and resource, making it highly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple read-only list operation with an output schema present, so return values are not needed. The description accurately conveys the core functionality, though a note on how multiple filters combine would enhance completeness. Given the simplicity, it's 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?
Schema description coverage is 100%, so the schema fully documents all parameters including fuzzy search and patterns. The description adds only a brief summary of filter types, which provides marginal value beyond the schema, aligning with the baseline 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 retrieves Jira agile boards, with a specific list of filter dimensions (name, project key, type). It does not explicitly distinguish from sibling tools that operate on boards (e.g., jira_get_board_issues), so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: the description indicates the tool is for finding boards by various criteria. However, it provides no explicit guidance on when to prefer this over other board-related tools or any exclusions, which keeps it at the 'implied usage' level.
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 only annotation is readOnlyHint=true, which already tells the agent this is a safe read operation. The description adds no behavioral detail beyond the read-only nature, such as permissions, rate limits, or output scope. It simply restates the action, adding minimal value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the core action and object, and contains no filler. It is appropriately sized for a tool with one parameter and a clear purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, output schema exists), the description covers the essential function. It doesn't elaborate on edge cases or define 'fix versions', but for a basic read operation it is sufficient. A small gap remains in not mentioning any required permissions or the fact that it returns both released and unreleased versions.
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 thoroughly describes the only parameter (project_key) with pattern and example. The description's phrase 'for a specific Jira project' only restates this, so the baseline of 3 applies as the schema carries the parameter-semantic burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and identifies the resource 'all fix versions' with a clear scope 'for a specific Jira project'. This clearly distinguishes it from sibling tools like jira_create_version and jira_update_version, which are mutations.
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 retrieve versions for a project, but it does not explicitly state when not to use this tool or mention alternative tools. It lacks exclusions or alternative guidance, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already confirms the safe read behavior, and the description adds minimal extra context ('field definitions'). It does not disclose potential rate limits, prerequisites, or response structure, but given the simple nature and existing annotations, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the essence without waste. It is appropriately sized for a tool of this simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, presence of an output schema, and readOnlyHint annotation, the description is nearly complete. It lacks explicit mention of what 'field definitions' entails, but the output schema compensates for that.
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 (service_desk_id and request_type_id) including examples. The description adds no additional parameter meaning, which is fine since the schema is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 ('field definitions for a Jira Service Management request type'), precisely distinguishing this from siblings like jira_get_request_types (which lists request types) or jira_get_field_options. It unambiguously states the tool's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 jira_get_create_fields or jira_search_fields. The description merely states the function without any context, exclusions, or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation already declares readOnlyHint=true, and the description's 'Get' is consistent with that. The description adds no further behavioral context (e.g., pagination, response structure, permissions), but for a straightforward read operation the annotation covers the key safety trait, so a mid score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the tool's function with no redundant words. It is front-loaded and maximally 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?
With one fully documented parameter, a readOnlyHint annotation, and an output schema present, the minimal description is nearly complete for a simple retrieval tool. However, it lacks any usage guidance or mention of related tools, preventing 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?
The schema already documents the sole parameter issue_key with full coverage, including format examples. The description only mentions 'a Jira issue' without adding any extra meaning 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 ('Get') and resource ('worklog entries for a Jira issue'), making the action unambiguous. Among siblings, it clearly distinguishes from jira_add_worklog (which adds) and other get tools by the unique resource 'worklog entries'.
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 related tools such as jira_add_worklog, leaving the usage context entirely to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already provide destructiveHint=true, so the agent knows the tool mutates state. The description adds the context that transitions, comments, and worklogs are optional side effects, but it does not disclose any consequences (e.g., status changes trigger notifications, worklogs affect time tracking). With annotations covering the safety profile, 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 one sentence, front-loaded with the primary action, and immediately informs about optional capabilities. 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?
Given the rich schema (all parameters documented) and the presence of an output schema, the description is largely sufficient. It communicates the core scope and optional bundled actions. However, it does not mention whether the optional actions are atomic or how they interact, but this is a minor gap given the complete structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameters with detailed descriptions, so the description does not need to compensate. The one-sentence description adds no information beyond the schema, but the schema already provides examples, formats, and usage tips for each parameter, making the baseline 3 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 'Update an issue and optionally transition, comment, and log work' clearly specifies the verb (update), the resource (issue), and the optional additional actions. This distinguishes the tool from single-purpose siblings like jira_transition_issue and jira_add_comment, as it is a combined update/transition/comment/worklog tool.
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 explicit guidance on when to use this tool versus the many specialized siblings that perform the same individual actions (transition, comment, worklog). While it implies that multiple actions can be combined, it does not state when to prefer this tool or when to use the dedicated ones instead, leaving the agent without clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers safety, so the description only adds the board scope and JQL filtering. It does not disclose that 'all issues' is subject to limit/pagination (limit max 50) or clarify any nuances like default field selection. The description adds some value but not rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero filler. It states the core purpose efficiently and earns its place 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?
Given the rich schema, output schema, and readOnly annotation, the minimal description is mostly sufficient for understanding the tool's function. However, with six parameters and closely related sibling tools, a bit more context on tool selection or pagination would improve completeness. It is adequate but leaves room for improvement.
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%, meaning all six parameters are well-documented in the schema. The description's mention of 'filtered by JQL' adds no new information beyond what the jql parameter description already provides. No compensation needed, but also no added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get'), resource ('issues linked to a specific board'), and modifier ('filtered by JQL'). This distinctly differentiates it from siblings like jira_search (all issues), jira_get_project_issues, and jira_get_sprint_issues.
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 board scope, but the description does not explicitly state when to prefer this over alternatives like jira_search or jira_get_project_issues. No exclusions or alternative tools are mentioned, leaving the agent to infer selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description ('Get comments') is consistent with a read-only operation. However, the description adds no further behavioral context such as pagination, ordering, or whether inline comments are included. It relies on the annotation for safety, meeting the baseline without enhancement.
Agents need to know what a tool does to the world before 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 words. It efficiently conveys the tool's purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, read-only, output schema present), the description is mostly complete. However, it does not clarify the distinction between regular comments and inline comments (handled by a sibling tool), which could cause confusion for the agent. This minor gap 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?
The input schema provides 100% coverage with a detailed description for page_id, including URL parsing guidance. The tool description's mention of 'a specific Confluence page' 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 clearly states the tool retrieves comments for a specific Confluence page, using a specific verb ('Get') and resource ('comments') with a target. This distinguishes it from siblings like confluence_get_inline_comments and confluence_get_page.
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 for fetching page comments, but it does not explicitly state when to use it over alternative tools such as confluence_get_inline_comments. There is no mention of exclusions or when-not-to-use scenarios, so the guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds the scope of content types (pages, blog posts, attachments). It does not disclose pagination, sorting, or failure behavior, but given the output schema and simple nature, this is acceptable. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-formed sentence that is front-loaded with the verb and resource. It provides essential scope details without any 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 one-parameter read-only tool with a rich schema and output schema, the description is sufficiently complete. It covers the content types and the schema covers parameter details. Error handling and edge cases are not described, but those are less critical given the 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 coverage is 100%, and the page_id parameter description is thorough, including ID formats for different content types (numeric, 'att' prefix). The tool description adds little beyond what is already in 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 clearly states the operation (get labels) and the resource (Confluence content: pages, blog posts, or attachments). It distinguishes from sibling tools by focusing specifically on labels, and the title 'Get Labels' aligns perfectly with 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 use case (retrieving labels) but does not explicitly contrast with the write counterpart confluence_add_label or other content retrieval tools. There is no when-not-to-use guidance, but the context is reasonably clear for a simple read operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers the safety profile. The description adds the behavioral detail that the page can be retrieved via either ID or title+space key, but it does not mention behavioral options such as metadata inclusion or markdown conversion (though these are documented in the input schema). No contradictions with annotations, and some additional context is provided, but it does not go beyond what the schema already conveys.
Agents need to know what a tool does to the world before 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, clear and free of unnecessary words. It efficiently communicates the core purpose and identification methods without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple read operation with a detailed input schema and an output schema present. The description adequately covers the essential purpose and identification logic, and the schema handles parameter semantics and return format. It is complete for the tool's complexity, though it could briefly mention that page_id takes precedence or that title requires space_key, but these are already 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% with detailed per-parameter explanations. The tool description merely restates the ID/title+space key relationship already present in the schema, adding no new semantic meaning. Therefore, 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 tool's function: 'Get content of a specific Confluence page' with explicit methods of identification (by ID or by title+space key). This specific verb+resource combination distinguishes it from sibling tools like confluence_get_page_template or confluence_get_page_restrictions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying the two identification methods, but it does not provide explicit guidance on when to use this tool versus alternatives (e.g., using confluence_search when the exact ID or title is unknown). There are no exclusions or comparisons with sibling tools, so the usage context is present but incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already communicates that this is a safe read operation. The description adds the 'unified diff' format detail but does not disclose behaviors like version order requirements, error handling, or output size limits. It does not contradict the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately conveys the tool's purpose. Every word is functional and no unnecessary information is included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with a simple parameter set and an output schema, the description is largely complete. It could benefit from a note on version ordering (e.g., from_version should be older) or a pointer to related tools for history, but these are minor gaps given the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all three parameters, including an example for page_id. The description does not add additional parameter meaning beyond what the schema already provides, so a 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 uses the verb 'Get' with the resource 'unified diff' and specifies the object 'between two versions of a Confluence page'. It unambiguously distinguishes this tool from the many sibling tools, as no other sibling offers diff functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the description and tool name: it is used when a diff between two page versions is needed. However, there is no explicit guidance on when to prefer this over alternatives or any exclusions, such as version ordering or relationship to confluence_get_page_history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The descriptions implies a write operation (replying creates a comment), but annotations only include destructiveHint=false and no readOnlyHint. The description doesn't add details about permissions, side effects, or what happens to the thread. 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, concise sentence that immediately conveys the tool's function. It contains no filler or redundant information, scoring high on efficiency.
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 tool with a full input schema and an output schema, the description is sufficient. It clearly states the operation and scope, though it could mention that it's a mutating action. Still, the context is complete enough for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full descriptions for both parameters (comment_id and body), covering type, format (Markdown), and meaning. The description doesn't add any additional semantic value beyond what the schema states. 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 identifies the action ('Reply'), the resource ('existing comment thread'), and the context ('on a Confluence page'). This distinguishes it from the sibling tool 'confluence_add_comment', which presumably adds a new top-level comment, by specifying 'existing' thread.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'existing comment thread' implies this tool is for replies, not for creating new top-level comments. However, it does not explicitly name alternatives or provide when-not-to-use guidance. The context is clear but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose any behavioral traits beyond the annotation readOnlyHint=true. It only states the search capability without mentioning fallback behavior, pagination, result format, or quoting quirks. These details are present in the schema but not in the tool description itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence with no unnecessary words. It is front-loaded with the verb and resource, making it immediately clear what the tool does.
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 description is minimal, but the input schema provides comprehensive parameter documentation and there is an output schema, so an agent has enough information to invoke the tool correctly. The description could add high-level context about result scoping, but the structured data fills the 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%, with detailed descriptions for all three parameters, especially the query param with many CQL examples. The tool description only says 'simple terms or CQL', which adds no meaning beyond what the schema already 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 the specific verb 'search' and identifies the resource as 'Confluence content', with the method being 'simple terms or CQL'. This clearly distinguishes it from sibling tools like confluence_search_user, which searches for users, and jira_search, which searches Jira content.
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 that this tool is for searching Confluence content, implying it should be used for content rather than users or Jira items. However, it does not explicitly state when not to use it or mention alternatives, so it lacks explicit 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 annotations only provide destructiveHint:false, which is minimal. The description adds no additional behavioral context, such as idempotency, permissions required, or what happens if the user is already a watcher. It does not contradict the annotations, but it does not go beyond the obvious 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 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, the presence of an output schema, and a non-destructive annotation, the description is adequate. It states the purpose and the schema covers the rest. It does not explain permissions or error cases, but these are not essential for a simple add-watcher 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 well-described parameters (issue_key pattern and user_identifier platform guidance). The description adds no further parameter semantics, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Add'), a direct object ('a user as a watcher'), and a clear target ('a Jira issue'). It unambiguously distinguishes this tool from sibling tools like jira_get_issue_watchers and jira_remove_watcher.
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 action is immediately clear from the description, leaving no doubt about when to use it. However, it does not explicitly mention exclusions or alternatives, such as 'use jira_remove_watcher to remove a watcher.' This is a minor gap, but the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation already marks destructiveHint=true, signaling a write operation. The description adds no additional behavioral context beyond that, but it aligns with the annotation. Since the description does not reveal side effects like estimate updates or permission requirements, a mid-range score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no filler or redundancy. It is front-loaded with the action and resource, making it immediately understandable.
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 comprehensive schema, presence of an output schema, and straightforward behavior, the description is largely sufficient. It could optionally mention interactions with estimates or required permissions, but these are not critical given the additional structured information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with detailed descriptions for all six parameters, including formats and examples. The description itself adds no parameter information, so the baseline of 3 holds.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Add' and the resource 'worklog entry to a Jira issue,' making it distinct from jira_get_worklog and other issue-related tools. It precisely conveys the action 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 its use for logging time on an issue, but it does not explicitly state when to use this tool over alternatives (e.g., jira_add_comment) or provide exclusions. There is no guidance on prerequisites or scenarios where it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the tool's safety profile is covered. The description adds no extra behavioral context beyond the purpose (e.g., permissions, output details). It is consistent with the annotation, making this score acceptable but not exceptional.
Agents need to know what a tool does to the world before 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 and efficiently communicates the tool's function without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, read-only, with complete schema coverage and output schema), the description is sufficient. A small enhancement could mention the return format, but the output schema exists, so the description need not explain it. Overall, complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter issue_key, including a pattern and example. The description adds no parameter-level details 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 'Get the list of watchers for a Jira issue' clearly states a specific verb ('Get') and resource ('list of watchers'), distinguishing it from sibling tools like jira_add_watcher, jira_remove_watcher, and jira_get_issue. 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 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 (whenever you need the watchers of an issue) but provides no explicit alternatives or exclusions. Given the presence of related sibling tools (add/remove watchers), more explicit guidance would improve the score, but a clear context is still conveyed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so the safe-read nature is known. The description adds context about the new Jira Forms REST API and the ADF design structure in the return, but lacks details on error behavior, prerequisites, or response format beyond the annotations/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?
Two concise sentences, front-loaded with the main purpose and adding relevant context about the API and return content. 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?
Given the low complexity (2 parameters, no nested objects) and the presence of an output schema, the description is largely complete. It mentions the key output aspect (ADF design structure), though it could have briefly noted that the form is associated with an issue, but the issue_key parameter covers that.
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 documentation coverage is 100%, with both parameters adequately described. The description does not add meaningful semantic details 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 clearly states 'Get detailed information about a specific ProForma form', which is a specific verb+resource. It distinguishes from sibling tools like jira_get_issue_proforma_forms (which lists forms) by emphasizing 'specific form' and 'detailed information'.
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 detailed form info, but does not explicitly mention alternatives or exclusion criteria. No reference to sibling tools such as jira_get_issue_proforma_forms or jira_update_proforma_form_answers, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation is present and the description does not contradict it. The description adds the service desk scope but does not disclose pagination behavior, result shape, or any additional constraints beyond what annotations already 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 that immediately states the action and resource, with no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with complete parameter schema, readOnlyHint annotation, and an output schema, the description provides adequate context. It does not explain pagination (already in schema) or explicitly differentiate from sibling tools, which would elevate it further.
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 parameters (service_desk_id, limit, start_at). The description does not add parameter-level semantics beyond the schema, which already fully explains each field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets request types for a Jira Service Management service desk. It uses a specific verb and resource, and distinguishes itself from the sibling 'jira_get_request_type_fields' by focusing on types rather than fields.
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 request types for a service desk are needed, but provides no explicit when-to-use vs alternatives, exclusions, or guidance on choosing between this and related tools like jira_get_request_type_fields.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description doesn't need to restate safety. It adds one useful behavioral fact: the tool is unavailable on Jira Cloud, which will affect invocation. Other behaviors (pagination, error conditions) are not disclosed, but the description is 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?
Two short sentences: the first states the core purpose, the second adds a critical platform restriction. No filler or repetition. Information is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list operation, the description is nearly sufficient. It states the purpose, gives the essential platform constraint, and an output schema exists (so return details are covered). Missing is a hint about pagination or integration with sibling tools (e.g., getting queue issues), but these gaps are minor given the schema and 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% – each parameter (limit, start_at, service_desk_id) already has a clear description in the schema. The tool description adds no extra parameter explanation. Baseline 3 is appropriate 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?
Clearly states it 'Get queues for a Jira Service Desk' – a specific verb and resource. Distinguishes from siblings like jira_get_queue_issues (which gets issues in a queue) and jira_get_service_desk_for_project (which gets the service desk for a project). The platform note adds precision without diluting purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear usage constraint: 'Server/Data Center only. Not available on Jira Cloud.' This tells when NOT to use it but does not explicitly compare to alternatives like jira_get_queue_issues or jira_get_service_desk_for_project. No direct sibling differentiation or work-flow guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, so the tool's safety profile is known. The description adds the 'Cloud only' environmental constraint, which is not in the annotations. However, it does not disclose any performance implications or the fact that the limit parameter still fetches all data (that nuance is in the schema, not the description). Thus, it adds some but not substantial 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, well-structured sentence with no filler. It front-loads the primary action and resource, then provides a necessary qualifier. Every word earns its place, achieving maximum conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, read-only batch tool with a fully specified schema, an output schema, and a readOnlyHint annotation, this one-sentence description is sufficient. It names the operation and key scope, and the structured fields cover the rest. No critical gaps remain.
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%, meaning all three parameters (issue_ids_or_keys, limit, fields) have descriptions in the schema. The description itself contributes no parameter-specific meaning beyond referencing 'multiple Jira issues'. Given the full schema coverage, the baseline of 3 is appropriate; the description 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 clearly states the tool's function: 'Get changelogs for multiple Jira issues'. It uses a specific verb ('Get'), identifies the resource ('changelogs'), and specifies the scope ('multiple Jira issues'). The addition of '(Cloud only)' distinguishes it from potential on-premise versions, making it unambiguous among sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/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 implies usage for batch changelog retrieval but does not mention exclusions or substitute tools. The 'Cloud only' constraint offers some context but does not serve as comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers the safety profile, and the description adds minimal behavioral context beyond stating it returns all available types. No information on pagination, ordering, or other behavioral traits is provided, but none is expected for a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler or redundancy, front-loaded with the core action and resource. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only lookup with one optional parameter and an output schema, the description fully captures the tool's purpose. No additional context is necessary given the output schema and 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?
The schema provides 100% coverage for the single parameter name_filter, so the description does not need to add parameter details. The parameter is self-explanatory and the schema description is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and a clear resource 'issue link types', fully stating its purpose. It distinguishes itself from sibling tools by targeting a unique resource not covered elsewhere.
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 as a straightforward lookup for link types, but provides no explicit guidance on when to use it or any exclusions. While alternatives are not relevant, there is no discussion of use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already indicates a safe read operation, and the description adds no extra behavioral context such as return format, pagination, or potential empty results. It is not misleading, but it does not enrich beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is front-loaded and contains no redundant wording. It is appropriately concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one required parameter, full schema coverage, an output schema, and a read-only annotation, the one-line description is sufficient. No additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the project_key parameter is fully described with pattern and example. The description only reinforces 'specific Jira project' without adding new semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'all components for a specific Jira project', which is specific enough to distinguish from sibling tools like jira_get_project_versions or jira_get_project_issue_types. The phrasing 'for a specific Jira project' also signals the required input.
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 use case (when you need components of a project) but does not explicitly mention when to use this tool over alternatives or provide any exclusions. No comparison is made with similar tools such as jira_get_project_versions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with the readOnlyHint annotation, indicating a safe read operation. However, it adds no additional behavioral context beyond the annotation, such as dependency on issue status or permissions. The annotation already covers the read-only nature, so a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that earns its place. It is front-loaded and contains no redundancy or extra fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an existing output schema. The description sufficiently explains what the tool does, and the output schema covers return values. No further context is needed 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 provides 100% coverage with a detailed description for issue_key, including pattern and example. The description adds no extra parameter semantics 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 uses a specific verb ('Get') and resource ('available status transitions') tied to a Jira issue. It clearly identifies this as a read-only retrieval operation, distinguishing it from sibling tools like jira_transition_issue that perform the actual transition.
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 fetching transition options before performing a transition, but it does not explicitly state when to use it or mention alternatives. The sibling context suggests jira_transition_issue for performing transitions, but the description itself lacks this guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares this as a read operation, and the description aligns with that ('Retrieve'). The description adds no extra behavioral context such as permissions, response size, or rate limits, but it does not contradict the annotation. Since annotations cover the safety profile, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly one sentence, front-loaded with the main action and resource, with zero redundant words. It is perfectly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool, the description combined with the rich input schema, output schema, and readOnlyHint annotation provides complete context. No additional prerequisites or limitations are necessary to understand the tool's function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; the parameter user_identifier has a detailed description with examples (email, username, account ID, Server/DC key). The tool description adds no extra meaning beyond reinforcing that it's for a specific user, so the high schema coverage earns 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 'Retrieve profile information for a specific Jira user' uses a specific verb ('retrieve') and a clear resource ('profile information' for a user). It distinguishes itself from sibling tools like jira_search_assignable_users by emphasizing a specific user with an identifier, not searching or assigning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for a specific Jira user' implies the tool is used when you already know the target user. However, the description does not explicitly state when to choose this over alternatives (e.g., jira_search_assignable_users to find a user, or confluence_search_user for Confluence users) nor provide any exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, and the description adds the behavior of being anchored to a text selection. However, the description doesn't disclose additional behavioral details such as requirements for exact text matching or potential side effects. With annotations covering the safety profile, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
This is a single sentence that immediately conveys the tool's purpose with no extraneous information. It is front-loaded and every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the full schema coverage, the destructiveHint annotation, and the presence of an output schema, the short description is sufficient. It could mention prerequisites like exact text match, but the schema already covers that, so the description adequately supports 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?
The input schema provides complete descriptions for all 5 parameters (100% coverage), so the description doesn't need to elaborate on parameter meanings. It adds no value beyond the schema, thus the baseline score of 3 is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Add an inline comment anchored to a text selection on a page,' which clearly specifies the verb (Add), the resource (inline comment), and the unique anchoring to a text selection. This distinguishes it from sibling tools like confluence_add_comment and confluence_reply_to_comment.
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 an inline comment needs to be attached to specific text on a page. It doesn't explicitly mention alternatives or exclusions, but the 'anchored to a text selection' phrasing provides unambiguous context for when this tool should be selected over a general comment 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?
Annotations declare destructiveHint=false, and the description aligns by describing a non-destructive mutation. However, the description does not disclose permission requirements, idempotency, or behavior with duplicate labels. Since annotations already cover the core safety profile, 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 front-loaded with the purpose and then uses a concise bullet list for use cases. Every sentence earns its place; no fluff or redundancy. Ideal size for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose and usage context well for its low complexity. An output schema exists, so return values are defined. It could mention duplicate label behavior, but this is a minor gap and not critical for agent selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with detailed parameter descriptions (e.g., page_id format with 'att' prefix, label name examples). The description itself adds no additional parameter semantics, so the 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?
Clearly states the tool adds a label to Confluence content, specifying the resource types (pages, blog posts, attachments) and distinguishing it from sibling tools like confluence_get_labels or confluence_add_comment. The verb 'Add' and resource 'label' are concrete 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?
Provides explicit use cases (categorizing attachments, tracking status, filtering) that give the agent clear guidance on when this tool is appropriate. It lacks explicit exclusions or alternatives, but the context is sufficient for a simple labeling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description's 'Search' action is consistent. The description adds behavioral context about API method selection (CQL for Cloud, group member API for Server/DC), which annotations don't cover, and there is no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the core action and resource, no redundant 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?
With an output schema present and read-only annotation, the tool is sufficiently specified. The API variant note and schema's param docs cover the main contexts; minor extra details like permission requirements are absent but not critical for a search 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 detailed descriptions, including CQL examples and group_name behavior. The description does not add 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 states a specific action ('Search') and a specific resource ('Confluence users'), clearly distinguishing from siblings like confluence_search (content) and jira_search_assignable_users (Jira users). Mention of CQL vs group member API adds further specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for finding Confluence users but does not explicitly contrast with alternative user-search tools like jira_search_assignable_users. It lacks explicit when-to-use or exclusions, though the platform-specific API mention provides some context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint: true, so the read-only nature is covered. The description adds behavioral detail by specifying the exact types of dates returned (created, updated, due date, resolution date) and the optional inclusion of status change history with time tracking. This goes beyond the bare annotation and clarifies the tool's output scope, though it does not discuss permissions, rate limits, or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, front-loaded with the main purpose, followed by specific details on return values. Every sentence earns its place, with no redundant phrases or fluff. 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 params, 1 required), the presence of an output schema (not shown but indicated), and readOnlyHint annotation, the description covers the essential what and why. It mentions the return value (dates and optional status history) and a use case ('workflow analysis'). However, it lacks explicit comparison to sibling tools or guidance on when not to use it, which would make it fully self-contained.
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 three parameters, so the schema already explains each parameter. The description adds minimal extra meaning by mentioning 'optionally status change history' and 'time tracking,' which loosely aligns with the include_status_changes and include_status_summary booleans, but it does not provide syntax, defaults, or examples beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get date information and status transition history for a Jira issue.' It identifies a specific verb ('Get') and resource ('Jira issue') and distinguishes itself from sibling tools like jira_get_issue (full issue details), jira_get_transitions (available transitions), and jira_get_worklog (worklog entries) by focusing on dates and status history.
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 workflow analysis and retrieving date-related fields, but it does not explicitly state when to use this tool instead of alternatives like jira_get_issue or jira_get_transitions. No exclusions or alternative guidance is provided, so it relies on the user to infer the appropriate use case from the niche it fills.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds useful context by mentioning the 'new Jira Forms REST API' and that 'Form IDs are returned as UUIDs.' This goes beyond the annotation by disclosing the API version and return format, though it does not cover pagination or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and adds relevant behavioral context in the second sentence. There is no wasted or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema present, annotations provided), the description is adequately complete. It covers what the tool does, the API used, and return format. It could mention alternatives or edge cases, but that is not essential given the rich structured data.
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 only parameter (issue_key) with a clear description and example. The tool description does not add any additional parameter semantics, 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 ('Get') with a clear resource ('all ProForma forms') and scope ('associated with a Jira issue'). It distinguishes from sibling tools like jira_get_proforma_form_details, which would focus on a single form's details rather than listing all forms 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 Guidelines3/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 you need all forms for an issue), but it does not explicitly mention alternatives or exclusions. Given the presence of a closely related sibling (jira_get_proforma_form_details), the lack of explicit differentiation is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so the safety profile is known. The description adds behavioral context by listing the environment variables that control working hours, which affects calculation results, and by enumerating available metrics. This goes beyond the schema and annotations, though it doesn't discuss rate limits or response structure (covered by 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 concise and front-loaded with the core purpose, followed by metric examples and a structured env var list. Each sentence serves a purpose; no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and readOnly annotation, the description sufficiently covers the tool's function, configuration, and metric types. It doesn't cover usage guidance or edge cases, but for a read-only metric calculator, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, with all four parameters fully described. The description adds no new parameter-level semantics beyond what the schema already provides; it only references the env var list globally. Thus 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 opens with 'Calculate SLA metrics for a Jira issue,' a specific verb+resource statement that clearly distinguishes this from sibling tools like jira_get_issue (which fetches issue details) and jira_get_issue_dates (which likely returns raw dates). It lists example metrics, reinforcing its unique purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for computing time-based SLA metrics but provides no explicit when-to-use or alternatives. It doesn't state when to use this versus other issue tools, leaving the agent to infer from the verb 'calculate' and metric names. No exclusions or comparisons are made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare destructiveHint=true, and the description aligns with that. The description does not add much beyond what the title and schema already convey, such as irreversibility or the distinction between username/account_id for Jira Server vs Cloud, though the schema does cover those details.
Agents need to know what a tool does to the world before 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 filler. It is appropriately sized for the tool's simplicity and front-loads the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple remove-watcher tool, the description plus schema and annotations are fairly complete. It might benefit from noting that username and account_id are mutually exclusive depending on Jira type, but the schema descriptions already indicate the intended use and the output schema is present.
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%: each parameter has a description (e.g., 'Username to remove (for Jira Server/DC)', 'Account ID to remove (for Jira Cloud)'). The tool description itself adds no parameter-level semantics, 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 'Remove a user from watching a Jira issue' uses a specific verb (remove) and clearly identifies both the resource (watcher/user) and the target (Jira issue). It distinguishes this tool from the sibling tools jira_add_watcher and jira_get_issue_watchers.
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 you want to remove a watcher from an issue) and the context is unambiguous. However, it does not explicitly mention alternatives or exclusions, though sibling tool names partially fill that gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is known. The description adds the 'all' scope but does not disclose potential pagination, ordering, or how inline comments are returned. This is acceptable but not richly transparent.
Agents need to know what a tool does to the world before 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 the essential purpose without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter), the provided annotations (readOnlyHint=true), and the presence of an output schema, the description is complete enough for selection and basic invocation. No additional context is necessary.
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 page_id has 100% schema coverage with its own description. The tool description adds no additional parameter context, so it relies fully on 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 all inline comments for a Confluence page' clearly states a specific verb, resource, and scope. It distinguishes itself from sibling tool confluence_get_comments by explicitly focusing on inline 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 clearly indicates when to use the tool: to retrieve inline comments for a Confluence page. It does not explicitly name alternatives or exclusions, but the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already identifies this as a read operation, and the description adds value by explaining that it returns 'current restriction lists' and that an empty list means unrestricted. This gives the agent important interpretation context beyond the annotation, though it does not discuss pagination, authentication, or other edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the purpose and then adding a key interpretation detail. Every word earns its place, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter, a clear read-only annotation, an output schema, and a description that explains the return semantics (restriction lists and empty list meaning). This is sufficient for an agent to select and invoke the tool correctly without 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 covers 100% of parameters with a clear description ('The ID of the page'), so the baseline is 3. The description does not add further meaning to the page_id parameter, but also does not need to since the schema is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 ('view and edit restrictions for a Confluence page'), clearly distinguishing it from sibling tools like confluence_set_page_restrictions and confluence_check_content_permissions. It also clarifies the two operations (read/view and update/edit).
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 (to retrieve current restrictions) but does not explicitly state when to use this tool versus alternatives such as confluence_set_page_restrictions or confluence_check_content_permissions. There are no exclusion criteria or alternative recommendations, leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare readOnlyHint=true, so the read-only nature is already covered. The description adds the detail that the body is in storage format, which provides some insight into the return content, but it does not disclose other behavioral aspects like authentication requirements or rate limits. This is consistent with the annotation, and the additional context is modest.
Agents need to know what a tool does to the world before 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 that immediately states the action and key detail about the body. It is front-loaded with the verb and resource, and every word earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema present), the description fully covers the necessary context. It specifies the cloud variant and the body format, which is sufficient for an agent to invoke the tool correctly. No additional details are needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single parameter `template_id` with a clear description. The tool description's mention of 'by ID' adds no semantic information beyond what the schema already provides. With 100% schema coverage, 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 verb 'Get', the resource 'Cloud page template', and the scope 'by ID', while also specifying that it includes the storage-format body. This distinguishes it from sibling tools like 'confluence_list_page_templates' and 'confluence_create_page_from_template' by focusing on retrieving a single template by its identifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you need a specific template by its ID and want its body content. It does not explicitly mention alternatives or exclusions, but the 'by ID' phrasing makes the use case clear enough without conflicting with listed sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=true, so the safety profile is already covered. The description adds the Cloud-only availability and the reliance on the Analytics API, which is useful context. However, it does not disclose details like what 'view statistics' includes (e.g., time period, unique vs total views) beyond what the output schema might provide. With annotations present, 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 two short sentences. The first sentence states the purpose, and the second gives an important availability note. No wasted words, and the critical information is front-loaded. Excellent structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two well-documented parameters and an output schema. The description covers the core purpose and a key limitation (Cloud-only). Since an output schema exists, there is no need to describe return values. The description is complete for an agent to decide to use this tool for page view analytics.
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 page_id and include_title have descriptive text in the schema. The description adds no new parameter semantics beyond what the schema already provides. Baseline of 3 is appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get view statistics for a Confluence page.' It uses a specific verb ('Get') and a specific resource ('view statistics for a Confluence page'), which distinguishes it from sibling tools like confluence_get_page (which fetches page content) and confluence_get_comments. No 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 provides a clear usage constraint: it is only available for Confluence Cloud, not Server/Data Center instances. This tells the agent when not to use it. However, it does not explicitly contrast with alternatives or state when to prefer this tool over others, 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?
Annotations already declare readOnlyHint=true, and the description adds the behavioral detail that the tool includes Epic links and relationship information. It also notes that enrichments can be inlined via the 'include' parameter, which is useful. The schema's 'update_history' parameter implies a side effect, but the description does not contradict the annotation, so no red flag is raised.
Agents need to know what a tool does to the world before 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 concise sentences that front-load the core action and then provide one additional useful tip about the 'include' parameter. Every word earns its place, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value details are covered. The description mentions the critical aspects (specific issue retrieval, Epic links, inline enrichments) while the rich schema descriptions handle parameter details. For a read-only lookup tool, this is a complete and well-rounded description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each of the 8 parameters thoroughly described in the schema. The tool description adds value by explaining the purpose of the 'include' parameter in avoiding separate calls, but it does not add semantic meaning to other parameters. The schema carries the heavy lifting, 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 'Get details of a specific Jira issue' with a specific verb and resource. It further distinguishes itself from broader tools like 'jira_search' or 'jira_get_project_issues' by mentioning 'Epic links and relationship information' and the ability to inline enrichments. This is a precise, non-tautological purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains that the 'include' parameter can inline remote_links, transitions, watchers, changelog, comments, and worklogs 'so that separate tool calls are not needed.' This provides clear context on when to use this tool as a consolidated fetch versus making separate calls to sibling tools like jira_get_worklog or jira_get_issue_watchers, though it does not name these alternatives explicitly.
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 readOnlyHint=true, the safety profile is already covered. The description adds that it batch retrieves PRs, commits, and branches, disclosing the data scope. It does not mention pagination, rate limits, or performance implications, but the annotation lowers the bar for 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 two focused sentences, front-loaded with the purpose and clarifying the batch behavior. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only batch retrieval tool with a full input schema and an output schema, the description sufficiently covers the purpose, scope, and data categories. No critical information is missing for an agent to select and 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?
All three parameters have full descriptions in the schema (100% coverage). The description's mention of PRs, commits, branches aligns with the data_type parameter but adds no new detail beyond what the schema already provides, so it meets the baseline without extra compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and resource ('development information') and clarifies batch scope for 'multiple Jira issues'. It distinguishes from the singular sibling tool jira_get_issue_development_info by emphasizing '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 implies a batch use case: 'for multiple issues at once' suggests it is intended for bulk operations, contrasting with the singular alternative. However, it does not explicitly name that alternative or provide when-not guidance, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation already declares readOnlyHint=true, so the safety profile is known. The description adds that it returns a list of creatable issue types and mentions IDs, but doesn't disclose pagination, permissions, or error behavior. This is acceptable but not rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short paragraphs: the first states the purpose, the second explains the return value and a critical next-step usage. Every sentence adds value, no filler or repetition of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only getter with one documented parameter and an output schema, the description fully covers what the tool does, what it returns, and how to use it downstream. Complete for its complexity level.
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 the project_key parameter. The description only restates that the project is 'specified' via the key, adding little beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and resource 'available issue types for a Jira project', clearly distinguishing it from sibling tools like get_request_types or get_project_fields. It adds detail that issues are those 'that can be created' in the project, pinpointing its exact scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent to use the returned issue type IDs with get_create_fields to discover required fields, giving a concrete use case and pointing to a complementary tool. It doesn't state when not to use the tool, but the guidance is clear enough for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key behavioral trait beyond the annotations: it removes issues from any sprint. This is valuable context for a mutating operation (readOnlyHint=false). It doesn't cover permissions or reversibility, but the sprint-removal detail provides meaningful transparency beyond the structural 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 that leads with the verb and target. Every word earns its place; there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter, an output schema, and no nested objects, the description fully covers the necessary context. It states the primary action and the side effect (sprint removal), and the output schema handles return value details, so nothing critical is 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 coverage is 100% for the single parameter issue_keys, which already includes a clear example format. The description adds no further parameter-specific details, so it meets the baseline but doesn't exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Move issues to the backlog') and adds the specific consequence ('removing them from any sprint'), which distinguishes it from more general tools like jira_move_issue. The verb and target are 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the intent is to place issues in the backlog and pull them out of sprints, but it doesn't explicitly say when not to use it or mention alternatives. Given there is a sibling tool jira_move_issue that could overlap, the lack of contrast leaves guidance implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include destructiveHint=true, indicating potential destructive impact. The description adds meaningful behavioral detail beyond this: it discloses that Cloud uses a native copy endpoint while Server/DC fetches the body and creates a new page, and that attachments are skipped on Server/DC. This transparently surfaces platform-specific behaviors that are not in the annotations or 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 compact, front-loaded with the purpose, and every sentence adds value. The first sentence states the core function, the second explains platform-dependent behaviors. No redundant or filler 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?
For a copy operation with 5 parameters and an output schema, the description sufficiently explains the key behavioral differences (Cloud vs Server/DC, attachment handling). It does not detail edge cases like duplicate title handling or permission requirements, but the provided information is adequate for basic usage. The output schema covers return values, and annotations cover safety hints, leaving the description to focus on the operation's core 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 the baseline is 3. The description does not add new meaning beyond the schema; it mentions attachment copying in the context of platform differences, which aligns with the copy_attachments parameter description but does not extend it. The parameter details are already well-documented in the schema, so no additional value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Copy a Confluence page to a new location' with a specific verb and resource. It distinguishes the tool from siblings like move_page or create_page by explicitly focusing on copying. The additional platform-specific implementation details further clarify 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear behavioral context for Cloud vs Server/DC, including the limitation that attachments are not copied on Server/DC. This informs usage decisions (e.g., if attachments are critical, the Server/DC path is insufficient), but it does not explicitly name alternative tools or state when not to use this tool. The context is solid though 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?
The description adds behavioral context beyond the annotations, such as the Cloud-only restriction, the fact that it fetches the template and uses storage-format content, and that the page is editable afterwards. It doesn't disclose permission requirements or side effects, but given the straightforward create operation and the destructiveHint=false annotation, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each with a clear purpose: summary, scope, and behavior/follow-up. No redundant wording. The description is short 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 a well-documented schema and an output schema, so the description doesn't need to detail return values. It covers the operation's scope (Cloud-only), behavior, and a suggested next step. It doesn't cover error conditions or prerequisites, but for a simple create operation this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all parameters with 100% coverage, so the description doesn't need to add parameter details. It does provide a slight nuance by saying it fetches the named template, which aligns with template_id. This meets the baseline but doesn't significantly enhance 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 clearly states the verb (create), resource (page), and the key distinction from siblings (pre-populated from a template). It also notes Cloud-only availability, which differentiates from other Confluence operations. This is a specific and unambiguous definition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context: use this to create a Cloud page from a template, and the result can be edited via confluence_update_page. However, it doesn't explicitly mention when to use this over confluence_create_page or when not to use it, so it lacks explicit exclusion or alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true already indicating safety, the description adds valuable behavioral context: it returns parent_id and depth attributes, is designed for 'token-efficient processing,' and is 'much more efficient than rendering full ASCII trees.' It doesn't discuss pagination limits or error behavior, but the annotation covers the primary safety trait, so this is a solid 4.
Agents need to know what a tool does to the world before 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 at five sentences, front-loading the core purpose immediately. Each sentence adds something: purpose, return attributes, usage tips, efficiency, and a use case. There is no repetition, filler, or tangential 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 description, combined with the annotation and full schema coverage, covers the tool's purpose, output shape (parent_id, depth), and recommended use case. An output schema exists, so return value details don't need to be in the description. Only minor gaps like pagination behavior are not explicitly mentioned, but the limit parameter covers that. It is complete enough 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?
The schema already describes both parameters (space_key and limit) with 100% coverage, including a default and max for limit. The description doesn't add extra parameter-level meaning; it does mention filtering by depth, but 'depth' is not an input parameter in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Get page hierarchy for a Confluence space as a flat list,' which clearly specifies the verb (Get), resource (page hierarchy for a Confluence space), and output format (flat list). It also distinguishes this from sibling tools like get_page or get_page_children by focusing on the entire space hierarchy, not just a single page or direct children.
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 usage context: 'Use this to understand space organization before creating/moving pages.' It also gives practical tips like 'Filter by depth to focus on relevant sections, or find pages by title.' However, it doesn't explicitly mention when to avoid this tool or name alternatives, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers safety, and the description adds return format details: 'results' list with principal, operation, and target. Also discloses the API wrapper and cloud-only limitation, which is useful 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?
Four concise sentences plus a note, each providing a distinct piece of information: purpose, endpoint, platform limitation, return format, and use case. 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?
With an output schema present and readOnlyHint annotation, the description covers the core return structure and use case. It could optionally mention pagination behavior, but the cursor and limit params in the schema cover that.
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 space_id described in detail including how to find it. The description adds no additional parameter semantics beyond what the schema already provides, 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 clearly states 'List all permission assignments for a Confluence space' with a specific verb and resource, and adds an audit use case. It distinguishes from content-permission tools by specifying 'space' level permissions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly notes the tool is only for Confluence Cloud, excluding Server/Data Center, and frames the purpose as auditing space access. It doesn't name alternatives but the cloud-only note provides clear when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide destructiveHint=true, and the description adds crucial scoping: it replaces only the content beneath a named heading and leaves all other sections, macros, layouts, and Confluence-specific elements intact. This precisely defines the destructive footprint and explains the safety benefit. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences. The first sentence states the purpose directly; the second elaborates on scope and rationale. Every sentence earns its place, with no fluff or repetition. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides enough context for an agent: the tool is destructive but scoped, the rationale for use, and the key behavior. Combined with rich schema and output schema, it is complete for decision-making. A minor gap is no mention of error behavior if the heading is not found, but that is not essential.
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 provides detailed parameter explanations (e.g., new_content must not include the heading; content_format choices). The description adds some conceptual context by framing the operation in terms of 'section' and 'named heading,' but this is largely redundant with the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Update a single section of a Confluence page without affecting the rest.' It clearly distinguishes from sibling tools like confluence_update_page by emphasizing section-level granularity and contrasting with full-page round-trip updates. The scope 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 description gives a clear when-to-use rationale: update a section while preserving other Confluence elements, avoiding the data loss from full-page Markdown round-trip. It implies when not to use (when a full-page update is acceptable), but does not name alternative tools explicitly, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the key behavioral trait of versioning: 'If the attachment already exists (same filename), a new version is created.' This goes beyond the destructiveHint annotation by explaining the specific mutation behavior. It also clarifies the base64 mode is for remote/containerized servers. No contradiction with annotations found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening sentence, a concise paragraph on input modes, and a bulleted list of use cases. No redundant or filler content; every sentence contributes meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich schema and output schema, the description does not need to explain return values. It adequately covers the tool's purpose, input exclusivity, versioning behavior, and use cases. It is complete enough for an agent to understand when and how to invoke this tool successfully.
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 already covers all parameters (100% coverage), providing detailed descriptions for each. The tool description adds value by stating the mutual exclusivity constraint ('Exactly one of the two must be supplied') and explaining the rationale for the base64 mode. This enhances understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Upload an attachment to Confluence content (page or blog post).' It is specific about the target and the two input modes. However, it does not distinguish from the sibling tool 'confluence_upload_attachments' (plural), leaving ambiguity about whether this tool is for single vs. batch uploads.
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 for when to use the tool, listing concrete use cases ('Attaching documents, images, or files to a page', 'Updating existing attachments with new versions', 'Adding supporting materials to documentation'). It also explains when to use file_path vs. content_base64 based on server environment. However, it does not explicitly mention alternatives or exclusions, such as using the plural upload tool for multiple files or listing attachments with get_attachments.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral details beyond the destructiveHint annotation, such as automatic version creation when files with the same names exist and the fact that all files share the same comment/minor_edit settings. This adds useful context for the agent, though it doesn't address potential failures or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and efficient: a single sentence states the main action, a second addresses efficiency and versioning behavior, and a concise bulleted list provides use cases. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description, combined with the rich schema, destructiveHint annotation, and presence of an output schema, gives the agent sufficient context to invoke the tool safely and correctly. It could have included permission requirements or edge-case failure behavior, but for a batch upload tool, the provided context is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all parameters with detailed descriptions, examples, and defaults (100% coverage). The tool description does not add parameter semantics beyond what the schema already provides, so it meets the baseline for schema-covered 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's purpose: 'Upload multiple attachments to Confluence content in a single operation.' It specifies the verb, resource, and scope, and distinguishes itself from the sibling tool 'confluence_upload_attachment' by noting it is more efficient than calling that tool multiple times.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions an alternative ('More efficient than calling upload_attachment multiple times') and provides a 'Useful for' list with concrete scenarios. However, it does not explicitly state when to use the singular 'upload_attachment' instead, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide destructiveHint=false, so the description carries the burden of adding behavioral context. It does explain that links appear in the issue's 'Links' section and can be clicked to navigate, which is useful UI/behavioral context. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the core purpose, and adds a brief note about the result. No redundant or vague wording; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and the input schema is fully described, the description is sufficient for a straightforward creation tool. It explains what the tool does and the outcome, but could mention optional parameter behavior (e.g., relationship) or edge cases, though not strictly required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the description does not need to add parameter details. The description does not go beyond the schema, which is acceptable per the baseline 3 when schema covers everything.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Create a remote issue link (web link or Confluence link) for a Jira issue.' This is a specific verb+resource+scope. The mention of 'remote' and 'external resources' effectively distinguishes it from the sibling tool jira_create_issue_link, which likely links two Jira issues together.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is for adding web/Confluence links, which implies its use case. However, it does not explicitly state when not to use it or name alternatives like jira_create_issue_link for issue-to-issue links. Thus it has clear context but no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds algorithmic details: fetches all epics, detects parent via parent field or inward issue links, groups by parent, and buckets unlinked epics. This goes beyond the annotation without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, all substantive. The main action is front-loaded, followed by mechanism, edge-case handling, and use case. No filler or repeated schema info.
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 output schema covers return structure, annotations cover safety, and the description explains grouping logic and the 'Unlinked' case. Minor gaps remain around behavior with zero epics or performance implications of max_epics, but these are non-critical for a read-only reporting 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%: both project_key and max_epics are fully described with patterns and ranges. The description adds no extra parameter meaning, so it correctly relies on the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Group a project's epics under their cross-project parent issues.' It clearly distinguishes this tool from siblings like jira_get_project_issues or jira_search by focusing on epic-to-parent grouping and explicitly mentions the 'Unlinked' fallback.
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 final sentence provides clear use context: 'Useful for understanding how a project's epics roll up to initiatives in another project.' It implies when to use this over simpler issue-listing tools, though it does not explicitly name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds useful context not in annotations: the platform restriction (Server/Data Center only). This goes beyond the structured data and helps the agent avoid incorrect invocation on Cloud environments.
Agents need to know what a tool does to the world before 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 concise sentences. The first states the purpose, and the second gives an essential constraint. Every word earns its place; no filler or 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 with a single parameter and an output schema (per context signals). The description covers the purpose and an important availability restriction. It does not need to detail return values since the output schema exists. Minor gap: no mention of error behavior if the project key is invalid, but this is not critical for a read-only getter.
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 the only parameter (project_key), including a pattern and example. The description does not add additional 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Get the Jira Service Desk associated with a project key.' This is distinct from sibling tools like jira_get_service_desk_queues, which focus on queues, and other get_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage constraint: 'Server/Data Center only. Not available on Jira Cloud.' This tells the agent when the tool is applicable and implicitly warns against using it in Cloud environments. It does not explicitly name alternatives, but the constraint serves as a strong guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals a safe READ operation, and the description adds useful context by mentioning the wrapped POST endpoint (surprising for a read, but clarified by 'Check') and the specific return shape ('hasPermission' boolean). It also discloses the Cloud-only platform limitation, which is valuable 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 three short paragraphs that front-load the main action. Every sentence earns its place: the endpoint wrapper, the Cloud-only restriction, and the return value are each conveyed in a single, clear sentence without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple permission-check tool. The description covers the operation's purpose, the API endpoint, platform restrictions, and the return format. With a full output schema and rich input schema already present, the description is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides thorough descriptions for all four parameters, including examples, defaults, and allowed values (100% coverage). The description does not add extra parameter-level detail beyond what the schema already states, 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 opens with a clear action verb ('Check') and a specific resource ('content permissions'), making the tool's purpose immediately obvious. It distinguishes itself from sibling tools like confluence_set_page_restrictions by focusing on checking a permission rather than modifying restrictions.
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 notes the Cloud-only availability, which is an explicit exclusion for Server/Data Center users. It also clearly states that it returns a hasPermission boolean, implying when to use this tool, but it does not explicitly name alternative tools or exclusions beyond the platform note.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint already annotated, the description adds useful behavior: Cloud-only availability and the fact it returns only metadata (ID, name, description, type) without the full body. This goes beyond the annotation without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: the first states purpose, the second adds a key limitation, and the third points to the appropriate sibling for body retrieval. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two optional parameters, an output schema, and a read-only annotation, the description covers all necessary context: what it lists, the Cloud restriction, the metadata-only behavior, and the alternative for full content. The output schema handles return values, so no further detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 additional parameter semantics beyond what the schema already provides; it simply mentions 'template metadata' which is already captured by the output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'Confluence page content templates', and it distinguishes from siblings by noting it returns metadata without the full body. It explicitly names the alternative for body retrieval, resolving 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 provides clear context: it is Cloud-only and returns metadata only. It also gives an explicit alternative (use confluence_get_page_template for the body). However, it does not explicitly list when not to use this tool or other exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers the safety profile. The description adds useful behavioral context: it scans issues, extracts cross-project links, and groups them by target project and link type. It does not contradict the annotations; a minor caveat about the max_issues limit exists but is left to the 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 few short, front-loaded sentences with no redundancy. It states the core purpose, the behavioral details, and the use case in a compact, logical structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter read-only tool with an output schema and 100% schema description coverage, the description fully covers purpose, behavior, and usage context. Nothing essential is 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?
The input schema has 100% description coverage for both parameters, including project_key format and max_issues range and default. The description adds no parameter-specific details, 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 opens with a specific verb and resource: 'Find all cross-project issue links for a project.' It then details the scanning, extraction, and grouping behavior, clearly distinguishing it from generic tools like jira_get_project_issues or jira_get_link_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 states 'Useful for dependency analysis across multi-project Jira setups,' which gives a clear use case. However, it does not explicitly name alternatives or exclusion criteria, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=true. The description adds behavioral context beyond this: automatic resolution to the global context when context_id is omitted, and version-specific API mechanisms (Field Context Option API vs createmeta). This enriches the agent's understanding without contradicting any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded. The first sentence states the purpose, the second lists supported field types, and the next two sentences cover Cloud and Server/DC differences. Every sentence adds operational value, with no redundant fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters and two distinct deployment paths, the description covers the essential behavior, supported field types, API differences, and required parameters. An output schema exists, so return values are already structured; the description need not repeat them. It is complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is already documented. The description adds some cross-parameter context (context_id for Cloud, project_key/issue_type for Server/DC) but largely restates what the schema already says, providing only marginal additional meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Get allowed option values for a custom field.' It then enumerates the supported field types (select, multi-select, radio, checkbox, cascading select), which helps distinguish it from sibling tools like jira_get_request_type_fields or jira_get_create_fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides deployment-specific usage guidance: Cloud uses the Field Context Option API with optional context_id auto-resolving to the global context, while Server/DC uses createmeta and requires project_key and issue_type. It gives clear context for when to use the tool but does not mention alternatives or explicit when-not-to-use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds valuable context that this retrieves data from connected source control systems (Bitbucket, GitHub, GitLab) and shows the development panel info. No contradictions with annotations, and the added context helps the agent understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, two sentences that front-load the core purpose. Every word adds value, no redundancy or irrelevant details. It perfectly balances brevity with necessary context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the read-only annotation, 100% schema coverage, and an output schema, the description provides enough context for an agent to select and invoke the tool correctly. It explains the domain (development panel info from source control systems) and clarifies what kind of data to expect. No major gaps are present.
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% parameter description coverage, so the baseline is 3. The description's mention of PRs/commits/branches provides some context for the data_type parameter and the type of information retrieved, but it adds little beyond what the schema already documents for 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 uses a specific verb ('Get') and clearly identifies the resource ('development information') linked to a Jira issue, explicitly enumerating PRs, commits, and branches. This makes the tool's purpose unambiguous and distinguishes it from generic issue retrieval tools, though it doesn't explicitly contrast with the plural sibling tool jira_get_issues_development_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this is for retrieving development panel information for a specific Jira issue, with an issue_key required. However, it does not explicitly state when not to use it or mention alternatives like the plural sibling tool jira_get_issues_development_info, so it lacks explicit exclusions/alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare readOnlyHint true, and the description adds meaningful context about the create schema and deduplication across issue types. This goes beyond the annotation by explaining the exact nature of the returned fields, though it does not discuss auth, rate limits, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no redundancy. The first sentence immediately states the core purpose, and the second clarifies the deduplication nuance, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a single parameter, an output schema, and the annotation readOnlyHint, the description provides sufficient context for an agent to understand what the tool does and when to invoke it. The clarification about create schema and deduplication rounds out the necessary 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 only parameter, project_key, is fully described in the schema with an example, so the schema coverage is 100%. The description does not add additional parameter semantics beyond what the schema already provides, which is acceptable given the simple single-parameter case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves fields available on issues of a project, specifically the create schema, and clarifies deduplication across issue types. It distinguishes from related tools like jira_get_create_fields and jira_search_fields by emphasizing project-level and deduplicated scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context about what this tool returns, but it does not explicitly mention when to use this tool versus alternatives like jira_get_create_fields or jira_search_fields. The phrasing implies project-level field discovery, but lacks direct exclusions or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true annotation already indicating safety, the description adds valuable context about platform availability (Server/Data Center only, not Cloud) and the specific source (service desk queue). This goes beyond the annotation without contradicting it.
Agents need to know what a tool does to the world before 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 core action front-loaded and no unnecessary words. Every word adds value, making it an excellent example of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, with a complete schema, output schema, and read-only annotation. The description's focus on the action and platform constraint is sufficient for an agent to use it correctly without any missing critical 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 schema fully documents all four parameters including types, defaults, and constraints. The description adds no parameter-specific details, matching the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves issues from a Jira Service Desk queue, using a specific verb and resource. It distinguishes itself from sibling tools like jira_search (search issues) and jira_get_board_issues (board issues) by targeting service desk queues specifically.
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 stating it is for Server/Data Center only and not available on Jira Cloud, helping the agent know when it is applicable. However, it does not explicitly mention alternatives or when to choose this over other issue-listing tools, so it lacks explicit exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds useful behavioral context by noting it uses the projects picker endpoint, returns a ranked list, and avoids fetching all visible projects. This goes beyond what the annotation 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 two concise sentences with the main purpose front-loaded. Every sentence provides valuable information without any fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the presence of an output schema, and the read-only annotation, the description is complete enough. It covers the purpose, search mechanism, and efficiency trade-off without needing to explain return values or safety.
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 (query, max_results, current_project_ids). The description does not add additional parameter-specific semantics 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 clearly states the tool's function with a specific verb ('Search'), resource ('Jira projects'), and scope ('by name or key prefix'). It also distinguishes from siblings like jira_get_all_projects by mentioning a ranked list and avoiding fetching all visible projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: when searching for matching projects by name/key, and it implies a contrast with fetching all projects. However, it does not explicitly name alternative tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations include destructiveHint=true, the description adds substantial behavioral detail: the issue retains its type, the key may change (with an example), the operation is asynchronous with polling, and there is a 30-second timeout. This exceeds what annotations alone provide and is genuinely helpful for an agent predicting 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 efficiently organized into three short paragraphs, each serving a purpose: core action, behavior details, and async/polling behavior. Every sentence adds operational value without fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema and annotations, the description sufficiently covers the overall behavior, including the key change and async polling. It does not mention potential failure modes or permission prerequisites, but for a move operation with this complexity, the provided details are adequate and likely sufficient 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?
Schema coverage is 100% with both parameters fully described, including pattern and examples. The description adds some context (e.g., issue type retention, key change) but largely reiterates what the schema already states. This 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 uses a specific verb ('Move') and clearly identifies the resource ('Jira issue') and destination ('to a different project'). This distinguishes it from sibling tools like jira_update_issue, jira_transition_issue, and jira_delete_issue. The scope 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 description provides clear context for when to use the tool: moving an issue to a different project. It also notes the Jira Cloud-only restriction and the use of the bulk move API. It does not explicitly name alternatives or state when not to use it, but the context is sufficient for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond the destructiveHint annotation by stating 'Only fields explicitly provided are modified; other attributes of the version are left untouched'. This clarifies the partial-update semantics, which is important for an update tool. It does not mention permissions or error behavior, but the annotation already signals destructiveness, and the description supplements it well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of three concise sentences: the first states the primary action, the second clarifies partial-update behavior, and the third lists practical use cases. Every sentence contributes meaningful information without redundancy or fluff, 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 and the input schema fully covers parameters, the description does not need to explain return values or each parameter. It covers the core purpose, partial-update semantics, and typical use cases. It could optionally mention prerequisites like the version ID being valid, but the schema already specifies that. Overall, it is sufficient for an AI agent to select and use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds extra semantic value by stating that only explicitly provided fields are modified, which explains the default null behavior of optional parameters. This goes beyond what the schema descriptions alone convey, so a slightly higher score is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Update an existing fix version in a Jira project' with a specific verb, resource, and scope. It distinguishes itself from sibling tools like jira_create_version and jira_batch_create_versions by emphasizing it updates an existing version rather than creating one, and the phrase 'without recreating them' reinforces the distinction.
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 usage context by listing typical scenarios: 'archiving/unarchiving versions, renaming, or shifting release dates'. It implies that creation of versions should be handled by other tools ('without recreating them'), but it does not explicitly list when not to use this tool or name alternative tools for exclusion, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the destructiveHint=true annotation by explaining that the action 'cannot be undone,' deletes 'ALL its versions,' and includes a prominent warning. It also advises on backup and verification, adding valuable behavioral context that the annotation alone does not 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 uses clear headings, bullet points, and a warning callout. It is concise and well-structured, with every sentence contributing useful information. No redundant filler or verbose explanations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter destructive tool with an output schema and a comprehensive input schema, the description covers purpose, usage scenarios, prerequisites, and risk mitigation. It is fully complete for an agent to understand when and how to invoke the tool safely.
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 the single parameter attachment_id, including its purpose, how to find it (via get_attachments), an example, and a warning. The description's best practices add operational advice but do not add new parameter semantics beyond what the schema already states, 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 opens with 'Permanently delete an attachment from Confluence,' a specific verb+resource combination that clearly states the action and scope. This distinguishes it from sibling tools like confluence_upload_attachment, confluence_get_attachments, and confluence_download_attachment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context with bulleted examples ('Remove outdated or incorrect attachments', 'Clean up duplicate files', 'Delete sensitive information') and explicit best practices including verifying the attachment ID with get_attachments, downloading a backup, and checking with content owners. It does not explicitly list when NOT to use it, but for a destructive tool, the strong warning and prerequisites provide adequate guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description reveals critical behavior: content is base64-encoded, embedded in the MCP response, and large files are not downloaded but return an error. This goes well beyond the annotation and helps set agent expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: first sentence states the main action, second explains the encoding, third gives the size constraint. No redundant or unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with no output schema, the description is complete: it covers return format (base64 embedded resource), the size limit, and error behavior. The readOnlyHint annotation confirms safety, and the schema fills the remaining parameter 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 tool description itself does not elaborate on the parameter, but the input schema provides excellent documentation: example ID, how to find via get_attachments, and a workflow. Since the schema covers the parameter fully (100% coverage), a baseline of 3 is appropriate; the description adds no extra meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Download an attachment from Confluence') and the specific output format ('as a base64-encoded embedded resource'), distinguishing it from sibling tools like jira_download_attachments or confluence_download_content_attachments. It also adds a unique constraint (50 MB limit) that further clarifies scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains the use case (MCP protocol, avoiding filesystem access) and discloses the 50 MB limitation, providing context on when to use it. It does not explicitly name alternatives or state when not to use it, but the purpose is clear enough for an agent to distinguish it from other attachment tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses that attachments are returned as base64-encoded embedded resources (important for MCP usage), that files over 50 MB are skipped, and that errors are reported in a summary. This adds significant behavioral context not present in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action, and wastes no words. It efficiently communicates purpose, output format, and a key limitation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers the essential aspects: what it does, how results are returned (base64), the 50 MB limit, and error handling. This 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?
The input schema already provides full coverage for the single parameter (content_id) with a clear description. The tool description does not add further parameter semantics beyond what the schema states, 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's function: downloading all attachments for a Confluence content item and embedding them as base64 resources. It specifies the resource (content item) and scope (all attachments), distinguishing it from sibling tools that download single attachments or list metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use when you need all attachments for a content item as embedded resources. It does not explicitly name alternatives or exclusions, but the use case is well-defined and implied by the 'all attachments' scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds valuable behavioral context by disclosing the media type quirk (application/octet-stream for binary files) and recommending filename filtering instead. It also lists the metadata fields returned, giving the agent a clear picture of the tool's output. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening, a bulleted list of return metadata, a highlighted 'Important' caveat, and a 'Useful for' section. Every sentence adds value and supports tool selection or invocation. Despite its length, it remains focused and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and the presence of an output schema, the description covers all essential aspects: what it lists, what metadata is returned, a critical API behavior caveat, and practical use cases. It doesn't need to explain return values in detail because the output schema exists. It is complete and well-suited for an agent deciding when and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters are documented. The description goes beyond the schema by explicitly advising that 'filename' is a more reliable filter than 'media_type' and mentioning pattern matching support. This adds practical interpretation that the schema alone does not fully convey, warranting a score above 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 opens with a specific verb and resource: 'List all attachments for a Confluence content item (page or blog post).' It clearly distinguishes this from sibling tools like download_attachment, upload_attachment, or delete_attachment by focusing on listing metadata rather than performing an action on files. The scope 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?
The 'Useful for' section provides clear practical contexts (discovering files, getting IDs for download, checking existence, listing for processing). It implicitly positions the tool as a precursor to download operations, which differentiates it from sibling download tools. However, it does not explicitly name alternative tools or state when not to use this tool, so it falls short of full alternative/exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide readOnlyHint=true, so the description adds substantial behavioral detail: it lists supported image formats, base64 encoding, fallback detection for ambiguous MIME types, and a 50 MB size limit with error handling. This goes beyond the annotation and fully discloses edge-case behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear first sentence stating the purpose, followed by two short paragraphs covering filtering and edge-case behavior. Every sentence adds value without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simple interface (one required parameter), the description comprehensively covers what is returned (base64 ImageContent), what is excluded, and important edge cases like size limits and MIME detection. No output schema exists, so the description carries the full burden and does so effectively.
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 covers the single parameter (content_id) 100%, including what it represents. The tool description does not add additional parameter semantics beyond the schema, 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 tool gets all images attached to a Confluence page as inline image content. It uses a specific verb+resource and explicitly distinguishes from sibling tools like confluence_get_attachments by filtering to images only and excluding non-image attachments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is for images only, with non-image attachments excluded. It implies use when you need inline image content, but does not explicitly name alternative tools like confluence_get_attachments; however, the exclusion statement provides sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides extensive detail beyond the readOnlyHint annotation, explaining base64 encoding, the distinction between EmbeddedResource and TextContent returns, MIME type handling, and the rationale (#1419). This is exactly the kind of behavioral transparency that helps an agent know what to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the primary action, then efficiently explains the return format and nuances. Every sentence serves a purpose, and the length is justified by the need to clarify base64 and MIME types.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description fully compensates by explaining what the tool returns: base64 content, EmbeddedResource for images, and TextContent for others. The single well-documented parameter plus detailed return behavior makes the tool complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully covers the only parameter 'issue_key' with a pattern and example, and the description does not add additional parameter details. With 100% schema description 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 'Download attachments from a Jira issue' with a specific verb and resource. It distinguishes itself from sibling tools like 'jira_get_issue_images' by covering all attachment types, not just images.
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 context is clear: use this tool to retrieve attachment contents from a Jira issue. While it does not explicitly mention alternative tools or when-not-to-use, the purpose is unambiguous given the description and tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds meaningful behavioral context by specifying exactly what data is returned (required/optional fields, names, IDs, schema) and mentions using a separate tool for field options. While it doesn't disclose exhaustive details like rate limits or pagination, it provides sufficient transparency for a read-only metadata lookup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with three short sentences that front-load the purpose, describe the output, and provide an alternative for options. Every sentence earns its place, avoiding redundancy and unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two well-documented parameters and an output schema, the description covers all essential aspects: what it does, what parameters are needed, what it returns, and how to handle a related use case. It is complete for an AI agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with both project_key and issue_type_id well-documented. The description does not add extra parameter semantics beyond the schema, but it reinforces the parameters' role in the tool's purpose. This aligns with the baseline expectation for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get fields available for creating an issue of a specific type' and details what is returned (field names, IDs, required status, schema). It distinguishes itself from the sibling jira_get_field_options by instructing to use that tool for field options, ensuring clarity among similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance by naming jira_get_field_options as the alternative when a returned field needs allowed values. It also implies the primary use case (when preparing to create an issue) without ambiguous context, making it clear when to use this tool versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses significant behavioral details: filters to specific image formats, returns base64 ImageContent, uses filename extension fallback for ambiguous MIME types, and skips images over 50MB with an error summary entry. This provides an agent with a rich understanding of the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a front-loaded main statement followed by three precise, information-dense sentences. Every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description explains the return format (base64 ImageContent), what is filtered out, and the error handling for large images. This is complete for a simple read-only tool with a single parameter.
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 of the issue_key parameter, including an example and return behavior. The description adds little beyond the schema, so per the baseline for high schema coverage, a 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 verb 'Get', the resource 'images attached to a Jira issue', and distinguishes from sibling jira_download_attachments by emphasizing 'images only' and returning 'inline image content'. This makes the tool's specific role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that the tool is for retrieving image attachments for direct rendering, implying use for vision tasks. However, it does not explicitly name alternative tools like jira_download_attachments or state when not to use this tool, so it falls short of being fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotation 'destructiveHint: true', the description discloses that it 'Replaces all existing restrictions with the provided lists' and that omitting all parameters or passing empty lists removes all restrictions. This is critical behavioral insight for an agent, as it indicates the operation is not additive but a full overwrite, and can also remove protections. This exceeds the annotation's simple danger flag.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary purpose, and immediately follows with the most important behavioral caveat. Every sentence earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is largely complete for a tool with rich schema and annotations. It explains the replacement and removal behavior, but leaves a minor ambiguity: what happens when only some parameters are omitted (e.g., only read_users supplied). The phrase 'replaces all existing restrictions' implies omitted lists are treated as empty, but this is not stated explicitly. Still, the core use cases are covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptions for each parameter. The description adds value by explaining the combined semantics: the provided lists replace all existing restrictions, and omitting all parameters or passing empty lists clears restrictions. This clarifies how the parameters interact as a set, which is not obvious from the individual schema descriptions alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Set view and edit restrictions on a Confluence page.' It clearly distinguishes from sibling tools like 'confluence_get_page_restrictions' (which retrieves) and 'confluence_check_content_permissions' (which checks). The second sentence clarifies the tool's core behavior, further eliminating 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 clearly implies this tool is used to modify page restrictions. It does not explicitly mention alternatives or when not to use it, but the context is clear: this is for setting/replacing restrictions, not for viewing them. The destructive behavior is noted, which helps the agent choose this only when a modification is intended. No exclusions are stated, so it loses one point for not explicitly naming alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds further behavioral context: it returns the full result set for disambiguation, requires exactly one of project_key or issue_key, and works without the global Browse Users permission. This goes well beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured into clear paragraphs: purpose, usage scenarios, and context/permissions. It is longer than necessary but every sentence adds meaningful information. The front-loading of the core purpose and immediate usage guidance makes it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description covers all critical aspects: purpose, usage context, parameter constraints, permission considerations, and behavioral nuances. It is sufficiently complete for the tool's complexity and leaves no significant gaps for an agent to misuse it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds valuable meaning by explaining the relationship between project_key and issue_key (exactly one must be provided) and clarifying the query parameter's behavior (case-insensitive, partial match). This supplemental constraint and search semantics improve 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 clearly states the tool searches Jira users assignable in a given project or issue, with a specific verb and resource. It explicitly distinguishes itself from get_user_profile by noting it returns the full result set and supports human-name search, which sets it apart from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: use when you have a display name/partial name/email fragment and need a concrete identifier for assignee/reporter/watcher. It also names alternative get_user_profile and explains why that tool is not suitable, offering clear exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say `readOnlyHint: false`, which is consistent with the write operation. The description discloses additional behavior: it uses the dedicated PUT endpoint, explains the identifier resolution order (key lookup → email search → text search → assignable-user search), and warns about the unreliability of `update_issue`. This goes well beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short, focused paragraphs. The first sentence states the core purpose, the second explains the advantage over an alternative, and the third provides essential identifier details. There is no fluff, and the structure front-loads the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with an existing output schema, the description covers the endpoint, the reliability rationale, accepted identifier forms, and resolution order. It also clarifies that an empty string or null unassigns, which is reflected in the schema but helps the agent understand usage. No critical context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description adds valuable semantic detail about the `assignee` parameter, specifying accepted identifier forms (login name, email, display name, JIRAUSER key) and the exact resolution order. It also references the JSON object format from `jira_search_assignable_users`, which is not fully detailed 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 opens with a specific verb+resource: 'Assign a Jira issue to a user using the dedicated assignment endpoint.' It explicitly distinguishes itself from the sibling `update_issue` tool by noting that setting assignee via `update_issue` is silently ignored in some configurations, making the purpose and unique value clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use this tool over `update_issue`: 'This is more reliable than setting assignee via update_issue, which is silently ignored by some Jira configurations.' It also mentions accepted identifier forms and the resolution order, providing concrete guidance on how to supply the assignee parameter, including a hint that JSON object strings from `jira_search_assignable_users` are acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint=true annotation, the description discloses a critical behavioral limitation: the Jira Forms API does not preserve time components in DATETIME fields. It also explains automatic conversion of ISO 8601 dates to Unix timestamps, and provides example answer structures. This adds significant behavioral context that an agent needs to know before calling 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-organized with clear sections: purpose, known limitation, workaround, automatic conversion, examples, and type list. Each section serves a purpose, though the workaround example repeats the limitation slightly. It could be slightly trimmed, but the length is justified given the tool's complexity and important caveats.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is exceptionally complete. It covers the tool's purpose, the answers array format, common answer types, date/time conversion rules, a known limitation, and a workaround referencing a sibling tool. The output schema exists, so return values need not be explained. Given the tool's complexity and the importance of the DATETIME caveat, this description leaves no critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema provides 100% coverage with basic descriptions, the description vastly enriches parameter semantics. It explains the structure of the 'answers' array with a detailed example, lists common answer types (TEXT, NUMBER, SELECT, etc.) and their expected value formats, and clarifies special date/datetime handling. This goes far beyond the schema's generic 'additionalProperties' 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 begins with a specific verb and resource: 'Update form field answers using the Jira Forms REST API.' It explicitly identifies this as 'the primary method for updating form data,' distinguishing it from sibling tools like jira_update_issue and jira_get_proforma_form_details. The purpose is unambiguous and well-scoped.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance by stating this is the primary method for updating form data and gives a concrete when-not-to-use scenario: for DATETIME fields, it instructs to use jira_update_issue instead, with a detailed workaround. This distinguishes usage from alternatives and provides clear contextual instructions.
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:

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

Score Badge

Copy to your README.md:

[![atlassian-mcp-server MCP server](https://glama.ai/mcp/servers/hieptran87/atlassian-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/hieptran87/atlassian-mcp-server)

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/hieptran87/atlassian-mcp-server'

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