atlassian-browser-mcp

by GeiserX

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v1.2.1
Disambiguation5/5
Tools are clearly separated by prefix (confluence_ vs jira_) and within each, they use distinct verb_noun combinations. No overlapping purposes; each tool has a unique, well-defined function.
Naming Consistency5/5
All tools follow a consistent snake_case verb_noun pattern across both Confluence and Jira sets. Verbs like create, get, update, delete, add, search are used uniformly.
Tool Count2/5
With 91 tools, the server is overly broad, covering two major products with many specialized functions. This makes it heavy and harder to navigate; splitting into separate Jira and Confluence servers would improve coherence.
Completeness4/5
The tool set covers a comprehensive range of operations for both Jira and Confluence, including CRUD, search, permissions, attachments, comments, and advanced features. Minor gaps exist, such as no delete comment or space management tools.
Average 4.1/5 across 91 of 91 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 2 community issues answered or closed in the last 6 months
- 16 commits in the last 12 weeks
- Last stable release on July 11, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under GPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
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?
The annotation provides destructiveHint: true, but the description adds minimal extra context: it mentions that it can raise ValueError if in read-only mode or Jira client unavailable. It does not explain other behavioral traits like whether linking replaces an existing epic link or whether it's idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main purpose. The parameter list is somewhat repetitive given the schema, but overall it is not verbose and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool and the presence of an output schema, the description covers the basic operation, required parameters, and potential errors. However, it could mention that the issue and epic must already exist, and that the operation is destructive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already fully describes the parameters. The description merely lists the parameter names without adding any extra meaning or context, making it redundant.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Link an existing issue to an epic' with a specific verb and resource. It is clear and distinguishes from sibling tools like jira_create_issue_link or jira_remove_issue_link.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no preconditions (e.g., issue must not already be linked), and no exclusions are mentioned. The description only states the basic action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, so the description's 'update' and 'changing' reinforce this. It mentions raising ValueError for read-only mode, but lacks details on permissions needed or side effects. With annotations covering safety, the description adds modest context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with Args, Returns, Raises sections, but includes parameter details that are redundant with the schema. It could be more concise while still being clear.
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 all parameters, return value, and raises clause. With an output schema present (not shown), the description adequately explains behavior. However, it omits rate limits or authentication specifics, which are not critical for completeness given the tool complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed parameter descriptions (e.g., field format, patterns). The description adds minimal extra value, such as noting Markdown for description, but mostly repeats schema info. 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 clearly states the tool updates an existing Jira issue, listing specific actions like changing status, adding Epic links, and updating fields. It uses a specific verb-resource pair ('Update Issue') and distinguishes from sibling tools like create and delete, though it overlaps with jira_transition_issue and jira_link_to_epic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus siblings like jira_transition_issue or jira_link_to_epic. It lists those capabilities but doesn't clarify that dedicated tools might be preferred for specific 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 already mark the tool as destructive (destructiveHint: true). The description repeats 'delete' but adds no additional behavioral traits such as reversibility, side effects, or permissions beyond what annotations 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 concise, well-structured with clear Args, Returns, and Raises sections, and contains no superfluous content. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with one parameter and annotations, the description is adequate but lacks specifics about consequences (e.g., whether deletion is irreversible, impact on children). Output schema exists but is not described in detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 already explains the 'page_id' parameter. The description's Args section simply restates that information without adding new meaning. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Delete' and the resource 'existing Confluence page'. It is specific and distinguishable from sibling tools like 'confluence_delete_attachment'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no context about when not to use it. It is a straightforward delete, but some usage context is expected.
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 that it raises ValueError for read-only mode. However, it does not elaborate on other behaviors like estimate handling 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with Args, Returns, and Raises sections. It is appropriately sized but somewhat redundant with the input schema, reducing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, 2 required) and that schema and output schema are present, the description covers basic functionality and errors. However, it lacks context on how optional parameters like original_estimate interact with the worklog addition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description's Args section largely repeats the schema, adding minimal additional meaning beyond the existing 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 clearly states 'Add a worklog entry to a Jira issue,' specifying the action and resource. It distinguishes from sibling tools like jira_get_worklog and jira_add_comment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, nor does it provide context on prerequisites or when not to use it. The only guidance is an error condition for read-only mode.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, confirming write operation. The description adds 'Returns results' but no additional behavioral traits like error handling, idempotency, or permissions. Minimal extra value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes unnecessary 'Args:' and 'Returns:' sections typically used in code docs. Could be more concise by removing these and integrating key info into a single sentence.
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 output schema exists and parameter schema is detailed, the description covers the basics. However, lacks context on batch limits, error behavior, or result handling, which would be valuable for a batch operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with detailed descriptions for both parameters. The description mentions 'JSON array string of version objects' but does not add new meaning beyond the schema's example and field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Batch create multiple versions in a Jira project', specifying the verb (batch create) and resource (versions). It distinguishes from sibling tool 'jira_create_version' which creates a single version.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs alternatives (e.g., jira_create_version), nor any prerequisites or conditions. The agent is left to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include destructiveHint=true, indicating mutation. The description repeats this by stating 'Create' but adds minimal extra behavior (e.g., no side effects, permissions, or error cases).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args and Returns sections, though the Args section is somewhat redundant with the schema. It is clear and not overly long, with each sentence serving a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality and notes the return format (JSON string). However, it lacks prerequisites (e.g., authentication, project existence) and error handling. With moderate complexity and an output schema, it is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents parameters. The description repeats parameter names and types without adding new semantics; 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 'Create a new fix version in a Jira project,' specifying the action (create) and resource (fix version). Among siblings, jira_batch_create_versions exists for batch creation, so this tool is distinct for single version creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., batch_create_versions) or prerequisites like login or permissions. It only describes the action without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation already declares readOnlyHint=true, consistent with the description stating it returns comments. No additional behavioral traits (e.g., pagination, ordering) are disclosed 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 brief and to the point, though the Args and Returns sections extend it slightly. It is front-loaded with the core purpose sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description adequately covers the tool's purpose and return type. It lacks details on pagination or ordering but is sufficient for a straightforward retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a detailed parameter description for page_id. The tool description only repeats the parameter name, adding no additional meaning beyond what is already in the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get comments for a specific Confluence page' uses a specific verb and resource, clearly distinguishing 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 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_search or confluence_get_page. It does not mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, so the description doesn't need to restate that. It adds value by mentioning possible errors (ValueError for read-only mode or client unavailability) and the return type (JSON string with success message). However, it doesn't disclose side effects like overwriting existing sprint assignments or validation failures.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with Args, Returns, and Raises sections, which is easy to parse. It is concise without extraneous information, though the Args section largely mirrors the schema. The purpose is front-loaded in the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple two-parameter tool with an output schema, the description covers the action, parameters, return type, and error cases. It does not explain the success message structure, but the output schema likely handles that. The description is adequate for an agent to 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?
With 100% schema coverage, the input schema already provides clear descriptions for both parameters. The description's repetition of parameter details ('The ID of the sprint', 'Comma-separated issue keys') does not add significant new meaning 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 clearly states 'Add issues to a Jira sprint' which is a specific verb+resource combination. It distinguishes itself from sibling tools like jira_create_sprint (creates sprint) and jira_get_sprint_issues (retrieves issues), making it easy for an agent to select the right tool for adding issues.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. It mentions a ValueError for read-only mode, but does not indicate scenarios where adding issues might be inappropriate (e.g., sprint is closed) or suggest alternative tools like jira_update_sprint for other sprint modifications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true. The description adds valuable behavioral context: it creates an issue, supports optional Epic/parent links, returns a JSON string, and raises ValueError if read-only or client unavailable. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args, Returns, and Raises sections, but it is slightly verbose. It does not repeat schema descriptions inecessarily, and every sentence adds value, though the Args list could be omitted since schema covers it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, multiple optional fields, return JSON), the description covers creation details, optional features, and error conditions. It does not mention authentication or project existence, but these are implied or handled by separate tools. The return format benefits from the output schema, so description is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for all parameters. The description adds no new semantic information beyond what the schema provides, staying at the baseline score for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a new Jira issue, with optional Epic link or parent for subtasks. It is specific about the resource and action, but does not explicitly distinguish from siblings like jira_batch_create_issues or jira_update_issue, though the verb and scope imply difference.
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 lacks explicit when-to-use or when-not-to-use guidance. It does not mention that for batch creation one should use jira_batch_create_issues, nor does it state prerequisites like being logged in. The error section hints at read-only mode but provides no direct comparative advice.
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 basic return type ('list of board objects'). It does not elaborate on pagination behavior despite parameters like start_at and limit, nor on authentication requirements or data freshness.
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 uses a clear structured format with Args/Returns sections and front-loaded purpose. It is slightly verbose for a simple get tool, but still effective.
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 parameters are fully described in the schema, the description covers the essential input and output. It could mention the scope of boards (e.g., user-accessible boards) but is otherwise 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 already documents each parameter adequately. The description repeats the parameter descriptions without adding new meaning or constraints beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'jira agile boards', and specifies filtering by name, project key, or type. It distinguishes from siblings like jira_get_board_issues which retrieves issues from a board, not the board list itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when or when not to use this tool vs alternatives among the many Jira sibling tools. It lacks explicit context like 'use this to list boards before selecting one for further operations' or 'for board-specific issues, use jira_get_board_issues'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint: true, and the description adds behavioral context by explaining the 'refresh' parameter for forcing a field list refresh and the behavior when keyword is empty (lists first 'limit' fields). However, it does not cover potential outcomes like fuzzy match failures or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear first sentence and well-structured Args/Returns sections. It avoids verbosity while covering key points, though the docstring format could be more 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 (3 optional params) and presence of an output schema (not shown but referenced), the description adequately explains purpose and behavior. It covers the main use case and parameter effects, though lacks details on error handling or output structure beyond 'JSON string'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description repeats parameter info from the schema without adding new meaning, except for the empty keyword behavior which is already in the schema. 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 'Search Jira fields by keyword with fuzzy match', specifying the verb, resource, and method. It distinguishes from siblings like jira_get_field_options by focusing on searching fields rather than retrieving options. The return of matching field definitions is also explained.
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, such as jira_get_field_options or other search tools. It lacks usage context like prerequisites or exclusions, leaving the agent to infer based on the name alone.
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 the return format (JSON string of inline comments) and possible ValueError if client is unavailable, which is useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, front-loading the purpose and using a structured docstring format. Every sentence is necessary and adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with an output schema and one parameter, the description is complete. It lacks explicit differentiation from related sibling tools, but the core functionality is well-covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description merely repeats the parameter's purpose without adding new meaning. 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 clearly states the action (get), resource (inline comments), and scope (for a page). However, it does not differentiate from the sibling tool 'confluence_get_comments', which may cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'confluence_get_comments'. The description only explains what it does without providing context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include destructiveHint: true, which is consistent with creating a link. The description adds that it raises ValueError in read-only mode, but does not elaborate on other side effects (e.g., whether links can be reversed). The behavioral context provided is adequate but minimal 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses a structured docstring format with Args and Returns sections. It is moderately concise but includes redundant mentions of 'ctx' (not in schema) and full parameter lines. The main purpose sentence is front-loaded, but the docstring could be shorter by removing the ctx line and using a more compact description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, 3 required), the description covers all parameters, return values, and error cases. The output schema exists (context signal), so return details are not required. The description lacks a brief usage example or mention of typical link types (e.g., 'Blocks'), but it is largely complete for an experienced 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%, so baseline is 3. The description lists parameters with types and defaults, but does not add semantic meaning beyond the schema. For example, it repeats the schema's descriptions of inward/outward_issue_key but does not clarify concepts like 'source' vs 'target' in more detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 link between two Jira issues.' The docstring details parameters like link_type, inward_issue_key, outward_issue_key, and the return value. This distinguishes it from siblings like jira_remove_issue_link and jira_link_to_epic.
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 listing required parameters and error conditions (ValueError for missing fields, read-only mode, or Jira client unavailable). However, it does not explicitly state when to use this tool vs alternatives like jira_link_to_epic or jira_create_remote_issue_link, nor does it provide a when-not-to-use guideline.
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 provide readOnlyHint=true, so the description does not need to repeat that. It adds context about the type of data retrieved (PRs, commits, branches), but lacks details on rate limits, authentication requirements, or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with Args and Returns sections, but it is slightly verbose. It could be more concise, e.g., by removing the 'Args:' and 'Returns:' labels since the schema already provides parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (though not shown here) and annotations, the description covers the main functionality: batch retrieval of development info. It mentions the optional filters and return format, which is sufficient for moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds minimal value. For example, it says 'List of Jira issue keys' while schema specifies 'Comma-separated list', which is clearer. Overall, the description largely paraphrases 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 retrieves development information (PRs, commits, branches) for multiple Jira issues. It explicitly mentions batch retrieval, distinguishing it from the singular sibling tool jira_get_issue_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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies batch usage but does not explicitly state when to use this tool over alternatives like jira_get_issue_development_info. No when-not or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, so the description's mention of 'Add' is consistent. It adds a note about ValueError if the Jira client is missing, but doesn't disclose other behaviors like duplicate handling or user existence checks. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the action and uses a structured docstring (Args, Returns, Raises). It is efficient but includes some redundancy (e.g., repeating parameter names). Still concise and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers purpose, parameters, return format (JSON), and error condition. The existence of an output schema and annotations further completes the picture. Lacks mention of user validity or side effects, but remains fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. The description's Args section restates parameter names and the Raises note, but adds no meaning beyond the schema's descriptions (e.g., issue_key pattern, user_identifier clarification). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Add a user as a watcher to a Jira issue.' It specifies the verb (add), resource (watcher), and target (Jira issue), and is distinct from sibling tools like jira_remove_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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating the purpose, but provides no explicit guidance on when to use this tool versus alternatives (e.g., jira_get_issue_watchers to check current watchers). There is no mention of prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds value beyond annotations by explaining that attachments are returned as base64-encoded embedded resources for MCP protocol compatibility, avoiding filesystem access. This is useful behavioral context. Annotations already confirm read-only, so 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise but includes a docstring-style breakdown of Args and Returns. It's front-loaded with purpose and adds necessary detail about return format. Could be slightly tighter, but it's well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and no output schema, the description covers purpose, parameter, and return format. It lacks error handling info (e.g., what if issue has no attachments or key invalid), but overall it's fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for issue_key. The description's Args section repeats the same info ('Jira issue key') without adding new meaning, so it meets the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Download attachments from a Jira issue.' It specifies the action (download), resource (attachments), and source (Jira issue), making it distinct from sibling tools like jira_get_issue or jira_search that do not download attachments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., jira_get_issue which returns issue data without attachments). No explicit when-not-to-use or exclusion criteria, leaving the agent to infer context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states it retrieves development panel information from connected source control systems like Bitbucket, GitHub, or GitLab. Annotations already declare readOnlyHint=true, so no contradiction. The description adds context about the types of systems and data returned without conflicting with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a brief summary followed by expanded details and structured Args/Returns sections. It is front-loaded and concise, with no wasted sentences.
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 all key aspects: it specifies what is retrieved (PRs, branches, commits, repositories), mentions connected source control systems, and includes a Returns section. Since an output schema exists, the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description's Args section repeats schema info but adds examples for application_type and data_type. This provides minor additional guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get development information (PRs, commits, branches) linked to a Jira issue.' It specifies the action and resource. However, it does not explicitly differentiate from the sibling tool 'jira_get_issues_development_info' (plural), though the singular vs plural naming implies it's for a single 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 implies usage for retrieving development panel info from connected source control systems but does not provide explicit guidance on when to use this tool vs alternatives, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the read-only nature (consistent with readOnlyHint annotations) and explains configuration via environment variables. It adds context about working hours filtering and available metrics, but does not detail error behavior or response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with a clear summary, but the Args section largely duplicates schema descriptions. The environment variables block is detailed but makes the description longer than necessary. Could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers core functionality and configuration, but lacks details on the exact output structure despite having an output schema. Error handling and edge cases (e.g., missing issue_key) are not addressed. Fairly complete for a typical tool but could be improved.
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 value by explaining environment variable defaults and the return format (JSON string), which is not in the schema. It also lists available metrics and their defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it calculates SLA metrics for a Jira issue, listing specific metrics like cycle time and lead time. It distinguishes itself from other Jira tools by focusing on SLA calculations, which is unique among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like jira_get_issue_dates or other issue retrieval tools. The description lacks when-not-to-use or comparison hints.
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 provide readOnlyHint=true, making safety clear. The description adds pagination (start_at, limit) and field customization details but does not disclose further behavioral traits (e.g., if closed issues are included). With annotations, the bar is lower, and the description adds some value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a structured Args/Returns format. It is front-loaded with the main purpose and uses efficient language. Slightly more verbose than necessary (e.g., listing all args) but still clear.
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 (as indicated in context), the description adequately covers input parameters and return type. It lacks details on behavior like ordering or issue status inclusion, but for a list tool with pagination, it is 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?
Schema coverage is 100%, so the schema fully documents parameters. The description repeats parameter info without adding new meaning. Baseline score of 3 is appropriate as the description does not enhance parameter 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 retrieves issues from a sprint using 'Get jira issues from sprint.' It distinguishes from sibling tools like jira_get_sprint_from_board and jira_search by specifying the resource (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?
No explicit when-to-use or when-not-to-use instructions. While the purpose implies using it for retrieving sprint issues, there is no guidance on alternatives like jira_search or jira_get_board_issues. Usage is implied but not clearly delineated.
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, indicating a read operation. However, it does not add behavioral context beyond stating it returns a 'JSON string with page info and unified diff'—no mention of permissions, rate limits, 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 highly concise: one sentence for purpose, a formatted Args list, and a Returns line. Every sentence serves a clear purpose with no wasted words, and the structure is front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 comprehensive parameter descriptions, the description adequately explains the tool's functionality and output format. Minor gaps exist (e.g., no mention that both versions must exist), but overall it is sufficient for a simple diff 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 already provides detailed descriptions for all three parameters (100% coverage), including an example for page_id. The description's parameter list adds no new meaning beyond restating the parameter names, so it meets the baseline but does not 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 tool 'get a unified diff between two versions of a Confluence page', using a specific verb and resource. This distinguishes it from sibling tools like 'confluence_get_page' (which retrieves full page content) and 'confluence_get_page_history' (which lists version 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 the tool is used for comparing page versions, but provides no explicit guidance on when to use it versus alternatives (e.g., 'use this for diffs, use confluence_get_page for full content'). No exclusions or when-not-to-use scenarios are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint: true, confirming write behavior. The description adds context: read-only mode check, Jira client availability, and error handling (ValueError for invalid JSON). It also describes return format (JSON string with success/validation result). This goes beyond the annotations, though it omits details like partial batch failure handling.
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 three sentences plus structured Args/Returns/Raises sections. It is front-loaded with the purpose and uses clear formatting. No redundant information, but it could be slightly tighter by merging some details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers core purpose, parameters, and errors. However, it lacks transactional semantics (e.g., whether all issues are created atomically or partially), rate limits, or permission requirements. For a batch mutation tool, this missing context reduces completeness given 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%, so the baseline is 3. The description adds minimal value beyond the schema: it reiterates that issues is a JSON array string and mentions validate_only, but the schema already provides full documentation, including an example for issues.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 multiple Jira issues in a batch.' It uses a specific verb ('Create') and resource ('multiple Jira issues'), and the batch nature distinguishes it from the sibling tool jira_create_issue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use batch versus singular creation. While the name and context imply the batch variant, there is no guidance on trade-offs, alternatives (e.g., jira_create_issue), or when validate_only should be used. The usage is implied but not articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. The description adds context on return format (JSON string with watcher count and list) and a potential ValueError, which is consistent with the read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear single-line purpose followed by structured Args/Returns/Raises sections. It is front-loaded but the Args section is somewhat redundant with the schema.
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 tool with one parameter, the description sufficiently covers purpose, return format, and error conditions. No gaps are apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of the parameter with a description. The tool's description repeats the parameter name but adds no new 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 'Get the list of watchers for a Jira issue,' using a specific verb and resource. It distinguishes itself from sibling tools like jira_add_watcher 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 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, nor does it mention prerequisites like issue existence or permission requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. The description adds that fields are deduplicated across issue types, returns empty list on error, and raises ValueError if client not configured, providing useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded. The docstring format includes Args/Returns/Raises but is efficient overall. Minor redundancy in repeating parameter description but still concise.
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 fully explains return format (list of fields with attributes) and error handling (empty list, ValueError), covering all necessary context 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% (one parameter described). The description repeats the parameter detail from the schema (project key with example) without adding significant new semantics, meeting the baseline for high 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 it retrieves fields available on issues of a project, deduplicated across issue types, distinguishing it from sibling tools like jira_get_create_fields which likely target create screen fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like jira_get_create_fields or jira_get_project_issue_types. The description mentions 'create schema' but does not clarify when this tool is preferred over others.
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 does not contradict the readOnlyHint annotation. It adds value by explaining the return format (JSON string with pagination info), which goes beyond the annotations. However, it does not disclose additional behavioral traits like rate limits or authentication 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 concise and well-structured: a clear opening sentence followed by a parameter list and a return description. Every element is necessary and no filler is present.
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 (3 parameters, output schema exists), the description adequately covers the core functionality, parameters, and return type. It could mention authentication or project access constraints, but overall it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the baseline is 3. The description restates parameter names and descriptions from the schema without adding new meaning or clarification beyond what is already 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 'Get all issues for a specific Jira project,' specifying the verb (Get) and the resource (issues by project key). This distinguishes it from sibling tools like jira_get_board_issues or 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of when not to use it or which sibling tools might be more appropriate for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states it moves issues and removes from sprints, matching the readOnlyHint=false annotation. It also adds context by documenting that a ValueError is raised in read-only mode or if the Jira client is unavailable, which provides additional behavioral insights beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with clear sections: a one-sentence summary, then Args, Returns, and Raises. Every sentence is informative and no word is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, the description is fairly complete. It covers the core action, parameter format, return value, and error conditions. However, it could provide more detail on output structure or side effects (e.g., impact on sprint planning).
Complex tools with many parameters or behaviors need more documentation. Simple tools 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, issue_keys, is fully described in the input schema (100% coverage). The description repeats this information but adds no new semantics. The presence of an internal 'ctx' parameter in the description (not in the schema) is minor noise but does not add meaningful guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 its effect ('removing them from any sprint'). The verb 'move' and resource 'issues' are specific, and the effect distinguishes it from siblings like jira_add_issues_to_sprint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives (e.g., jira_add_issues_to_sprint). It lacks prerequisites, such as requiring an authenticated session, and does not mention cases where the tool 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 show readOnlyHint=false, consistent with the 'Remove' action. The description includes a Raises section for ValueError, which adds some transparency, but it does not disclose permissions needed or behavior if the user is not a watcher.
Agents need to know what a tool does to the world before calling it. Descriptions 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 followed by structured Args, Returns, Raises. It is front-loaded and every part 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 tool with an output schema, the description covers purpose, parameters, errors, and cloud vs server distinction. It is nearly complete, though lacks mention of required field (though schema 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?
The input schema has 100% coverage with descriptions. The description repeats parameter info in Args, but adds little beyond the schema. Baseline 3 applies as schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Remove' and identifies the resource 'a user from watching a Jira issue'. It clearly distinguishes the tool from siblings like '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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions Server/DC vs Cloud via parameters but does not explicitly state when to use this tool over alternatives or when not to use it. It lacks direct guidance on usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation 'readOnlyHint: true' already indicates read-only behavior. The description adds minimal additional behavioral context, such as the return format (JSON string). No side effects, auth needs, or rate limits are mentioned, but the read-only nature is sufficiently implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a clear first-line summary followed by an Args section. No superfluous information; every sentence serves a purpose. It is front-loaded and 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?
Given the presence of an output schema (as per context signals), the description does not need to detail return values. It covers the tool's purpose, parameters, and return type sufficiently. The tool is simple and well-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description repeats the parameter names and purposes (page_id, version, convert_to_markdown) but adds no significant new semantic meaning beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a historical version of a specific Confluence page' with a specific verb and resource. It distinguishes itself from sibling tools like 'confluence_get_page' (current version) and 'confluence_get_page_diff' (diff), as the purpose implies historical retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool or when not to. It lacks guidance on alternatives or prerequisites. The purpose is clear, but no direct usage instructions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, so the description does not need to restate mutability. It adds context by mentioning ValueError for read-only mode or client unavailability. However, it lacks details on permissions, ID validation, or concurrency behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and structured with clear sections for Args, Returns, and Raises. It avoids unnecessary text, though it could be slightly more streamlined by integrating parameters inline.
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 of a reply tool, the description covers key aspects: parameters, return type (JSON string), and error conditions. It is complete enough for basic use, though it could mention idempotency or the format of the comment ID.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 baseline is 3. The description repeats the parameter descriptions from the schema (e.g., 'Markdown format' for body). It adds minimal extra value beyond what is already in the schema, though the returns and raises sections provide some context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Reply to') and the resource ('an existing comment thread on a Confluence page'). The title and description differentiate it from sibling tools like 'confluence_add_comment' (which adds a top-level comment) and 'confluence_get_comments' (read operation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying 'Reply to an existing comment thread', distinguishing it from adding a new comment. However, it does not explicitly mention when not to use or list alternatives, leaving some room for interpretation. The distinction from 'confluence_add_comment' is clear but not spelled out.
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 include destructiveHint: true, indicating mutation, and the description explicitly mentions raises ValueError for read-only mode or unavailable client. It also describes the return type. However, it doesn't detail permissions or whether the comment is fully replaced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with Args, Returns, Raises and is mostly concise. However, it includes 'ctx: The FastMCP context' which may be unnecessary for an agent selecting the tool, slightly reducing 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 complexity, the description provides necessary purpose, input, output, and error condition. It lacks some detail like requiring an existing comment or full replacement behavior, but overall complete for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all parameters. The description repeats parameter names with brief explanations but adds little beyond the schema. 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 'Edit an existing comment on a Jira issue,' which is a specific verb and resource. It distinguishes itself from siblings like jira_add_comment and jira_update_issue by focusing on editing an existing comment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives like jira_add_comment or jira_update_issue. Usage is implied from the tool name and description, but no clear guidance on exclusions or prerequisites is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint: true, and the description does not contradict this. It adds return format info, which is helpful. No additional behavioral traits are needed beyond what annotations 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 succinct with a clear purpose sentence, structured parameter list, and returns note. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter tool with full schema descriptions and an output schema, the description covers purpose, all parameters, and return values, leaving no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains parameters thoroughly. The description's Args section merely repeats this information without adding new meaning, warranting a baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves issues linked to a board with JQL filtering, distinguishing it from related siblings like jira_get_sprint_issues and jira_get_project_issues.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives, nor does it mention when not to use it. The purpose is implied but not contrasted with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the readOnlyHint annotation by stating form IDs are UUIDs and the return type is a JSON string. No contradictions with annotations are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a one-line summary followed by Args/Returns sections, making it easy to scan. It is concise without unnecessary detail, though it could be slightly more terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter and an output schema (mentioned in context), the description adequately explains input, output, and basic behavior. It lacks error specifics but is sufficient for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage and a single well-described parameter (issue_key), the description adds minimal value beyond restating the parameter purpose. Baseline expectation is met.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 all ProForma forms for a Jira issue, using the specific 'ProForma' term and referencing the 'new Jira Forms REST API,' which distinguishes it from other Jira-related tools among the siblings.
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 mentions the API type but does not explicitly guide when to use this tool over the sibling jira_get_proforma_form_details. It lacks when-to-use or when-not-to-use guidance, leaving differentiation implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint: true, so the description's lack of additional behavioral disclosure is acceptable. It mentions the return format ('JSON string representing the worklog entries') but does not disclose pagination, authentication, or other behaviors beyond 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 extremely concise: two lines of purpose and an Args block. It front-loads the action and resource, includes parameter documentation, and has no wasted words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, read-only) and has an output schema, so the description does not need to explain return values. It provides sufficient information for an agent to understand purpose and required input.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 single parameter 'issue_key' with a description and pattern. With 100% schema coverage, the description's additional 'Args' section provides no new meaning beyond the schema. Baseline score 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 worklog entries for a Jira issue,' specifying the verb 'get', the resource 'worklog entries', and the scope 'for a Jira issue.' This distinguishes it from sibling tools like 'jira_add_worklog'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving worklogs but does not explicitly state when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. Sibling tool names suggest a counterpart 'jira_add_worklog' but no direct guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool raises ValueError if in read-only mode or if the Jira client is unavailable, which adds context beyond the destructiveHint: true annotation. It also specifies the return format (JSON string or error message). However, it doesn't detail any side effects (e.g., impact on sprint issues) or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for Args, Returns, and Raises. However, it repeats information already present in the schema, making it slightly longer than necessary. It could be more succinct by omitting the parameter list and focusing on behavioral insights.
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 (6 parameters, 1 required) and the presence of a detailed input schema and output schema, the description covers the essential aspects: what it updates, return format, and error conditions. It lacks an example or typical use case but is adequate for a mutation tool with clear 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 input schema already has 100% coverage with descriptions for all parameters. The description repeats the parameter names, their optionality, and for 'state' provides valid enum values (future|active|closed). This adds minimal new meaning 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 clearly states the tool updates a Jira sprint and lists the specific fields that can be modified (name, state, start_date, end_date, goal). This distinguishes it from sibling tools like jira_create_sprint (create) and jira_get_sprints_from_board (read). The verb 'update' and resource 'jira sprint' are precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to modify an existing sprint but provides no explicit guidance on when to use vs alternatives, such as jira_create_sprint for new sprints or jira_transition_issue for issue state changes. No 'when not to use' or exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations by mentioning that it raises ValueError in read-only mode or when client is unavailable. The existing destructiveHint annotation is consistent with the mutation, and the description does not contradict it.
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 full docstring, which includes structured Args and Returns sections. While clear and informative, it is slightly verbose for a tool description, but still efficiently presents key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create operation with two clear parameters and an output schema provided, the description covers all necessary information: what it does, how to use it, error conditions, and return format. No 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 description coverage is 100%, and the description does not add extra meaning beyond the schema's parameter descriptions ('The ID of the page to add a comment to' and 'The comment content in Markdown format'). 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 'Add a comment to a Confluence page', which is a specific verb+resource. It distinguishes from sibling tools like 'confluence_reply_to_comment' (for replying to existing comments) and 'confluence_get_comments' (listing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives like 'confluence_reply_to_comment'. The usage is implied but not clearly defined, leaving room for ambiguity despite the straightforward action.
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 modification. The description adds that the tool raises ValueError in read-only mode or if the Confluence client is unavailable, providing useful behavioral context beyond annotations. However, it does not detail behaviors such as what happens if the text selection is not found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear one-line purpose followed by Args, Returns, and Raises sections. It is front-loaded but slightly verbose; a more concise version could omit redundant parameter details already covered by the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and detailed schema coverage, the description adequately explains the return value (JSON string) and error conditions. It covers all essential aspects: action, inputs, output, and failure modes, making it 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 coverage is 100% with descriptions for all parameters. The description's docstring repeats this information without adding significant new semantics. The function signature and argument descriptions align with the schema, but no additional meaning beyond what the schema provides is introduced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('add an inline comment anchored to a text selection on a page'), specifying the resource (page) and the unique anchoring aspect. This distinguishes it from sibling tool 'confluence_add_comment' which adds a general comment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for adding a comment anchored to specific text, but does not explicitly state when to use this tool vs. alternatives like 'confluence_add_comment' or 'confluence_reply_to_comment'. No exclusion criteria or contextual prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by detailing behavior: it notes read-only mode raises ValueError, explains the conditional ServiceDesk API usage for the public parameter, and states the return type as JSON string. Annotations only have destructiveHint=true, so the description significantly enhances 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 succinct with clear sections for Args, Returns, and Raises. Every sentence is informative and free of redundancy. At 7 lines, it is appropriately sized and front-loaded with the primary 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 has 4 parameters (2 required) and an output schema (though not shown), the description covers behavior, error cases, and return type. It does not detail the exact JSON return structure but that is likely in the output schema. Overall, it is sufficiently complete for correct 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?
Schema description coverage is 100%, with detailed descriptions for each parameter. The tool description adds minimal new meaning beyond the schema, mostly restating parameter purposes. Baseline score of 3 is appropriate as schema carries the 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 explicitly states 'Add a comment to a Jira issue', which is a clear verb+resource combination. It distinguishes itself from siblings like 'jira_edit_comment' and 'confluence_add_comment' by specifying Jira and adding a new comment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description explains parameter usage (visibility vs public), it does not explicitly state when to use this tool over alternatives like 'jira_edit_comment' for editing or 'confluence_add_comment' for Confluence. Usage context is implied but not directly contrasted.
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 value beyond annotations by mentioning error conditions (ValueError for read-only mode or Jira client unavailable) and return type (JSON string). Annotations only indicate destructiveHint=true.
Agents need to know what a tool does to the world before calling it. Descriptions 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 main purpose, and well-structured with Args, Returns, Raises sections. No wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description includes return type and error conditions, which is sufficient given the presence of an output schema. However, it does not mention prerequisites like board existence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description merely lists parameters without adding new semantic context beyond what is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create Jira sprint for a board', specifying the action (create) and resource (sprint). It distinguishes from sibling tools like jira_update_sprint and jira_get_sprints_from_board.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives, such as jira_update_sprint. Usage is implied by the tool name and parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. The description adds useful behavioral details: project keys always uppercase, filter configuration, and a possible ValueError. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses a verbose docstring format with extraneous sections (e.g., 'ctx' parameter). The main purpose is front-loaded, but the returns section repeats information from the description and could be more 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 output schema exists, the description appropriately covers return behavior (uppercase keys, filter) and error handling. Only one parameter with full schema coverage; no missing essential 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 single parameter 'include_archived' is fully described in the input schema (100% coverage). The tool description adds no further semantics beyond the schema's description and default 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 'all Jira projects', and scope 'accessible to the current user', effectively distinguishing it from sibling tools that operate on specific projects or other Jira entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies the context of filtering via JIRA_PROJECTS_FILTER and accessibility, guiding when results are limited. However, it does not explicitly exclude usage for specific project queries or mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so no safety disclosure needed. The description adds context about the return format (ADF design structure, JSON string or error object), which is valuable beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear first sentence stating purpose. It includes an Args and Returns section, which is structured but slightly verbose with boilerplate like 'Uses the new Jira Forms REST API.' Still, it is efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 required params, no nested objects) and presence of output schema, the description covers retrieval purpose, parameters, and return type. No additional guidance on pagination or edge cases 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 description does not need to add much. The description's Args block repeats similar information as the schema parameter descriptions, offering no 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 'Get detailed information about a specific ProForma form,' using a specific verb and resource. It distinguishes from sibling tools like jira_get_issue_proforma_forms (list) and jira_update_proforma_form_answers (update).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool vs alternatives. It mentions the API used but lacks guidance on when not to use it or how it differs from the list tool. The usage is implied by the need for both issue_key and form_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint: true. The description adds that the tool returns a JSON string list of label objects, which gives some behavioral context. However, it does not discuss error handling, authorization needs, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single introductory sentence followed by structured Args and Returns blocks. Every part earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, read-only, returns a JSON list). The description clearly states the goal, input, and output format. With an output schema present, no further detail on return values 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 parameter description in the schema is detailed (including examples and content type variants). The description itself only paraphrases the parameter name and purpose, adding minimal 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 verb 'Get' and resource 'labels' for Confluence content (pages, blog posts, or attachments). It distinguishes from siblings like 'confluence_add_label' which adds labels, and other tools that retrieve different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The purpose implies its use for retrieving labels, but there is no mention of when not to use it or any comparative context with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's main contribution is clarifying that empty lists denote unrestricted operations and raising ValueError when client is not configured. This adds value beyond what annotations provide, though the safety profile is already well-covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured, and front-loaded. The three-line summary followed by detailed return format, args, and raises sections efficiently communicates all essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, read-only retrieval), the description fully explains the return format including the structure of restriction lists and error conditions. The presence of an output schema is not required as the description already provides sufficient detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'page_id' is described identically in the schema and the tool description ('The ID of the page'). With 100% schema coverage, no additional meaning is added, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives such as confluence_check_content_permissions or confluence_set_page_restrictions. Usage is implied through the description of what it returns, but no exclusions or contextual cues are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so no side effects are expected. The description adds operational details: the two different APIs used depending on deployment type, and the return format. This supplements the annotations well without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args and Returns sections, and the main purpose is front-loaded. However, it is slightly verbose with repeated parameter details that are already in the schema. It could be more concise while retaining clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (not shown but indicated), the description's mention of the return format is sufficient. It covers the cloud/server distinction and parameter behaviors. For a 3-parameter tool with good schema, this is complete enough, though lacking usage examples.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for each parameter. The tool description repeats some parameter info but adds the cloud vs server distinction for group_name, and the Returns section clarifies the output. This adds marginal 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 'Search Confluence users using CQL (Cloud) or group member API (Server/DC).' This provides a specific verb and resource, and distinguishes it from sibling tools like confluence_search (which searches content, not users).
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 explains the difference between Cloud and Server/DC usage, but does not explicitly guide when to use this tool over alternatives like confluence_search or jira_get_user_profile. Usage context is implied but not formally stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the annotations: it explicitly states the destructive replacement behavior and what happens when parameters are omitted. Annotations already include destructiveHint=true, so the description reinforces and elaborates. It also documents the return type and error condition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with sections (Args, Returns, Raises), which aids readability. However, the Args section is verbose and largely redundant with the input schema, adding unnecessary length. The first sentence is clear, but the overall description could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, behavior, parameters, return type, and error conditions. Given that an output schema exists, the return description is sufficient. It provides a complete understanding of the tool's functionality without relying heavily on the schema or 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 baseline is 3. The Args section in the description largely repeats the schema descriptions (e.g., Account IDs vs usernames). It adds minimal new semantics, such as clarifying that omitted parameters remove restrictions, which is already implied by the schema defaults. Therefore, it does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Set view and edit restrictions on a Confluence page.' It uses a specific verb ('Set') and resource ('restrictions on a Confluence page'), distinguishing it from sibling tools like 'confluence_get_page_restrictions' which retrieve 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 explains that the tool 'Replaces all existing restrictions with the provided lists' and that omitting parameters removes restrictions. This provides clear context on when to use the tool, but it does not explicitly mention when not to use it or point to alternatives like the get tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint: true. The description adds valuable behavioral details: it raises NotImplementedError for on-prem, and the limit parameter only limits response data but still fetches all data. This goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args, Returns, and Raises sections. It is concise and front-loaded, with every sentence providing necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's batch nature, readOnly annotations, and presence of output schema, the description covers purpose, parameters, return type, and error conditions completely. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 has 100% coverage with descriptions. The description's Args section re-describes parameters but adds minimal new meaning beyond the schema. Given high 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 tool gets changelogs for multiple Jira issues, specifying 'Cloud only'. The verb 'Get' and resource 'changelogs for multiple Jira issues' distinguishes it from sibling tools like jira_get_issue, which retrieves single issue details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Cloud only' and raises NotImplementedError for Server/Data Center, providing a clear context. However, it does not explicitly state when to use this tool versus alternatives (e.g., jira_get_issue for individual changelogs), nor when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include destructiveHint: true, so the description doesn't need to reiterate. It adds that a ValueError is raised in read-only mode or if the Jira client is unavailable, and states the return format. 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 very concise, using a clear structure (Purpose, Args, Returns, Raises). Every sentence adds value, and the main purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter destructive tool, the description covers purpose, parameter, return, and error conditions. The output schema exists, and annotations provide safety cues. No further information 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 schema already describes the issue_key parameter well (with example and pattern). The description only repeats 'Jira issue key' with no additional semantics. With 100% schema coverage, baseline is 3, and no extra 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 the action ('Delete') and resource ('an existing Jira issue'), and includes the required parameter. It is distinct among sibling tools that modify issues (update, transition, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool over alternatives (e.g., transition_issue to close). It mentions read-only mode and client availability as error conditions, providing some context, but no guidance on when not to delete.
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, which the description aligns with by describing a read operation. The description adds behavioral context by specifying the returned data (dates and optional status history), which annotations do not cover. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear purpose line, followed by what returns, then an Args section, and a Returns line. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description sufficiently covers input parameters and return value format (JSON string with issue dates and status tracking data). It is complete for a read tool with moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The description's Args section restates parameters without adding new meaning. Baseline 3 is appropriate as the schema carries the semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get date information and status transition history for a Jira issue', using a specific verb and resource. It distinguishes from sibling tools like jira_get_issue or jira_get_issue_sla 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 retrieving dates and status history, but it does not explicitly state when to use it versus alternatives like jira_get_issue. No when-not or exclusion criteria are provided, limiting guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reads as a read operation, which aligns with the readOnlyHint annotation. It does not add further behavioral context (e.g., pagination or caching) but 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, complete sentence with no extraneous information. It is front-loaded and concise.
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 required parameter, read-only, output schema exists), the description is sufficiently complete. No additional information is necessary for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the parameter (project_key) with a description and pattern. The description adds no extra meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('all components'), and the context ('for a specific Jira project'). It directly distinguishes from sibling tools like jira_get_project_versions or jira_search, which deal with different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving components of a known project, but does not explicitly exclude scenarios or mention alternatives. It is clear enough 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include readOnlyHint=true, and the description confirms the read-only nature. It adds minimal behavioral context (e.g., 'for a specific project') but does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence, front-loaded with the verb and resource, with no unnecessary 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 single parameter, readOnlyHint annotation, and presence of an output schema, the description fully covers the tool's purpose and input requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter 'project_key' is well-documented with a description and pattern. The description adds no additional parameter information beyond the schema, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get all fix versions for a specific Jira project.' with a specific verb and resource, distinguishing it from siblings like jira_get_project_components or jira_get_all_projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving versions but provides no explicit guidance on when to use this tool over alternatives (e.g., jira_get_project_issues). The context of siblings is broad, but no exclusions or conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, and the description adds that the tool returns a JSON string of transitions, providing behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with one sentence for purpose and an Args/Returns section. It could be slightly more streamlined by omitting redundant parameter description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and an output schema (present but not shown), the description adequately explains what it does and returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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_key, with a detailed description including pattern and example. The description adds no extra parameter information, meeting 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 verb 'Get' and the resource 'available status transitions for a Jira issue', distinguishing it from sibling tools like jira_transition_issue which performs transitions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose is clear, and the agent can infer that this tool is for reading transitions before performing one. However, no explicit when-to-use or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true, and the description adds value by listing specific error conditions (ValueError for missing link_id, read-only mode, or Jira client unavailability) and stating the return format (JSON success string).
Agents need to know what a tool does to the world before calling it. Descriptions 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 at 3 sentences, front-loading the purpose, then listing arguments, returns, and raises in a structured format. Every sentence is informative and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (1 param, clear schema, annotations with destructiveHint, and an output schema indicated by 'Returns: JSON string indicating success'), the description provides sufficient context including error conditions, making it complete for an AI agent to invoke 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?
Schema coverage is 100% (1 parameter with a clear description in the schema). The description restates the parameter's purpose but adds no additional meaning beyond what the schema already provides, so it meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Remove a link between two Jira issues.' This is a specific verb+resource combination that distinguishes it from sibling tools like jira_create_issue_link and jira_link_to_epic, which create links.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, but the action is self-explanatory and the parameter link_id is clearly indicated. There is no guidance on prerequisites or when not to use, which limits its utility for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, confirming this is a read-only operation. The description adds details about pagination (start_at, page_token) but does not disclose additional behavioral traits beyond what annotations offer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns) but is slightly verbose due to the JQL examples and parameter details. It is efficient but not exceptionally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the return value as a JSON string with pagination info. Combined with an output schema (as indicated by context signals), it provides enough information for an AI agent to understand the tool's input and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the baseline is 3. The description enhances this by providing JQL examples, clarifying the expand parameter options, and noting pagination token usage (Cloud-only). This adds value beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search Jira issues using JQL', which is a specific verb-resource combination. It distinguishes itself from sibling tools like jira_get_issue (single issue) and jira_get_board_issues (board-specific) by focusing on flexible JQL queries.
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 general JQL-based searching, but does not explicitly state when to avoid it or list alternative tools for specific searches. However, the context is sufficiently clear for most scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds behavioral details: projects are ranked, not all are fetched, keys are returned uppercase, and an environment variable can filter results. This adds value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with a header, usage explanation, and structured Args/Returns sections. It is concise but includes some redundancy (e.g., repeating parameter descriptions present in schema). Still efficient and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 params, output schema exists), the description covers purpose, behavioral quirks (uppercase keys, filter), and return type. It does not address error cases or empty query behavior, but is generally complete for this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. The description adds little beyond what the schema already provides for parameters (e.g., 'query: Name or key prefix' repeats schema). The behavioral notes about uppercase keys and filter are not parameter-specific. 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 'Search for Jira projects by name or key prefix' with a specific verb and resource. It distinguishes itself from siblings like jira_get_all_projects by noting it uses a picker endpoint for ranked results without fetching all 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 implies when to use this tool (searching by name/prefix) versus alternatives (like fetching all projects), but does not explicitly state when not to use or list alternatives. The mention of the JIRA_PROJECTS_FILTER provides additional 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 include destructiveHint: true, and the description specifies return value (JSON string of updated labels) and potential errors (ValueError for read-only or client issues). 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?
Very concise with a clear structure: action sentence, use-case list, then args/returns/raises. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple tool with two required params and an output schema mentioned, the description covers purpose, usage, and behavior. Lacks explicit permission or rate-limit warnings, but annotations hint at destructive action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with detailed descriptions for both parameters. The description merely repeats parameter names without adding extra meaning, so baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add label to Confluence content (pages, blog posts, or attachments)', specifying the verb and resource. It distinguishes from sibling tools focused on other actions like comments or pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides concrete use cases via bullet points (categorizing, tracking status, filtering). While it doesn't explicitly mention when not to use, the context is clear given the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint: true, so description need not restate safety. Adds value by mentioning the wrapped endpoint (POST) and return format (JSON with hasPermission boolean). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with purpose, then endpoint, availability constraint, and return format. No redundant information; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, description adequately covers purpose, usage scope, and return. Lacks examples or error handling, but sufficient for a simple read-only check 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 4 parameters with descriptions (100% coverage). Description adds common operation values and example IDs, providing modest additional guidance 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?
Description clearly states 'Check whether a user or group can perform an operation on specific content', specifying the action (check) and resource (content permissions), which distinguishes it from siblings like confluence_get_page_restrictions or confluence_get_space_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?
Explicitly notes the tool is only for Confluence Cloud and that Server/Data Center use different APIs, guiding when not to use. Does not directly name alternative tools, but the context provides alternatives via sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the description need not repeat that. The description adds behavioral details such as support for pagination (start, limit parameters) and content conversion (markdown vs HTML), which are not 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear summary followed by a parameter list. It is concise but could be slightly more streamlined by leveraging the schema descriptions instead of duplicating them.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and annotations, the description adequately covers all necessary contextual information: it explains the return format (JSON string), pagination, and content conversion options. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for all 7 parameters. The description adds value by clarifying the relationship between 'include_content' and 'convert_to_markdown' (e.g., 'Convert content to markdown if include_content is true'), which is not fully captured in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves child pages and folders of a specific Confluence page, using a specific verb and resource. This distinguishes it from sibling tools like 'confluence_get_page' which retrieves a single 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 usage for retrieving page hierarchy but does not explicitly state when to use this tool versus alternatives like 'confluence_search' or 'confluence_get_space_page_tree'. No exclusions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description discloses automatic version creation for existing files and that comment/minor_edit apply to all files. This adds 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: purpose, efficiency, versioning, use cases, then Args/Returns. It is concise and front-loaded. Minor redundancy with schema descriptions does not detract.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of annotations, output schema, and comprehensive schema descriptions, the description provides complete context for the tool's behavior, parameters, and usage scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with detailed parameter descriptions. The tool description adds minimal extra parameter info beyond the schema, so 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 uploads multiple attachments in a single operation. It differentiates from the sibling 'confluence_upload_attachment' by highlighting efficiency and batch capability.
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 lists specific use cases (bulk upload, batch update) and implies not using it for single uploads. It does not explicitly mention when to use alternative singular tool, but the sibling name is available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that links appear in the issue's 'Links' section and can be clicked, adding behavioral context beyond the destructiveHint annotation. It also notes return value and error conditions, but lacks details on permissions or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long with an Args section that largely duplicates the schema. While structured, it could be more concise by removing redundancy. It is adequately sized but not optimal for quick comprehension.
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 parameter count and full schema coverage, the description provides sufficient context for usage. It mentions the return value (JSON indicating success/failure) and expected exceptions (ValueError), making it fairly complete despite missing exact output schema details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description adds examples for issue_key format, URL, and icon size (16x16). It clarifies the purpose of each parameter beyond the schema, justifying a score above the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a remote issue link (web link or Confluence link) for a Jira issue. It specifies the verb 'create' and resource 'remote issue link', and distinguishes from siblings like jira_create_issue_link (which links Jira issues internally) by explicitly mentioning external links.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that it adds web and Confluence links to Jira issues, providing clear context for when to use it. However, it does not explicitly mention when not to use it or alternatives such as jira_create_issue_link for internal issue linking.
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 readOnlyHint: true, which matches the read-only nature. Description adds that it raises NotImplementedError on Cloud, which is important behavioral context beyond annotations. Also describes return format as JSON string with queue list and pagination metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with a clear structure: one-line purpose, platform restriction, args list, returns, raises. Front-loaded with purpose, 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 presence of an output schema (context indicates true) and annotations, the description is sufficiently complete. It covers the error case and return format. Could add more usage context, but current level is adequate for a read-only list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with descriptions. Description reiterates parameters with slight additions (e.g., 'Service desk ID (e.g., '4')'), adding minimal value beyond schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get queues for a Jira Service Desk' with a specific verb and resource. It distinguishes from siblings by specifying Server/Data Center only and using Jira Service Desk context, which is unique among the 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Server/Data Center only. Not available on Jira Cloud,' providing clear context on when to use. Does not compare directly to sibling tool like jira_get_queue_issues, but the restriction is 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?
Annotations already indicate readOnlyHint=true, and the description reinforces this by starting with 'Get.' It adds value by stating the return format ('JSON string representing a list of sprint objects') and parameter defaults, going beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using a clear docstring format with a one-line summary followed by parameter definitions. Every sentence adds value, and there is no redundant or vague language.
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 all parameters and the return type. Given the tool's simplicity and presence of an output schema, it is sufficiently complete. However, it could mention error handling or prerequisites (e.g., board existence) for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds meaning for the state parameter by listing valid values and noting that None returns all sprints. It also clarifies start_at as 'Starting index' and limit as 'Maximum results,' matching schema but providing context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get jira sprints from board by state,' specifying both the action and the resource. It distinguishes itself from sibling tools like jira_get_sprint_issues and jira_get_agile_boards by focusing on sprints from a board with optional state filtering.
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 listing parameters and defaults, such as state='active' and limit=10, but does not explicitly state when to use this tool versus alternatives like jira_get_sprint_issues or jira_get_agile_boards. It lacks guidance on when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the async behavior, polling, and the possibility of a new key. It also mentions error conditions. Annotations already include destructiveHint=true, so the description complements this without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear header, behavior paragraph, and argument list. It is front-loaded with the purpose. However, the section on async polling could be slightly more concise.
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 output schema exists, the description sufficiently explains the return value and error conditions. It covers Jira Cloud limitation, async nature, and key change. No 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?
Input schema has 100% coverage with descriptions for both parameters. The description repeats similar info (e.g., pattern, key assignment) but does not add significant new meaning. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Move' and the resource 'Jira issue to a different project'. It distinguishes from sibling tools like 'jira_move_issues_to_backlog' by specifying cross-project move. The phrase 'Jira Cloud only' 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?
The description provides context on when to use the tool: for cross-project moves, keeping issue type. It mentions asynchronous polling and timeout. It does not explicitly list alternatives or when not to use, but the context is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint, so the mutation is clear. Description adds the partial update behavior (only specified fields change). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured: purpose first, then usage hints, then parameter list. Every sentence adds value. No redundant fluff despite listing parameters which are already in schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, partial update, use cases, parameters, and return type. Lacks error conditions and permissions, but given output schema and annotations, it is sufficiently complete for a moderate-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for each parameter. The description's Args list adds no extra meaning beyond the schema, so it meets the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool updates an existing fix version in Jira. Includes specific use cases (archiving, renaming, shifting release dates) which distinguishes it from related tools like jira_create_version and jira_get_project_versions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states that only provided fields are modified, and describes when it is useful (archiving, etc.). Does not explicitly contrast with other update tools or state when not to use, but the context is adequate.
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, but the description adds meaningful context: it details the different copy mechanisms for Cloud vs Server/DC, notes that attachments are not copied on Server/DC, and lists raised exceptions (ValueError). This goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns, Raises). Every sentence is necessary and contributes to understanding. No redundant or verbose 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?
Given the tool's complexity (platform differences, optional parameters, output schema), the description adequately covers behavioral differences and error conditions. The return value is specified as JSON string, and the output schema exists, so no additional details 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%, so the description's Args section largely duplicates schema information. It adds no extra semantic value beyond restating parameter names and their basic function.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 ('Copy a Confluence page to a new location') and distinguishes the tool from siblings like 'confluence_move_page' by noting it copies rather than moves. It also specifies platform-specific behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to copy a page) and provides caveats (Server/DC path does not copy attachments). However, it does not explicitly state when not to use it or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, which is consistent. The description adds value by mentioning the Cloud-only restriction and the return format (JSON with total views and last viewed date).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one line for purpose, a note, then args and returns. It is well-structured with no unnecessary 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 (2 params, output schema present), the description covers purpose, availability limitation, and return type. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 explains both parameters (page_id and include_title). The description does not add further parameter details, but this is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 view statistics for a Confluence page' using a specific verb and resource. It distinguishes itself from sibling tools like confluence_get_page by focusing on analytics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly notes that this tool is only available for Confluence Cloud, not Server/Data Center, which guides when NOT to use it. However, it does not mention alternative tools for Server/DC users.
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 mark the tool as read-only (readOnlyHint: true). The description adds value by detailing the flat list output, parent_id and depth attributes, and token efficiency. It provides useful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, with a concise intro, key attributes, usage context, and clearly labeled args/returns. Every sentence adds value without redundancy, and it is 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of annotations, a complete output schema, and only two parameters, the description covers all necessary aspects: purpose, usage guidance, behavioral details, and parameter hints. It is fully adequate for an AI agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters (space_key and limit) with 100% coverage. The description adds a minor usage hint ('start with 100 for faster results') but does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the page hierarchy for a Confluence space as a flat list, using specific verbs and resources. It distinguishes itself from siblings like 'get_page_children' by explaining the flat list structure and efficiency, making the purpose very clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using this tool 'to understand space organization before creating/moving pages' and suggests filtering by depth or finding pages by title. It implies the context but does not explicitly exclude alternative tools like get_page_children, though the distinct output makes usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as destructive (`destructiveHint: true`), lowering the bar. The description adds behavioral context: it explains the return value (JSON string) and error scenarios (ValueError for missing parameters or client misconfiguration), which are not covered by 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 structured with clear sections (Args, Returns, Raises) and is concise. Every sentence adds informative value without redundancy. It is well-organized for an AI agent 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 input schema fully describes parameters, an output schema exists, and annotations are present, the description is complete. It covers error handling, return type, and parameter logic, leaving no major gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema description coverage is 100%, but the description adds value by explaining parameter nuances: e.g., 'If omitted with target_space_key, moves to space root' for `target_parent_id`, and the meanings of position options ('append', 'above', 'below'). This goes beyond the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Move a Confluence page to a new parent or space.' This verb-resource combination is precise and distinguishes it from siblings like `confluence_update_page` (which modifies content) and `confluence_delete_page` (which removes pages).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating the tool's purpose, but it does not explicitly compare with alternatives or state when not to use it. It includes error conditions (e.g., need for at least one of target_parent_id or target_space_key) which aids in proper invocation, but lacks direct guidance relative to sibling 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?
Describes filtering to image types, fallback via filename extension, 50 MB size limit, and return format as text summary + ImageContent. Adds value beyond readOnlyHint 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?
Concise, well-structured with clear sections for Args and Returns. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully covers behavior for a single-parameter tool: filtering, fallback, size limit, and return format. No output schema needed given clear 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 already covers issue_key with description (100% coverage). Description reuses but doesn't add new semantic details 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?
Clearly states 'Get all images attached to a Jira issue as inline image content' with specific verb and resource. Distinguishes from siblings like jira_get_issue and jira_download_attachments by focusing on images as inline content.
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?
Implies usage for retrieving images only, but does not explicitly compare to jira_download_attachments or state when not to use. Lacks explicit guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description does not need to repeat that. It adds value by stating the return format (JSON string of objects) and the optional name filter 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: one line for purpose, then Args and Returns sections. Every part is functional with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and an existing output schema, the description covers purpose, parameter usage, and return format, making it fully sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; the description replicates the parameter documentation (name_filter as optional substring). No additional context beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get all available issue link types', specifying the exact action and resource. It is distinct from sibling tools like jira_create_issue_link which deal with creating or removing links.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates the tool retrieves all link types with an optional filter. While no explicit when-not-to-use guidance is given, the purpose is straightforward and well-understood.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include readOnlyHint=true, confirming no destructive side effects. The description adds value by detailing the return format (list with id, name, description, subtask) and the context that this is a safe retrieval operation. No other behavioral traits are disclosed, but the existing annotation covers the key safety aspect.
Agents need to know what a tool does to the world before calling it. Descriptions 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 title line, a usage paragraph, and explicit Args/Returns sections. Every sentence provides necessary information without redundancy. It is concise and 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?
Given the simplicity of the tool (one parameter, no nested objects, and an output schema exists), the description is complete. It covers the purpose, usage, parameter, and return format effectively. There is no 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 coverage for the single parameter project_key is 100%, with a clear description and pattern. The description does not add additional parameter semantics beyond what the schema provides, but it does reinforce the context of project identification. 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' and the resource 'available issue types for a Jira project'. It specifies the output as a list of issue types like Bug, Task, Story, Epic, and explains how to use the returned IDs with get_create_fields, distinguishing it from other Jira 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 explicit guidance on using the returned issue type IDs with get_create_fields, which is a direct follow-up action. However, it does not explicitly mention when not to use this tool or compare it with alternatives like jira_get_project_fields, which may also provide issue type information.
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 description confirms it's a read operation. The description adds the error condition for Cloud, which is useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with clear sections for args, returns, and raises. Purpose is front-loaded and every sentence adds value. No unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter set, annotations, and output schema (implied), the description fully covers the tool's behavior, including the Cloud limitation and return format. 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 already fully describes the project_key parameter with description and pattern. The description adds no additional semantics beyond what the schema provides, so 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 it gets the Jira Service Desk for a project key, and specifies it is Server/Data Center only, distinguishing it from sibling tools that handle other Jira entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly notes it is not available on Jira Cloud and raises NotImplementedError, providing clear context on when not to use. It does not elaborate on alternatives but the specificity of service desk makes it unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark the tool as destructive (destructiveHint: true), and the description adds context about failure modes (ValueError for read-only, client unavailable, invalid format). It also describes mutual exclusivity and parameter dependencies. However, it does not specify behavior if a page with the same title exists (overwrite or fail), which would be additional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately structured with Args, Returns, and Raises sections. It is somewhat lengthy due to parameter details, but every sentence serves a purpose. Some redundancy with schema descriptions exists, but overall efficient given tool complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all essential aspects: purpose, parameters (with mutual exclusivity and defaults), return type (JSON string of created page), and error conditions. An output schema exists, so return value documentation is sufficient. For a creation tool with 11 parameters, completeness is high.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-documented. The description adds value by explaining the rationale for content_file (large bodies), confirming mutual exclusivity of content and content_file, and clarifying that content_format includes 'xhtml' as alias. It also notes defaults and constraints like heading anchors only for markdown.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new Confluence page' as the purpose, with a specific verb and resource. It distinguishes itself from sibling tools like confluence_update_page, confluence_copy_page, and confluence_delete_page by its creation focus. Parameter 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 good context, including mutual exclusivity of content and content_file, optional parent_id, and error cases (read-only mode, invalid format). However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., update vs create) and does not mention prerequisites like space existence.
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, it discloses that files >50 MB are skipped with an error entry, and that contents are embedded as base64 to avoid filesystem access. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded with main action, structured with clear sections. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-parameter tool, description adequately covers return format and size limit. Lacks output schema but explains the response structure sufficiently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter with full schema description; tool description merely repeats schema info. No additional meaning added beyond what 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?
Description clearly states verb 'download', resource 'all attachments for a Confluence content item', and format 'embedded resources'. Differentiates from sibling 'confluence_download_attachment' by specifying 'all 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?
Provides context on why base64 encoding is used and mentions file size limit, but does not explicitly state when to use vs. alternatives like 'confluence_download_attachment' or 'confluence_get_attachments'.
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 details image type detection, handling of ambiguous MIME types via filename extension, skipping images larger than 50 MB with error entries, and base64 encoding. This fully discloses behavior without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but every sentence adds value. It is well-structured with clear bullet points, though it could be slightly more concise without losing key 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?
Given the single required parameter, good annotations, and no output schema, the description fully covers the tool's behavior, including return format (text summary + ImageContent). It addresses edge cases like large files and MIME 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 only parameter, content_id, is fully described in the input schema (100% coverage). The description adds minimal value, only mentioning 'blog post' as an alternative to 'page' and providing an example, which is helpful but not substantive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 all images attached to a Confluence page as inline base64 content, filtering by image types. This specific verb+resource combination distinguishes it from siblings like confluence_get_attachments (all attachments) and confluence_download_attachment (single file).
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 implicitly says when to use (for images only) by stating non-image attachments are excluded, but it does not explicitly name alternative tools for non-images or provide when-not-to-use guidance. The context of sibling tools makes the distinction clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true. Description adds context about return format (JSON string) and potential errors (ValueError), enriching behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with Args list and front-loaded main sentence, but some parameter descriptions are redundant with schema, slightly reducing 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?
Covers all 13 parameters, includes return format description (JSON string), and mentions error conditions. Context signals show high schema coverage and output schema exists, so description is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing baseline 3. Description adds extra meaning, e.g., content_file is for large bodies, emoji accepts any emoji character, table_layout only applies when content_format is markdown.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Update an existing Confluence page', which is a specific verb and resource. Distinguished from siblings like confluence_update_page_section and confluence_create_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implicitly indicates use for full-page updates rather than partial updates, but does not explicitly mention alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations provide destructiveHint: true, and the description adds that existing attachments are updated (new version). It also mentions minor_edit for notification control. This is consistent and provides useful behavioral context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: it opens with the purpose, then explains the two input modes, then lists use cases, and finally provides a clear args section. Every sentence is informative 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 6 parameters and output schema, the description covers the essential aspects: input methods, optional parameters, versioning behavior, and return type. It could mention authentication requirements or error handling, but the description is sufficiently complete for an agent to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by succinctly summarizing the two parameter groups (file_path vs content_base64+filename) and their mutual exclusivity, which is not explicitly stated in the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('upload an attachment') and the resource ('Confluence content (page or blog post)'). It distinguishes itself from sibling tools like confluence_download_attachment and confluence_delete_attachment by focusing on the upload/update functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use file_path vs content_base64, and that only one must be supplied. It also describes the behavior when an attachment already exists (new version created). However, it does not explicitly compare to the sibling confluence_upload_attachments (plural) or mention prerequisites like authentication.
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 annotation 'readOnlyHint: true' is complemented by the description explaining the base64 encoding and the size limit behavior. It adds context about the MCP protocol and error handling, fully disclosing behavioral traits beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the primary purpose, and every sentence provides necessary information without redundancy. It efficiently covers the return format and size constraint.
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 single parameter, thorough schema documentation, and presence of annotations, the description fully covers the return type, error cases, and usage context. No output schema is needed as the return is clearly described.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 comprehensive documentation for the single parameter 'attachment_id', including an example and workflow guidance. The description does not add additional parameter semantics beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Download', the resource 'attachment from Confluence', and the format 'embedded resource' (base64-encoded). It distinguishes from sibling tools like 'confluence_download_content_attachments' by focusing on a single 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 a specific constraint for files larger than 50 MB, and guides the user to find attachment IDs via get_attachments. However, it does not explicitly compare with the alternative 'confluence_download_content_attachments' for multiple downloads.
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?
ReadOnlyHint annotation is present, and the description adds the API endpoint, return structure (JSON with 'results' list), and a note about Cloud vs. Server/Data Center compatibility. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is very concise (5 sentences) with no wasted words. It is front-loaded with the purpose and structured logically: purpose, endpoint, compatibility note, return format, and use case.
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 tool with complete annotations and output schema, the description covers the API endpoint, parameter details (via schema), return structure summary, and use case. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds valuable context for 'space_id' (numeric, not key, with example and how to find it). 'limit' and 'cursor' are standard, but the extra detail on 'space_id' justifies the higher score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all permission assignments for a Confluence space, with a specific verb 'List' and resource 'permission assignments'. The sibling 'confluence_check_content_permissions' targets content permissions, so this tool is well-distinguished.
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 specifies auditing space access as the use case and mentions it is only for Confluence Cloud. It does not explicitly list when not to use it or alternative tools, but the context is clear enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the tool is known to be read-only. The description adds that it returns a JSON string of simplified page objects, which is useful context beyond annotations. No contradictions present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args/Returns sections and front-loads the purpose. It is lengthy due to extensive CQL examples, but this is justified by the complexity of the parameter. Could be slightly more concise, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of CQL queries and the existence of an output schema, the description covers all necessary aspects: parameter usage, filtering, return format, and query syntax. It is fully adequate for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant value for the query parameter, detailing CQL syntax, special characters, and quoting rules. This level of detail is crucial for correct invocation, going far beyond the schema's brief description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search Confluence content using simple terms or CQL,' identifying the specific verb (search) and resource (Confluence content). It distinguishes itself from sibling tools like confluence_search_user (searches users) and jira_search (searches Jira).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides detailed guidance on how to use both simple text and CQL queries, with many examples and notes on quoting. It does not explicitly state when to use this tool vs alternatives, but the context of searching Confluence content is clear without needing 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 aligns with this by describing a read operation. The description adds value by detailing the return content (field metadata, required status, schema) and the parameter origin (issue_type_id from get_project_issue_types). No contradictory information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: a clear first sentence, a single sentence for sibling tool guidance, a parameter list, and a return description. Every sentence serves a purpose with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, the description covers all necessary aspects: purpose, parameters, return format, and cross-reference to related tool. The presence of an output schema is noted implicitly through the return description, making it fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters documented. The description adds semantic value by specifying that issue_type_id comes from 'get_project_issue_types' and provides an example. This goes beyond the schema descriptions, justifying a score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get' and the resource 'fields available for creating an issue of a specific type'. It distinguishes itself from sibling tools like jira_get_field_options, which handles allowed values, making its purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use an alternative tool ('Use jira_get_field_options when a returned field needs its allowed values'). It also implies usage context (retrieving fields for a specific project and issue type). However, it does not explicitly state when not to use this tool or provide comprehensive usage rules.
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 indicate readOnlyHint=true. The description adds critical behavioral details: automatic resolution of global context on Cloud, separate API paths for Cloud vs Server/DC, filtering behavior (contains matches child values), and the compact format option (values_only). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a concise opening sentence, followed by clear paragraphs for Cloud vs Server/DC behavior, then a bulleted Args list. Every sentence adds value, and there is no redundant or verbose 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?
Given the tool's complexity (7 parameters, version-specific behavior, output schema present), the description covers all necessary aspects: field type restrictions, Cloud/Server differences, parameter explanations, filtering, and output format options. The presence of an output schema relieves the description from detailing return structure.
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 meaning beyond the schema: it explains that context_id is auto-resolved to global context for Cloud, that project_key and issue_type are required for Server/DC, and that return_limit is applied after filtering. It also clarifies the contains filter applies to child values in cascading selects.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description precisely states 'Get allowed option values for a custom field' and lists the field types supported (select, multi-select, etc.). It clearly differs from sibling tools like jira_search_fields, which finds field IDs rather than retrieving their options.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on Cloud vs Server/DC usage, explaining when to use context_id versus project_key and issue_type. It implicitly tells the agent when not to use this tool (e.g., for other field types not listed) but does not explicitly mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=true, so the read-only behavior is known. The description adds context about the environment restriction (Server/DC vs Cloud), which is beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns, Raises) and is concise, containing only relevant information. Each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With high schema coverage, clear parameter descriptions, an output schema, and explicit error handling (NotImplementedError), the description is complete and provides sufficient context for correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 4 parameters. The description's Args section repeats parameter names and types but does not add meaningful new information 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 states 'Get issues from a Jira Service Desk queue' which is a specific verb+resource combination. It clearly distinguishes from sibling tools by targeting service desk queues, a unique functionality among the listed Jira 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 explicitly states 'Server/Data Center only. Not available on Jira Cloud.' and mentions raising NotImplementedError if connected to Cloud, giving clear when-to-use and 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 already indicate destructiveHint: true. Description adds details on optional fields and comment, and raises ValueError for various conditions, enhancing 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?
Concise and well-structured: purpose statement, then bulleted args, returns, raises. No unnecessary 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?
Tool has output schema, annotations, and description covers error cases, prerequisites, and optional parameters. Complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. Description adds context beyond schema, such as example JSON for fields and prerequisite for transition_id, but does not fully detail every parameter's behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Transition a Jira issue to a new status', using a specific verb and resource. It distinguishes from related tools like jira_update_issue and jira_get_transitions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit prerequisite instruction to use jira_get_transitions first is present. However, no explicit guidance on when not to use or comparison to 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?
Since no annotations are provided, the description fully discloses behavior. It explains that the tool does not perform login but reports instructions, and details why synchronous Playwright login would cause issues. It also states the outcome: the saved cookie jar is reused automatically.
Agents need to know what a tool does to the world before calling it. Descriptions 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 yet comprehensive. Every sentence adds value: the main purpose is stated first, followed by technical rationale and a clear CLI command. No extraneous information or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (login guide with two optional params and an output schema), the description covers all essential context: why it exists, how authentication works, and what the agent should do. The output schema exists, so explaining return values is not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the 'target' parameter indirectly by mentioning Jira and Confluence, but the 'url' parameter is completely unexplained. This omission leaves uncertainty about its purpose and usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Report how to authenticate.' It distinguishes itself from all sibling tools, which are operational Jira/Confluence actions, by focusing on authentication guidance. The verb 'report' is specific to providing instructions rather than performing actions.
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 explains when to use this tool (when authentication is needed) and when not to use it (avoiding Playwright in-process due to deadlock). It provides a concrete alternative: running the CLI command 'atlassian-cli login <jira|confluence>'. This clearly guides the agent on how to proceed.
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?
Description expands on the destructiveHint annotation by emphasizing irreversibility and deletion of all versions. Adds critical context beyond annotations, with 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections and front-loaded warning, but slightly verbose for a simple operation. Still clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all critical aspects: action, consequences, best practices, parameter source, and return value. Fully adequate for a deletion tool with good annotations and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with detailed parameter description including example and warning. Description adds value by referencing get_attachments tool for finding attachment IDs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Permanently delete an attachment from Confluence' with specific verb and resource. It distinguishes itself from sibling tools like download or get 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?
Provides explicit when-to-use scenarios (remove outdated, clean duplicates, delete sensitive info) and best practices (verify ID, backup, check with owners). Could be improved by stating when not to use, but is still clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description consistently describes a read operation. It adds context by mentioning error handling (returns error object if not found, raises ValueError if client not configured), which goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single-line summary followed by structured Args/Returns/Raises sections. Every sentence adds value, and the purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no nested objects), the output schema exists, and the description covers essential aspects: parameter types, return format (JSON string or error object), and error conditions. It is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter description in the schema lists identifier types, and the tool description elaborates with examples (email, username, key, account ID). With 100% schema coverage, the description adds valuable clarification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Retrieve profile information for a specific Jira user.' It uses a specific verb ('retrieve') and resource ('profile information for a specific Jira user'), distinguishing it from sibling tools like jira_get_issue or jira_search.
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 includes args, returns, and raises sections, specifying the user_identifier parameter with types. It does not explicitly state when not to use it or compare with alternatives, but given the tool's specificity, the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false (write operation). The description adds behavioral context: it uses the dedicated assignment endpoint, raises ValueError in failure modes (read-only mode, client unavailable, user not found), and is more reliable than update_issue. This goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentence intro followed by structured Args/Returns/Raises. No redundancy, front-loaded with key benefit. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (so return values don't need description), and annotations cover safety, the description covers purpose, usage guidance, parameter semantics, and error conditions completely. No gaps for a two-parameter assignment tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline is 3. The description adds value by explaining that 'assignee' can accept a JSON object string from jira_search_assignable_users and that null/empty string triggers unassignment. This clarifies usage beyond the schema's basic type descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Assign a Jira issue to a user'), the resource ('Jira issue'), and distinguishes it from the sibling 'update_issue' by noting it uses a dedicated endpoint and is more reliable. This satisfies the specific verb+resource and differentiation criteria.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance on when to use this tool over the alternative 'update_issue' (which can be silently ignored). Also specifies how to unassign (pass None or empty string) and the acceptable formats for assignee. No exclusions needed beyond this.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=true, which matches the read-only nature of the tool. The description adds context about included Epic links, return format (JSON), and raises ValueError, with no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with Args, Returns, Raises sections. It is front-loaded with the primary purpose and uses minimal but informative text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, 100% schema coverage, and an output schema (implied), the description covers all essential aspects: purpose, key parameters, error handling, and return type. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the `include` parameter's purpose to batch enrichments and reduce tool calls, which goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get details of a specific Jira issue' and mentions included information (Epic links, relationships). It distinguishes itself from siblings like jira_search and sub-getters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that the `include` parameter can inline enrichments to avoid separate tool calls, implying efficient usage. However, it doesn't explicitly contrast with alternatives like jira_get_issue_dates or jira_get_issue_images.
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 a critical behavioral nuance: the Confluence API returns 'application/octet-stream' for most binary files instead of specific MIME types, and advises using filename filtering. This adds significant value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections, bullet points for usage, and accurate parameter documentation. Every sentence adds value without redundancy, achieving efficiency and clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers the tool's purpose, usage, behavioral quirks, and return values (metadata list). With an output schema present, the description completes the picture for an agent to select and invoke the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description still adds meaning by explaining pagination logic and warning about media_type limitations, suggesting the filename parameter as more reliable. This goes beyond the schema's basic 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 explicitly states 'List all attachments for a Confluence content item (page or blog post)' with a specific verb and resource, clearly distinguishing it from sibling tools like confluence_download_attachment or confluence_delete_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 lists useful scenarios like 'discovering files', 'getting attachment IDs for download', and 'checking file existence', providing clear guidance on when to use. However, it does not explicitly mention when not to use or compare with alternatives like confluence_get_page_images.
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?
Consistent with annotations (readOnlyHint=true), adds context about return format (JSON string), metadata options, markdown vs HTML conversion, and token usage warning for HTML.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear Args section, no fluff, each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all needed aspects: identification methods, output format, metadata and conversion options, with an output schema present to handle return details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant meaning beyond the input schema: explains that page_id can be ID, URL, or tiny link, and describes mutual exclusivity. Schema coverage is 100% and description enriches each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets content of a specific Confluence page by ID or title+space, which distinguishes it from sibling tools like create, update, search, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance on when to use page_id vs title/space_key, but does not explicitly differentiate from other retrieval tools like confluence_search or get_page_children.
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 details that only content beneath a named heading is replaced, leaving macros and layouts intact. It also mentions error conditions (missing heading) and optional use of storage format for macros, providing full behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose paragraph followed by an args list. It is concise but the args list is somewhat lengthy; however, it is still efficient and readable.
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 full schema coverage, output schema existence, and detailed description of behavior, errors, and parameter nuances, the description is complete for the agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description's 'Args' section adds valuable context beyond the schema, such as that new_content should not include the heading, heading matching is case-sensitive, and content_format examples. This richly explains parameter 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 'Update a single section of a Confluence page without affecting the rest.' It specifies the verb (update) and resource (section), and distinguishes from sibling tools like confluence_update_page by emphasizing that it only updates a section, avoiding the data loss of full-page updates.
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 contrasts with full-page updates, stating that it 'avoids data loss when a full page is downloaded and re-uploaded.' This tells the agent when to use this tool (precise section edits) and when not to (if other parts need changing).
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 the tool returns the full result set for disambiguation, requires project/issue context, works without the global 'Browse Users' permission, and describes the output format (JSON with success, count, users). 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 clear sections: summary, usage guidance, parameter details, and return format. It is front-loaded with the main purpose, and every sentence adds necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, 1 required, output schema exists), the description is complete. It explains the permission context, the rationale for input constraints, and the return format, making it fully adequate for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage with descriptions. The description adds value by clarifying that the query is free-form and case-insensitive, explaining the mutual exclusivity of project_key and issue_key, and noting the maximum limit of 1000. This additional context helps the agent use parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search Jira users assignable in a given project or issue', providing a specific verb and resource. It distinguishes itself from the sibling tool `jira_get_user_profile` by noting that this tool is for human-name search and returns a full result set for disambiguation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: when a display name, partial name, or email fragment is available and a concrete identifier is needed. It also explains that exactly one of project_key or issue_key must be provided, the reason (API requirement and permission context), and directs away from `get_user_profile` for this use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true; description adds critical behavioral details: known DATETIME limitation (time lost), automatic date conversion from ISO 8601 and Unix timestamps, and lists common answer types with value formats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with headings, warnings, workaround, and examples. Every sentence adds value; front-loads core purpose and gradually provides 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?
Given tool complexity (multiple answer types, date handling, API limitation), description covers purpose, usage, behavioral quirks, parameter details, and return format. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions; description enriches understanding with answer object structure, examples for each type, and automatic conversion behavior. No ambiguity remains.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Update form field answers using the Jira Forms REST API', specifying verb and resource. Distinguishes from sibling jira_update_issue by highlighting it's the primary method for form data and providing a workaround for DATETIME fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states it's the primary method for updating form data, and provides detailed workaround for DATETIME fields using an alternative tool (jira_update_issue). Includes multiple example usage patterns and common answer types.
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-browser-mcp MCP server](https://glama.ai/mcp/servers/GeiserX/atlassian-browser-mcp/badges/card.svg)](https://glama.ai/mcp/servers/GeiserX/atlassian-browser-mcp)

Score Badge

Copy to your README.md:

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

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/GeiserX/atlassian-browser-mcp'

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