Jira Cloud MCP Server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation3/5
Most tools map to a distinct resource and action, but a few pairs blur together: get_issue_worklog/get_worklog, bulk_fetch_issues/search_and_reconsile_issues_using_jql_post, and get_all_projects/search_projects. The one-line descriptions are too terse to fully clarify these boundaries.
Naming Consistency3/5
There is a strong base of verb_noun names like get_issue, create_issue, update_comment, and delete_worklog, but conventions drift with submit_bulk_*, create_issues vs bulk_fetch_issues, do_transition, and the outlier search_and_reconsile_issues_using_jql_post. Overall the names remain readable but are not consistently patterned.
Tool Count1/5
With 62 tools, this far exceeds the 25+ 'too many' threshold and reaches the 50+ extreme-mismatch range. Even for a broad platform like Jira, the number of bulk, metadata, and subresource variants makes the surface overwhelming for an agent.
Completeness4/5
The server covers the core issue lifecycle thoroughly: create/edit/get/delete, transitions, comments, worklogs, watchers, votes, attachments, issue links, properties, remote links, search, projects, and users. Minor gaps like attachment download/delete and update/delete for components/versions are workable and do not create dead ends in the main workflow.
Average 2.3/5 across 62 of 62 tools scored. Lowest: 1.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under 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.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it reveals nothing beyond the fact that an edit occurs. It fails to mention notification behavior, screen security overrides, whether the issue is returned, or any side effects, making it nearly useless for predicting tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. 'Edit issue' earns no space because it merely repeats the tool name without conveying any useful, non-redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with seven parameters, a nested request body, and many related sibling tools, yet the description provides no context about how to structure an edit, what the response contains, or how this differs from other issue-modification tools. The absence of an output schema and annotations makes this even more inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 of 3 applies. The description itself adds no parameter semantics, but the input schema already documents all seven parameters, including the nested body object, issueIdOrKey, expand, notifyUsers, returnIssue, and override flags.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Edit issue' is a tautology that restates the tool name without adding any information about what editing an issue entails. It does not distinguish this tool from siblings like do_transition, assign_issue, or submit_bulk_edit, which also modify issues in some way.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives. The description does not mention that it edits fields, applies transitions, or when to prefer do_transition or submit_bulk_edit instead, leaving the agent without routing information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations and the description reveals nothing beyond the verb 'Get'. It does not disclose response format, error behavior, permission requirements, or whether this is a safe read operation. The tool description carries full behavioral burden and fails entirely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two words and contains no usable information. This is under-specification rather than efficient conciseness, as it does not earn its place by adding value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With three parameters, no output schema, no annotations, and a large sibling list, this description is completely inadequate. An agent would have no idea what the tool returns, when to invoke it, or how it differs from get_issue_worklog.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all three parameters. The tool description adds no additional meaning beyond what the schema states, matching the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get worklog' merely restates the tool name without specifying what this operation does. It does not clarify that this retrieves a single worklog by ID, nor does it distinguish itself from siblings like get_issue_worklog.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as get_issue_worklog, add_worklog, or update_worklog. With many worklog-related siblings, the absence of any selection criteria leaves the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no behavioral detail, the description fails to disclose whether this operation is read-only, whether it requires authentication, what data it returns, or whether it depends on a selected issue/project. The full burden falls on the description, and it provides nothing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It provides no distinguishing or actionable content, so the brevity does not serve the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations and no output schema, and the description gives no indication of what 'priorities' refers to or what the response will contain. Given the large sibling set, this is not enough contextual information for an agent to know when or how to 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 has zero parameters, so there is no parameter documentation burden for the description. The schema is trivially complete, and the description cannot be faulted for omitting parameter details that do not exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get priorities' is a tautology that simply restates the tool name. It does not identify the resource type, scope, or what distinguishes it from sibling tools like get_statuses or get_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?
There is no guidance about when to use this tool versus alternatives, no context about the current entity or project, and no exclusions or prerequisites. An agent is left with no direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'Add attachment.' It does not mention that this is a write operation, what side effects occur, whether authentication or permissions are needed, or any constraints around attachment content or size.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it earns no place because it merely repeats the tool name. This is under-specification rather than concise helpful writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with no output schema, the description and even the schema leave critical gaps: the body is only described as 'Request body (JSON object)' with generic object items, and there is no indication of required attachment payload structure or how the endpoint behaves. An agent cannot confidently invoke this tool correctly from this definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 issueIdOrKey and body. The description adds no parameter meaning beyond what the schema provides, which keeps this at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add attachment' restates the tool name almost verbatim and adds no scope. It names a verb and resource, so it minimally separates add_attachment from get_attachment, but it does not clarify what kind of attachment, where it is added, or how it is supplied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as add_comment, add_worklog, or get_attachment. There are no exclusions, prerequisites, or context signals to help an agent choose it correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden of behavioral disclosureand two words carry none of it. It never mentions that this is a mutating operation on an issue, whether it is reversible, whether permissions are required, or what the response looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two words is underspecification, not conciseness. There is no front-loaded key constraint and no explanatory structure; every useful fact an agent needs is absent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with a nested request object, required issueIdOrKey, no output schema, and many comment-related siblings, this description is severely incomplete. It omits the target resource, behavior, and response information entirely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 even though the description adds nothing about parameters. However, the body parameter's schema is misleading for a request object—it lists response-style fields like id, author, created, and self—and its description 'Request body (JSON object)' is unhelpful; the tool description does nothing to clarify the expected payload.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add comment' restates the tool name with no additional information. It supplies a verb and resource but never names the target (an issue), and nothing distinguishes it from siblings like update_comment, delete_comment, or get_comments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided at all. The description gives no context for when to choose add_comment over update_comment, delete_comment, or get_comments, and states no conditions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the behavioral disclosure burden. 'Add vote' reveals only the basic action and adds no information about permissions, reversibility, idempotency, side effects, or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is terse, but it is under-specified rather than helpfully concise. It restates the tool name and offers no structured information that would help an agent invoke or select the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, this description is not complete enough. It omits the target resource, the expected effect beyond 'vote', and any relationship to related vote/watcher tools, so an agent cannot confidently understand the tool's full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the parameter issueIdOrKey is already described as 'The ID or key of the issue.' The description adds no additional parameter semantics, which is acceptable given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add vote' is essentially the tool name repeated, so it provides no independent clarification of what the tool does. It does not explicitly state that a vote is added to an issue, even though the only parameter is issueIdOrKey.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use add_vote versus the related siblings remove_vote or get_votes. The description does not mention whether the vote is for the current user, whether prior votes matter, or any condition that would favor this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It states no side effects, permissions, notification behavior, estimate-adjustment implications, or response semantics. The only behavioral signal is the verb 'Add', which is already obvious from the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. Every other dimension suffers from the absence of detail, and the two-word description does not earn its place by conveying any useful information beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters, a nested body object, no annotations, no output schema, and many closely related siblings, this description is completely inadequate. An agent cannot determine the required body format, the meaning of worklog fields, or how the operation affects the issue's time estimate from this definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 even though the description adds no parameter information. The schema provides descriptions for most top-level parameters, though some are truncated and the nested 'body' object's fields lack individual descriptions. The tool description itself adds no semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add worklog' simply restates the tool name 'add_worklog' without explaining what a worklog is, what it records, or how it relates to an issue. It is a tautology rather than a meaningful definition, and it provides no distinction from sibling worklog tools like update_worklog or get_issue_worklog.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as add_comment, update_worklog, or get_issue_worklog. There is no mention of prerequisites, required issue context, or typical use cases, leaving the agent to infer entirely from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only repeats the tool name and fails to explain what the operation does, whether it replaces the current assignee, what permissions are required, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but this is under-specification rather than efficient conciseness. Two words cannot provide the information an agent needs to invoke the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and a nested body object, the definition needs meaningful behavioral and contextual detail. The description is completely inadequate: it omits what assigning means, what the response looks like, and how the body object should be populated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters described in the schema: issueIdOrKey identifies the issue and body holds the user object. The tool description itself adds nothing about the parameters, but the schema already documents them sufficiently, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Assign issue' is a tautology that simply restates the tool name. It gives no detail about what assignment means (e.g., setting an assignee on an issue) and does nothing to distinguish this tool from its many issue-related siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as edit_issue or do_transition. There is no mention of prerequisites, typical use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided and the description discloses no behavioral traits. It does not mention side effects, required fields, permissions, or result handling. The description carries almost no information beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but under-specified rather than appropriately concise. A two-word description is not sufficient for a nested-parameter creation operation and leaves nearly all meaning to the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with nested objects, no output schema, no annotations, and a large sibling set, the description is severely incomplete. An agent cannot determine how to construct a valid issue body, what the API expects, or what success looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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. However, the schema descriptions are weak: body is only described as 'Request body (JSON object)' and updateHistory's description is truncated. The tool description itself adds no parameter-level meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create issue' simply restates the tool name and provides a generic verb+resource pair. It does not explain what kind of issue, what system is involved, or how this differs from create_issues or edit_issue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as create_issues, submit_bulk_create, or edit_issue. No conditions, exclusions, or prefered scenarios are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action 'create' with no information about side effects, required context, permissions, validation, or consequences. This is no more informative than the tool name itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two words is under-specification rather than effective conciseness. The description is minimal but fails to communicate anything beyond the name, so it does not earn its place as a useful explanatory sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a nested body schema with many properties, no annotations, and no output schema, a two-word description is entirely inadequate. An agent cannot determine what a 'version' is, what response to expect, or how to construct a correct request.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 even though the description adds no parameter-level meaning. The schema documents 'body' as a request object with many properties, but the description gives no hints about which fields matter or how to construct a valid version.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create version' is essentially a verbatim restatement of the tool name 'create_version'. It names the action and resource but adds no detail, and it does not distinguish this operation from sibling create tools like create_component or create_issue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives. No context is provided about prerequisites, when creating a version is appropriate, or how it differs from related project/version operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing destructive behavior and side effects. It merely says 'Delete issue' and does not state that deletion is permanent, may cascade to subtasks, or may require specific permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At two words, the description is minimal, but this is under-specification rather than effective conciseness. It lacks front-loaded behavioral or usage context, so it fails to earn a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a destructive mutation tool with no annotations, no output schema, and a very sparse description. Critical context such as irreversibility, subtask behavior, permission requirements, and how the deleteSubtasks parameter affects the operation is completely absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema documents both parameters including the enum and default for deleteSubtasks. The description adds no parameter-level meaning, but the baseline of 3 applies because the schema already does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete issue' simply restates the tool name, which is a tautology. It identifies the general action and resource but provides no differentiation from sibling tools like submit_bulk_delete, delete_issue_link, or delete_issue_property.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as submit_bulk_delete for bulk operations or delete_issue_link for removing links. The description does not mislead, but it offers no contextual usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior, but 'Find users' discloses nothing: no mention of search semantics, pagination, result format, or idempotency. It neither confirms nor denies any behavioral traits, but it fails to provide the transparency the agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded, but it is under-specified rather than efficiently concise. It consists of a tautological two-word phrase and provides no structured or scoped information that would help an agent invoke the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given six parameters, zero required fields, no annotations, and no output schema, the description is far too incomplete. The agent is left unable to determine key invocation details such as which parameters are mutually exclusive, how paging works, or what the return value will be.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 alreadily documents the parameters, including the conditional requirement on accountId. The description adds no additional meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Find users' simply restates the tool name and provides no additional specification about which users are found, how matching works, or what scope the search covers. It does not differentiate this tool from related siblings like get_user or find_bulk_assignable_users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as get_user or find_bulk_assignable_users. The description offers no context, prerequisites, or exclusions, leaving the agent to infer usage from the parameter schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the full burden for behavioral disclosure. It merely restates the action 'get' with no mention of what happens, what is returned, pagination behavior, ordering, or any side effects. This is a complete absence of behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. Two words provide no meaningful structure or front-loaded context for the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is inadequate for a 3-parameter tool with no output schema and no annotations. It leaves the agent unsure whether changelogs are for the issue specified by issueIdOrKey, how pagination works, or how this tool differs from get_change_logs_by_ids.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 fully documents issueIdOrKey, startAt, and maxResults. The description adds no parameter-level detail, which meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get changelogs' is a direct paraphrase of the tool name and adds no new information. It fails to specify that these are issue changelogs or to distinguish this tool from the sibling get_change_logs_by_ids.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as get_change_logs_by_ids. The description offers no context about scope, prerequisites, or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but 'Get comments' reveals nothing beyond the action itself. It does not mention read-only behavior, ordering, pagination defaults, or any other observable behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely terse, but this is under-specification rather than effective conciseness. There is no front-loaded context, alternatives, or behavioral detail; every meaningful piece of information is missing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has five parameters, no annotations, no output schema, and there are closely related siblings. A two-word description leaves out essential context such as what resource is being queried, how pagination works, and when to choose this over get_comment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all five parameters. The description adds no parameter-level meaning, but the baseline of 3 applies because the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is 'Get comments', which essentially restates the tool name and adds no new information. It does not specify that comments belong to an issue, nor does it differentiate this plural tool from the sibling 'get_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. It does not mention issue context, pagination use cases, or how this differs from 'get_comment' or 'add_comment'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no description of behavior, the tool's effects and constraints are entirely undisclosed. The description does not state what is returned, whether it mutates state, or whether any special permissions are needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While extremely short, this is under-specification rather than effective conciseness. The description fails to convey essential information and is not front-loaded with useful content because there is no useful content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, 7 parameters, and a two-word description, the tool definition is completely inadequate for an agent to invoke it correctly. Critical context such as required parameters, return shape, and relationship to siblings is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 7 parameters. The description itself adds no parameter-level meaning, but the high schema coverage justifies the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get issue' is a tautology that restates the tool name without adding any specificity. It does not distinguish this tool from sibling retrieval tools like get_issue_watchers, get_comment, or get_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?
There is no guidance about when to use this tool versus alternatives. The description provides no context, prerequisites, or exclusions, leaving the agent to guess which tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no descriptive detail, the description leaves all behavioral traits undisclosed. It does not mention whether operations are read-only, what conditions may hide transitions, or what response behavior to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief but this is under-specification rather than effective conciseness. It does not add information beyond the name, so it fails to earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With six parameters, no output schema, and no annotations, the two-word description is far from sufficient. An agent has no context about return values, transition availability, or how to distinguish this from transition-related siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameters are already described in the input schema. The description adds no extra meaning beyond what the schema provides, so it meets the baseline but does not go further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get transitions' simply restates the tool name and does not specify what kind of transitions (e.g., issue workflow transitions) or how this differs from siblings like do_transition. It is a tautology rather than an informative definition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to call this tool versus alternatives such as do_transition or get_statuses. The description provides zero context about prerequisites or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It provides none beyond the verb 'Get', which merely repeats the tool name; it does not mention outdated parameters, authentication needs, response shape, or side-effect safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is technically short, but this is under-specification rather than efficient conciseness. The two words 'Get user' do not earn their place because they add no information beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With four parameters, two of them deprecated, no required parameters, and no output schema, this description is far from complete. An agent cannot tell how to identify the user, what optional behaviors expand accepts, or what the response will look like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters, including deprecation notes and the meaning of accountId. The description itself adds no parameter-level meaning, but the baseline of 3 applies because the structured schema is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get user' is a near-verbatim restatement of the tool name and provides no additional specificity. It does not indicate what kind of user data is returned, how the user is identified, or how this differs from sibling tools like find_users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose get_user over find_users, find_bulk_assignable_users, or get_issue_watchers. The description contains no context, prerequisites, or exclusions, so an agent receives no help in routing between alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden of behavioral disclosure. It only names a mutation without revealing that it is a bulk write, whether it is asynchronous, whether partial failures can happen, what permissions are required, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but it is under-specified rather than usefully concise. A three-word phrase for a tool with a nested request body and bulk semantics does not provide enough structure or front-loaded guidance for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex bulk operation with nested parameters, no output schema, and no annotations, yet the description provides almost no context. It omits mapping semantics, notification behavior, error handling, and permission requirements, making it inadequate for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is reported as 100%, so the baseline applies even though the tool description adds nothing about parameters. The schema exposes body fields like sendBulkNotification and targetToSourcesMapping, but the description does not explain their meaning or resolve the schema inconsistency where required targetToMultipleSourceMapping is not defined in properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Bulk move issues' essentially restates the tool name 'submit_bulk_move' without adding operational detail. It does not specify the effect of the move, what distinguishes it from siblings like edit_issue or transition_issue, or what 'submit' implies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus the many related issue-manipulation tools. The description does not mention prerequisites, alternatives, or the scenario in which a bulk move is the correct operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses nothing: no permission requirements, no side effects like notifications, no mention that existing content is replaced, and no indication of what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but it is under-specified rather than efficiently concise. For a tool with six parameters and a nested request body, a two-word restatement of the tool name does not earn its place as a meaningful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has six parameters, a nested body object, no output schema, and no annotations. A single phrase 'Update comment' provides essentially no operational context. An agent would have to infer even the basic workflow of locating an issue and replacing its comment body.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no parameter semantics, but it does not need to compensate for schema gaps. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is 'Update comment', which simply restates the tool name. It does identify the verb and resource, but it provides no additional context such as the issue association, the required body field, or how this differs from add_comment/get_comment beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. Sibling tools like add_comment, get_comment, get_comments, and delete_comment exist, but the description gives no conditions, prerequisites, or exclusions to help an agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden of behavioral disclosure. It only says 'Get' and provides no information about return format, whether globalId filters the result, whether this is a collection operation, or what error/edge-case behavior exists. There is no behavioral information beyond the operation's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-pecification rather than genuine conciseness. It carries no information beyond the tool's name, so the single sentence does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter tool with no output schema and no annotations, the description should at least clarify what is returned and how it differs from get_remote_issue_link_by_id. It does neither. The schema makes a bare call possible, but the description is not complete enough for confident tool selection and result interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters clearly described. The description itself adds no parameter semantics, but the baseline of 3 applies because the input schema already explains issueIdOrKey and globalId adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description, 'Get remote issue links', is essentially the tool's name de-underscored. It restates what the name already says without adding scope, object qualifiers, or a distinction from the sibling get_rem ote_issue_link_by_id. It is a tautology rather than an informative purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not-to-use guidance is provided. The sibling list includes get_rem ote_issue_link_by_id, which likely serves the single-link case, but the description does not clarify which tool to choose or how they differ. An agent must guess 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'Get votes' only implies a read operation and does not state what is returned, whether permissions are required, or whether the result is a count or list of voters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is short but under-specified. The terse phrase 'Get votes' does not earn conciseness credit because it omits essential context rather than efficiently conveying it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The single parameter is documented, but there is no output schema and no description of the return value, so an agent cannot predict what the tool will produce. The sibling list shows related vote operations, yet the description does not clarify this tool's role among them.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 issueIdOrKey described as 'The ID or key of the issue.' The description adds no parameter-level meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is exactly the tool name, 'Get votes', with no elaboration on what resource is being retrieved or for which entity. It identifies a verb and a resource but is tautological and indistinguishable from a generic votes endpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus related siblings such as add_vote or remove_vote. There is no mention of preconditions, alternatives, or the issue-level context implied by the issueIdOrKey parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only restates the action and reveals nothing about irreversibility, permissions, idempotency, whether a prior vote is required, or what happens after deletion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two words, making it concise but under-specified rather than properly structured. It omits the issue target, vote owner, and any usage context that would make the short length effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive one-parameter tool with no annotations and no output schema, this description is insufficient. An agent would not know whose vote is deleted, whether the voter must be the current user, or what the expected outcome is.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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%: issueIdOrKey is clearly documented as the ID or key of the issue. The description adds no parameter meaning, but the schema already provides adequate semantic coverage, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
"Delete vote" simply restates the tool name remove_vote with synonyms. It does not specify whose vote is deleted, that it targets an issue, or how it differs from siblings like add_vote and get_votes beyond the verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, no prerequisites, and no conditions. The sibling list includes add_vote and get_votes, but the description does not help an agent decide which operation is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It merely says 'Set issue property' and does not state whether the property is created or overwritten, whether permissions are required, whether the operation is idempotent, or what side effects occur. This is effectively no behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only three words and entirely restates the tool name. This is under-specification rather than genuine concciseness; every word is wasted because it adds no information beyond the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is far too minimal. While the schema fully documents parameters, the agent is left without any understanding of when this tool is appropriate or what behavior to expect, making the definition incomplete for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema documents all three parameters including constraints such as the property value being valid JSON up to 32768 bytes and the key max length of 255 characters. The description adds nothing beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set issue property' is a direct restatement of the tool name with no additional detail. It identifies the verb and resource but fails to distinguish this tool from siblings like get_issue_property, delete_issue_property, or edit_issue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus the many related sibling tools. Siblings like get_issue_property, delete_issue_property, and edit_issue are present but the description gives no context for choosing among them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden, and 'Create component' only signals a mutating operation — information already carried by the name itself. It says nothing about permissions, side effects, idempotency, or what happens on duplicate names. Slightly more informative than a bare noun but far short of what an unannotated mutation tool requires.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two words with no redundancy, but this is under-pecification rather than conciseness. A tool with a 16-field nested request body and no output schema cannot be usefully described in a single phrase. There are no sentences earning their place because there is effectively no content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Completely inadequate for the tool's complexity: no output schema, no annotations, a nested object parameter, and 60+ siblings to disambiguate from. An agent has no way to know what a component is, which fields matter, what the response contains, or how this differs from create_version or create_issue. Nothing necesary for correct invocation is conveyed.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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% at the top level, meeting the >80% threshold, so the baseline of 3 applies even though the description adds nothing about parameters. The body description 'Request body (JSON object)' is generic, and none of the 16 nested fields are documented in the description, but the rule grants baseline credit for the covered schema. The description itself contributes zero semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create component' is a near-verbatim restatement of the tool name 'create_component', making it a tautology. It fails to specify what kind of component (Jira project component, implied by the sibling set) or how it differs from the many other creation tools. No resource scope, context, or differentiating detail is provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is zero guidance on when to invoke this tool versus alternatives like create_version, create_issue, or get_project_component. No context, conditions, exclusions, or alternative routing is offered anywhere in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that the tool deletes a worklog, without mentioning whether the deletion is permanent, how it affects issue time estimates, notifications, or any other side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but under-specified rather than genuinely concise. It has no structured content, no sentence that earns its place beyond restating the tool name, and omits important context that could be conveyed in minimal additional text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with seven parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain required inputs, behavior, return value, or side effects, leaving an agent without enough information to invoke the tool correctly and confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents all seven parameters. The description adds no parameter-level meaning, but since the schema carries the burden, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete worklog' is a direct restatement of the tool name delete_worklog. It names the action and resource but adds no additional specificity about scope, target, or effect, so it qualifies as a tautology rather than a substantive purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives. Sibling tools such as update_worklog, add_worklog, and get_worklog exist, but the description does not clarify when deletion is appropriate or how it differs from these related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The verb 'Get' implies a read-only operation, but the description does not state authentication requirements, response characteristics, filtering behavior, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only one short sentence and is technically concise, but it is under-specified to the point of tautology. It provides no structured, usable content beyond repeating the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 optional parameters, no output schema, no annotations, and a large sibling tool set, the description is far too sparse. It does not explain what 'create issue metadata' includes, how the parameters constrain the result, or how this tool relates to create_issue and get_edit_issue_meta.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 5 parameters, so the baseline of 3 applies. The description itself adds no parameter-level meaning, but the schema already documents each parameter sufficiently.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a near-verbatim restatement of the tool name ('Get create issue metadata'), adding no new information about what the metadata actually contains or its scope. It does not meaningfully differentiate from siblings like get_edit_issue_meta beyond the word 'create'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_edit_issue_meta, get_fields, or create_issue. The description does not mention that this is useful before creating an issue or how it differs from related metadata endpoints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided and the description only says 'Get fields.' It does not disclose whether the operation is read-only, what it returns, whether authentication is required, or any side effects. The description carries the full burden of behavioral disclosure and provides none.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single two-word phrase is extremely brief, but this is under-specification rather than effective conciseness. It lacks the content needed to be useful, so it does not earn high marks for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and an empty parameter schema, the description is the only source of information. 'Get fields' does not specify the domain (which fields), expected output, or relationship to sibling tools. The tool may be simple, but the description is inadequate for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties, so there are no parameters to describe. The baseline for 0-parameter tools is 4, and the description's lack of parameter information is acceptable since no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get fields' is essentially a tautology of the tool name. It does not specify which fields (issue fields, custom fields, project fields) or provide any resource context, and it does not distinguish the tool from siblings like get_statuses or get_priorities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are no conditions, prerequisites, or exclusions mentioned, leaving an agent unable to decide when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only states the core action and says nothing about permission requirements, duplicate watcher handling, whether existing watchers are overwritten, or what happens on failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It provides no contextual structure or front-loaded details that help the agent understand the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no annotations and no output schema, the description should clarify scope, effects, and usage context. 'Add watcher' is not sufficient for an agent to confidently invoke the tool, especially given the large set of sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'body' and 'issueIdOrKey' already documented. The description itself adds no parameter meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add watcher' is a near-verbatim restatement of the tool name 'add_watcher', making it essentially tautological. It identifies the general action and resource but does not specify the target (e.g., an issue) or differentiate itself meaningfully from related tools beyond the obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not state when to use this tool instead of remove_watcher, get_issue_watchers, or add_vote, nor does it mention any prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only says 'Delete'. It does not reveal that deletion is permanent, whether special permissions are required, any cascading effects, or what happens to associated data. The minimal phrase offers no transparency beyond the obvious destructive intent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two words, but this is under-specification rather than true conciseness. It omits necessary context that could help an agent use or select the tool correctly. Every sentence should earn its place, and here the lone phrase contributes little beyond what the name already says.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations and no output schema, the description is far too sparse. It fails to mention irreversibility, required issue/comment context, or any behavioral notes. An agent on the edge between delete_comment and update_comment or get_comment gets no guidance on the consequences of the call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both required parameters (id and issueIdOrKey) have clear descriptions in the input schema. The tool description itself adds no parameter context, but per the baseline for full schema coverage, this is acceptable. No enum or nested object complexities exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete comment' is essentially a restatement of the tool name 'delete_comment'. It states a verb and resource but adds no specificity or differentiation beyond what the name already conveys. There is no mention of which comment, what context, or how it differs from sibling comment tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as update_comment, get_comment, or add_comment. There is no mention of prerequisites, use cases, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'Get comment'. It does not confirm read-only behavior, mention permissions, or explain the effect of the expand parameter. Minimal insight beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two words, which is under-specification rather than effective conciseness. It is front-loaded, but it omits essential context and does not earn its place as a useful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description is too thin. It does not explain how to retrieve a comment, what the response looks like, or how this differs from get_comments or get_issue. An agent would struggle to choose this tool correctly from the large sibling list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter detail, but the schema already documents all three parameters clearly. The description neither helps nor hurts.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a tautology: 'Get comment' merely restates the tool name without specifying what a comment is, what resource it operates on, or how it differs from get_comments. It provides a verb and resource but no distinguishing detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like get_comments, update_comment, or delete_comment. No context is given about required issue context or relationship to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavior. It only states 'Get', implying a read operation, but does not describe return format, error behavior, permissions, or any side effects. The description adds no behavioral context beyond what the name already implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but this is under-specification rather than proper conciseness. It is a three-word phrase that repeats the tool name and lacks any additional useful content. It does not provide a meaningful explanation of the tool's role.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter and no output schema, the description should at least clarify what an issue link is and that the return value is the link object. It also does not differentiate from remote issue link tools. The absence of annotations and output schema means the description needs to carry more context, but it carries almost none.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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% because linkId has a clear description. The description itself adds no parameter semantics beyond 'linkId', so the baseline of 3 applies. With only one parameter and a complete schema entry, no further compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get issue link' is a direct restatement of the tool name with spaces instead of underscores, providing no additional information beyond the name itself. It does not specify that this retrieves a link by its ID nor distinguish it from related siblings like get_remote_issue_link_by_id or get_issue_link_types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool or which alternative to choose. It does not mention scenarios, exclusions, tradeoffs, or sibling comparisons such as retrievin internal issue links vs remote issue links. An agent gets no direction beyond the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get' implies a read operation, but the description does not disclose response format, permissions, error behavior, or side effects. It is accurate but minimally informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and free of filler, but it is under-specified rather than appropriately concise. Three words do not provide enough context to justify the description's existence beyond the tool name. This is under-specification, not effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, no annotations, and a description that only restates the name. While parameter semantics are covered by the schema, the description does not explain what an issue property is, what the caller receives, or how this differs from related issue endpoints. The context is insufficient for confident tool selection and expectation setting.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters have clear descriptions in the input schema. The tool description itself adds no parameter-level detail, but the schema already provides sufficient meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get issue property' is essentially a rewording of the tool name and adds no detail about what an issue property is or what the operation entails. It fails to distinguish the tool from related property operations like set_issue_property or delete_issue_property. This is closer to a tautology than a functional explanation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_issue, set_issue_property, or delete_issue_property. There are no exclusions, prerequisites, or context hints. The agent is left to infer usage entirely from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'Get project,' which implies a read operation but discloses nothing about return format, error behavior, or the role of the expand/properties parameters. For an unannotated tool, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is under-specified rather than genuinely concise. At two words, it restates the tool name and provides no structure or prioritized information, so it does not earn its place as a helpful definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should indicate what a caller receives and how optional parameters affect the response. 'Get project' leaves all of that implicit, so an agent is under-informed despite the schema's parameter coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 all three parameters are already documented in the input schema. The description adds no parameter-level meaning, but the high schema coverage satisfies the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get project' simply restates the tool name, replacing the underscore with a space. It adds no new information about what kind of project, whether it is by ID or key, or how it differs from sibling tools like get_all_projects or search_projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as get_all_projects, search_projects, or get_project_components. An agent must rely solely on the tool name and schema to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description bears the full burden of disclosing side effects. 'Transition issue' implies a state-changing workflow operation but says nothing about permissions, reversibility, validation errors, or the fact that the body must specify a valid transition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two words is concise but crosses into under-specification. There is no fluff, but the description is too short to serve as a useful guide for a tool with a nested request body and several sibling variants.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and a nested body schema, the description is far too incomplete. An agent cannot tell what transition values are acceptable or what the result of a successful transition will look like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameter schema coverage is 100%, so the schema already documents issueIdOrKey and gives the body shape. The description adds no semantic detail about what should go in 'transition' or 'fields', but it does not need to compensate much because the schema is present.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The phrase 'Transition issue' states a clear verb and resource: the tool changes an issue's workflow status. However, it is too vague to distinguish do_transition from nearby siblings such as submit_bulk_transition or get_transitions, and it does not explain what a transition involves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. An agent must infer from the name that it applies to a single-issue workflow transition, and it is not told to call get_transitions first or to use submit_bulk_transition for multiple issues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, yet 'Get edit issue metadata' adds nothing beyond the name. The 'Get' verb weakly implies a read-only operation, but the description says nothing about what the response contains, authentication requirements, or how overrideEditableFlag and overrideScreenSecurity alter returned data. No contradiction with annotations exists because there are none.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four words with zero waste, but this is under-specification rather than genuine conciseness. The description is essentially a restatement of the tool name and omits definitional content that should come before any behavioral detail. Nothing is front-loaded because there is nothing to front-load.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a param surface that includes two permission-gated boolean toggles, the description is the sole source of operational context — and it explains none of it. An agent cannot determine what the tool returns, when to call it, or what the override flags do, making reliable selection and invocation impossible from the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline of 3 applies. The description itself contributes no parameter information, but the schema descriptions are serviceable: issueIdOrKey is self-explanatory, and the two booleans convey their purpose (returning non-editable/hidden fields) with permission caveats, though the permission strings appear truncated mid-sentence.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and resource ('edit issue metadata'), which on its face distinguishes it from edit_issue (the mutation itself) and get_create_issue_meta (the creation counterpart). However, it never defines what 'edit issue metadata' actually is — editable fields, field types, allowed values, screens — so an agent must infer the return semantic from the name alone. With roughly 70 siblings, the description does no explicit differentiation work.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to invoke this tool versus the closely related get_create_issue_meta, edit_issue, or get_issue. The natural pre-edit workflow is only implied by the name ('get edit issue meta'), never stated. Neither exclusions nor alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state return format, pagination, permissions, or side effects; the fact that it is a 'get' operation is implied by the verb but not explicit.
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 text is very concise, one sentence with no waste. However, it is under-specified: it lacks any structuring elements like scope or caveats, so the brevity is more a sign of missing content than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and a minimal description, an agent lacks essential context about what a 'project version' is, what the response looks like, or when to call this tool. The parameter schema is complete, but the tool-level description is insufficient for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with descriptions for both expand and projectIdOrKey. The description adds no parameter detail, but with the schema already documenting the parameters, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get project versions' essentially restates the tool name without clarifying what 'versions' means in a Jira context (e.g., releases, milestones). It does not distinguish itself from sibling tools like get_project or create_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?
There is no guidance on when to use this tool versus alternatives. No mention of situations where project versions are needed, or any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Fetch' weakly implies a read-only operation, but the description does not mention response format, error behavior, handling of missing issues, rate limits, or any other important runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but this is under-specification rather than effective conciseness. It provides no additional structure or useful detail beyond what the tool name already communicates.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a nested body schema, optional controls, no output schema, and no annotations, so the description should provide more operational context. It neither explains return values nor clarifies the purpose of the optional parameters, leaving an agent to infer too much from the schema alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is reported as 100%, so the baseline is 3. The description itself adds no parameter detail, though the body description does say the object contains information about which issues and fields to fetch. Optional parameters like expand, fields, properties, and fieldsByKeys remain semantically unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('fetch issues'), and 'bulk' weakly distinguishes it from single-issue tools like get_issue. However, it is almost a restatement of the tool name and does not clarify what 'bulk' means, what issue identifiers are accepted, or what distinguishes this from search-based issue retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_issue or JQL search tools. The schema implies issueIdsOrKeys, but the description provides no conditions, exclusions, or reasons to prefer this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'Delete issue link'. It does not disclose whether deletion is permanent, requires special permissions, or affects related data. The description carries no behavioral information beyond the operation itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it merely repeats the tool name and does not add value. Under-specification is not true conciseness; a useful description would include at least one distinguishing detail or usage hint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a deletion tool with no annotations and no output schema, the description should clarify scope, side effects, or distinctions from related deletion tools. None of this is present, leaving an agent to guess whether this applies to standard issue links or remote issue links.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for the single parameter linkId, so the schema already explains the parameter. The description adds no additional meaning about linkId format, provenance, or how to obtain it, but the baseline of 3 applies due to full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Delete' and the resource 'issue link', which is clear and unambiguous. However, it does not distinguish itself from the sibling tool delete_remote_issue_link_by_id, which is a related but distinct deletion operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like delete_remote_issue_link_by_id or get_issue_link. The description simply restates the tool name with no context for when it is the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It says 'Get', implying a read-only operation, but reveals nothing about required permissions, behavior with invalid changelog IDs, ordering of results, or error handling. The description is too minimal to give an agent confidence in side effects or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely terse and front-loaded with the verb, containing no filler words. However, it is a grammatical fragment rather than a clear sentence, and the brevity comes at the cost of important context. It is concise, but not ideally structured for comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a nested parameter object, the description is under-specified. It does not mention that the tool requires an issue identifier plus a list of changelog IDs, nor does it describe what is returned or how invalid IDs are handled. An agent would need to inspect the schema and infer behavior from the sibling tool names, which is insufficient for a reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is marked as 100%, so the schema already explains issueIdOrKey and the body structure. The description's 'by IDs' roughly maps to the changelogIds array but adds little beyond what the parameter names and schema already convey. It does not clarify that the IDs are changelog IDs or how they relate to the issueIdOrKey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a verb and resource ('Get changelogs') but the modifier 'by IDs' is ambiguous — it does not specify that these are changelog IDs for a specific issue. It does not clearly distinguish this tool from the sibling 'get_change_logs' (which likely returns all changelogs for an issue). The tool name hints at the meaning, but the description itself lacks precision.
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. The sibling tool list includes 'get_change_logs', which probably returns all changelogs for an issue, but no distinction or selection criteria is given. An agent would have to infer usage from the schema and tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden, but it only says 'Get' and does not describe auth requirements, return shape, potential errors, or any side-effect guarantees beyond the implication of a read operation. This is too thin for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but that reflects under-specification rather than effective conciseness. It contains one sentence that merely restates the tool name and provides no useful structure or additional substance.
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 operation is simple and all parameters are documented in the schema, so the tool is minimally callable. However, with no output schema and no usage or behavioral context, the description is only barely complete for a straightforward metadata lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema itself provides useful parameter detail, especially the level filter with allowed values -1/0/1. The description adds no parameter-level meaning, so it earns the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get issue types for project' is essentially a word-for-word paraphrase of the tool name and adds no new information. It states a general action but does not distinguish issue types from related metadata endpoints like get_fields, get_statuses, or get_create_issue_meta.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied by the action and object: call it when you need issue types for a project. There is no explicit when-to-use, when-not-to-use, or guidance about more specific sibling alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must communicate behavioral traits. The verb "Delete" implies a destructive mutation, but the description does not disclose side effects, permission requirements, idempotence, or the expected response on success.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and contains no filler, but it is almost a restatement of the tool name and is too terse to convey the necessary context. It is not bloated, yet it sacrifices informativeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the definition relies entirely on this brief description and the parameter schema. It omits the issue scope implied by issueIdOrKey, any usage context, and what happens after removal, making the tool definition incomplete for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema clearly documents issueIdOrKey, accountId, and the deprecation of username. The description adds no parameter-level information, but the schema already covers this dimension adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
"Delete watcher" states a clear action and object, and the verb loosely distinguishes it from add_watcher and get_issue_watchers. However, it does not specify that the watcher is removed from an issue and adds almost no information beyond the tool name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance about when to use remove_watcher instead of add_watcher or get_issue_watchers. There is no mention of prerequisites, alternatives, or the deprecated username parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It only repeats the create/update semantics already present in the tool name, without explaining what updating entails, whether existing links are overwritten, what happens on conflict, or what permissions/effects are involved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but this is under-specification rather than effective conciseness. It provides no added value beyond the tool name and does not earn its place as a helpful explanation for an upsert operation with a nested object.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is an upsert tool with no output schema, no annotations, and a complex nested body parameter. The description leaves the agent without enough context to construct a correct request body, understand update semantics, or know how the response will look or whether the operation is idempotent.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 top-level parameters, so baseline is 3. The description adds no parameter meaning beyond the schema. The nested 'body' object contains fields like globalId and relationship that remain unexplained in both the description and 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 the verb and resource: 'Create or update remote issue link.' It is unambiguous about the operation, and the 'remote' qualifier distinguishes it from ordinary issue-link tools like link_issues. It lacks richer detail but is not confusing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as link_issues or get_remote_issue_links. The description implies usage from the verb 'create or update,' but it does not state prerequisites, conditions, or cases where a different tool should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Create issue link' only implies a mutating operation; it does not disclose whether both issues must already exist, what happens with an invalid link type, whether the comment field is used, idempotency behavior, or what the response contains. This is minimal disclosure for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single three-word sentence with zero wasted words and front-loaded action. It is efficient to a fault — the brevity is itself the cause of the informational gaps in other dimensions, but as a concise statement it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutating tool with one parameter that nests four sub-fields, no annotations, no output schema, and a rich family of link-related sibling tools. The description explains none of the linking semantics, the meaning of inward/outward directions, when the comment applies, or how this differs from remote issue links. It is not complete enough for an agent to invoke correctly without guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 reported at 100% because the body parameter has the description 'The issue link request.', which merits the baseline of 3. However, that description is nearly tautological, and the nested properties (type, comment, inwardIssue, outwardIssue) are entirely undescribed. The tool description adds nothing about parameter meaning, leaving the distinction between inward and outward issues unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create issue link' states a verb and a resource, so it is not a meaningless tautology. However, it barely elaborates on the tool name 'link_issues' and does not convey that an issue link connects two issues (inward/outward) via a link type. The purpose is identifiable but vague, leaving the agent to infer the core semantics from the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention the sibling tools get_issue_link, delete_issue_link, get_issue_link_types, or create_or_update_remote_issue_link, nor any condition that would select one over the other. An agent must rely on naming conventions and schema inspection to make the call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states the action. It does not mention that this is a mutating bulk operation affecting many issues, that sendBulkNotification can be configured, or whether the edit is reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At three words, there is no redundancy, but this reads as under-specification rather than effective conciseness. A tool with a nested required body needs more structured detail to support correct invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a bulk mutation tool with three required inner fields, no annotations, and no output schema, yet the description supplies no selection context, usage constraints, or side-effect warnings. The definition is far too thin for an agent to call this tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is effectively high because the body property is described, so the baseline is 3. The tool description adds no parameter meaning: it does not explain editedFieldsInput format, valid selectedActions values, or how issue IDs/keys are referenced.
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 'Bulk edit issues' supplies a clear verb and resource, so an agent can see this operates on multiple issues at once. However, it does not distinguish it from sibling bulk tools like submit_bulk_move, submit_bulk_delete, or submit_bulk_transition, nor from edit_issue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus the other bulk operations or edit_issue. No alternatives, exclusions, or conditions are mentioned, so the agent must infer usage entirely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Delete issue property' signals a destructive action but does not explain whether deletion is permanent, whether it fails for missing properties, or whether any related data or history is affected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short—only three words—and contains no unnecessary text. However, this is under-specification rather than effective conciseness, since it omits even brief context about effects, usage, or prerequisites.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations and no output schema, the description is incomplete. It does not address failure modes, irreversibility, permission requirements, or how the response is structured, leaving an agent without enough context to invoke the tool confidently in an operational scenario.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters are adequately described in the schema itself. The description adds no additional parameter meaning, but given the high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (delete) and a specific resource (issue property), which clearly differentiates it from siblings like get_issue_property and set_issue_property. However, it does not define what an issue property is or clarify its relationship to issues, leaving some ambiguity for an agent encountering the term for the first time.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as set_issue_property or get_issue_property. The description does not mention prerequisites, side effects, or conditions that would make deletion appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It only states 'Get', implying read-only retrieval, but it does not mention auth needs, pagination, behavior differences between component sources, or what happens when the project has no components.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but not usefully concise: it essentially restates the tool name and provides no additional context. The single sentence does not earn its place beyond what the name already communicates.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should compensate by explaining what a 'project component' is and what the response looks like. It does neither, and it leaves the meaning of compass/auto sources unexplained despite the truncated schema hint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter docs already carry the semantic weight. The tool description adds nothing about projectIdOrKey or componentSource, but it is not required to duplicate 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 states a clear verb and resource: 'Get project components.' Though it repeats the tool name almost exactly, it identifies a distinct resource and can be visually separated from sibling tools like get_project, get_project_versions, or create_component.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_project_versions or create_component. It also does not explain when to choose jira vs compass vs auto for the componentSource parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Update worklog' conveys mutation but does not disclose side effects such as changing issue time estimates, notifying watchers, overwriting fields, or respecting editability flags. This is a significant transparency gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two words, which is concise, but this is under-specification rather than effective conciseness. It restates the tool name and contributes no additional information that would help an agent select or invoke the tool. The definition does not earn its place beyond being a label.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 8-parameter mutation tool with no annotations and no output schema, the description is far too sparse. It omits what the request body should contain, how time estimate adjustment works, and what response behavior to expect. The rich schema covers parameter formats, but the overall tool context is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema documents all eight parameters including the nested body object and the adjustEstimate enum. The description itself adds no parameter-level meaning, so the baseline score of 3 is appropriate because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Update worklog'. It clearly indicates the operation is modifying an existing worklog, which distinguishes it from sibling tools like add_worklog, delete_worklog, and get_worklog. However, it provides no details about what aspects of the worklog can be updated, so it stops short of the richest possible purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention that it is for existing worklogs only, nor does it reference add_worklog for creating worklogs or delete_worklog for removing them. Usage context is left entirely to inference from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only restates the operation and omits important behavior like pagination, expand behavior, date filtering, and response shape. The verb 'Get' at least implies a read-only operation, but that is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and concise, with no filler. However, it borders on tautology by simply restating the tool name, so it earns limited credit for efficiency while providing almost no additional content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema or annotations, so the description needs to compensate by explaining that the tool returns worklogs for an issue, likely paginated and filterable by start time. The current description is too sparse for a tool with 6 parameters and pagination semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 schema already explains pagination, expand, and date range parameters. The description adds no meaning beyond what the schema provides, which is acceptable given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Get issue worklogs' makes the operation specific to retrieving worklogs for an issue. It also distinguishes itself from sibling write tools like add_worklog, update_worklog, and delete_worklog, though it does not clarify whether this returns a list or a single worklog compared to get_worklog.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use this tool versus alternatives, such as get_worklog. The description only states the action without specifying conditions, prerequisites, or exclusions, leaving the agent to infer when this is the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It hints at a read-only search but does not explicitly state that issues are not modified, does not mention pagination ('nextPageToken'), and fails to explain the 'reconcileIssues' behavior suggested by the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It is concise, but the vague 'enhanced search' and the missing reconcile aspect keep it from being fully effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a nested request body, no output schema, and no annotations, a one-sentence description is severely inadequate. It omits how the body should be structured, what results look like, how pagination works, and the purpose of the 'reconcileIssues' array.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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% at the top level, so the baseline is 3. The tool description adds a hint that 'jql' is a JQL query, but the nested body fields such as 'reconcileIssues', 'nextPageToken', and 'fieldsByKeys' remain unexplained in both the description and the schema, so no added meaning is provided beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Search') and resource ('issues') with JQL, and the POST method is stated. However, the tool name references 'reconsile_issues' which is absent from the description, and the phrase 'enhanced search' is vague, so it does not fully distinguish itself from sibling search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool over alternatives, no conditions, and no exclusions. The description simply states what it does, leaving the agent to infer suitability from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'paginated'. It does not clarify read-only behavior, return value shape, default/max limits, experimental status of some parameters, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, but it is so terse that it omits the core search/filter purpose and any context. It earns brevity at the cost of useful content for a 13-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a rich 13-parameter input, the one-phrase description is insufficient. The schema covers individual parameters, but the description fails to communicate the tool's overall search/filter role, pagination behavior, or relationship to sibling project tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents all 13 parameters and their meanings, so the description need not compensate. The description adds no parameter-level meaning beyond the word 'paginated', which is also reflected in startAt/maxResults descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action and resource ('Get projects') with a useful qualifier ('paginated'), so an agent knows it returns project data in pages. However, it does not distinguish this from the sibling get_all_projects or get_project, and it omits the search/filtering nature that the name and parameters imply.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use search_projects versus alternatives such as get_all_projects or get_project. The description gives no conditions, exclusions, or hints about which sibling to prefer in which situation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of explaining behavior. It only states the read-oriented purpose and does not disclose pagination, default result limits, the deprecated username parameter, or the query/accountId mutual-exclusivity. This is a minimal disclosure for a search/list tool with no explicit behavior beyond 'find'.
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 six words and front-loads the core action and resource, with no filler. It earns its place as a title-like summary. However, the extreme brevity leaves useful usage and behavioral context for other dimensions rather than this one.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a 6-parameter tool with one required key, no annotations, no output schema, and a close sibling find_users; the single-sentence description is not enough to select or invoke it confidently. Important operational details such as query/accountId exclusivity, pagination defaults, and distinction from find_users are absent. The description covers purpose only, so the overall definition is incomplete 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 already documents all six parameters with 100% coverage, so the baseline is 3. The description adds no parameter-specific meaning beyond framing projectKeys in the context of assignability. It does not clarify the relationship between query and accountId or the paging parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Find'), names the resource ('users'), and qualifies the scope ('assignable to projects'), which distinguishes it from generic siblings like find_users. It is concise and leaves little ambiguity about the action. It does not explicitly mention 'bulk' or contrast with sibling search tools, so it falls just short of top marks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided for when to use this tool rather than find_users or other user-related tools. There are no stated exclusions, prerequisites, or alternative conditions. The only implied usage is from the purpose phrase itself, so an agent must infer when this variant applies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Get all projects' and does not mention pagination, authorization scope, response size, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded with no filler. It is slightly under-specified for the tool's context, but as a single-sentence definition it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With three optional parameters and no output schema, the description does not explain the return shape or usage context. An agent can infer the basic operation but not enough to confidently distinguish and invoke this tool over siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already documented in the input schema. The tool description adds no parameter-specific meaning, but the schema covers the need.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Get') and resource ('all projects'), so an agent understands the basic operation. It does not distinguish itself from sibling tools like search_projects or get_project, preventing a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as search_projects or get_project. It provides no context, exclusions, or routing information despite many nearby sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must disclose behavior. It only confirms the operation is a retrieval ('Get') but does not mention return format, pagination, permissions, or failure modes, which is a significant gap for a tool with no annotation safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded, with no wasted words. However, it adds little beyond the tool name and is under-specified; a middle score is appropriate for conciseness without substantive content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one fully-described parameter, but there is no output schema or annotation coverage. The description fails to hint at the return structure (e.g., a list of watchers), leaving a modest gap for an agent expecting to handle the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents the single parameter (issueIdOrKey with description), so the description adds no new meaning. Baseline 3 applies because schema description coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Get') and target ('issue watchers'), making the purpose clear. It does not explicitly differentiate from sibling tools like add_watcher/remove_watcher, but the resource is unambiguous enough for basic selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool vs. alternatives, nor any prerequisites or typical scenarios, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral disclosure burden. It simply says 'Get all statuses', which implies a read-only operation, but gives no information about permissions, response format, pagination, or whether statuses are project-scoped or global. This is minimal beyond what the verb 'get' already suggests.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single brief sentence, front-loaded with the core operation. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no annotations and no output schema, the description is the sole source of context. It tells the agent that all statuses are returned, but not what a status represents, how the response is structured, or if any scoping applies. This is minimal and leaves important gaps for autonomous decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema, so there are no parameter semantics to document. Per the baseline for tools with no params, this 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 states a specific verb and resource: 'Get all statuses'. It is clearly distinct from sibling tools like get_transitions and get_priorities, but it does not clarify whether these are issue statuses, workflow statuses, or something else, leaving slight ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. There is no mention of scenarios, exclusions, or related getters. The description only states what the tool does, not when it should be selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. "Bulk delete" conveys destructiveness but says nothing about whether deletion is permanent, whether notifications are sent, what permissions are required, or what response is returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded with the core action. It does not waste words, but it is so terse that it leaves out behavioral and usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive bulk operation with no annotations and no output schema, a three-word description is not enough. It lacks details on effects, prerequisites, response behavior, and how it differs from related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the body parameter, so the schema already explains the request body. The tool description itself adds no parameter-level meaning, but the nested property names like selectedIssueIdsOrKeys and sendBulkNotification are reasonably self-explanatory.
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?
"Bulk delete issues" clearly states the verb and resource. It distinguishes itself from sibling bulk operations like submit_bulk_move or submit_bulk_edit, though it does not explicitly contrast with the single-issue delete_issue tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention that delete_issue might handle single deletions or that bulk operations are for multiple issues, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Bulk create issue' only indicates a write operation and bulk behavior; it does not mention failure modes, partial success, limits, authentication needs, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, but it is under-specified rather than efficiently complete. There is no structure or additional context to help an agent understand the bulk creation semantics or request format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, no annotations, and a nested input body, the tool needs more contextual detail. The description does not explain how issueUpdates should be formed, what constraints exist, or what the bulk operation 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 description coverage is 100% for the single body parameter, so the baseline is 3 even though the description itself adds no parameter-level meaning. The schema describes body as 'Request body (JSON object)' but does not explain the issueUpdates items; however, per the rubric, high coverage keeps this at 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 'Bulk create issue' clearly states the verb (create), the resource (issue), and the bulk qualifier, which distinguishes it from the sibling tool create_issue. This is specific enough for an agent to identify the tool's core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as create_issue, submit_bulk_edit, or bulk_fetch_issues. The description does not mention any conditions, exclusions, or preferred contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. 'Get' implies a read operation, but the description does not state whether the result is a fixed list, whether it requires prior setup, or anything about the response shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, with no wasted words. However, it reads almost as a restatement of the tool name and provides only minimal information beyond it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter getter, a short description is tolerable, but there is no output schema and no explanation of what issue link types are or what the return value represents. The agent cannot tell whether this returns a global metadata list or something project-specific.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so there are no parameter semantics for the description to clarify. The baseline of 4 applies because no parameter information is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('get') and resource ('issue link types'), clearly identifying the operation. It is not a tautology, but it does not explicitly distinguish itself from sibling tools like get_issue_link or link_issues beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_issue_link or link_issues. The description does not mention that this likely lists available link types for use when linking issues, so the agent gets no routing or context clues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Bulk transition' only conveys a status change; it does not disclose side effects like notifications, permission requirements, batch atomicity, or reversibility — a significant omission for a bulk write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only four words, contains no fluff, and front-loads the core action. It loses a point because it is a terse fragment rather than a structured statement and omits qualifiers that would materially help the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a bulk side-effecting operation with no annotations and no output schema, this description is too sparse: an agent cannot determine how to express a transition (issue keys? transition IDs? notification settings?) or what the result will be. The schema provides structure, but the description does not fill the remaining 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 high since the body parameter already has a description about containing issues to be transitioned, so the baseline is 3. The tool description adds no further semantic detail about what each string in bulkTransitionInputs represents or how sendBulkNotification behaves.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear operation — bulk transition — and identifies the resource being affected (issue statuses), which distinguishes it from sibling bulk move/delete/edit tools. It does not explicitly contrast with the singular do_transition or mention the target statuses, so it stops just short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Use for bulk status transitions is implied by the word 'bulk', which weakly separates it from the singular do_transition sibling. However, there is no explicit guidance about prerequisites, when not to use it, or how it relates to get_transitions/do_transition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states the action; it does not confirm whether the deletion is permanent, whether it affects linked issue data, whether permissions are required, or how the response appears. For a destructive operation this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler. It is front-loaded and every word earns its place, though it lacks additional useful context like behavior or return values.
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 two-parameter delete operation with full schema coverage, the description is minimally adequate. It correctly identifies the resource and identifier, but lacks explicit destructive-behavior warnings and any guidance about output or side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description maps naturally to linkId and issueIdOrKey, but adds no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Delete'), resource ('remote issue link'), and the key identifier ('by ID'). It distinguishes this from the sibling get_remote_issue_link_by_id and create_or_update_remote_issue_link, and clearly aligns with the input schema's linkId parameter.
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: deleting a specific remote issue link by its ID, paired with the issue ID/key. It does not explicitly state when to use it over alternatives or mention any conditions, but the sibling context makes the fundamental use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. The word 'metadata' usefully signals that the tool returns attachment metadata rather than the binary attachment content, implying a read-only operation. However, it does not disclose authentication requirements, error behavior, or the shape of the returned metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise phrase with no filler. It earns its place by stating the core action and resource, though it lacks additional context that could make it more helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool, the description plus schema is minimally sufficient: the agent knows what to call, what parameter to provide, and that the result is metadata. However, without an output schema or annotations, the description does not clarify what fields of metadata are returned or any special cases like missing or invalid attachment IDs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already defines 'id' as 'The ID of the attachment.' The description adds no parameter-specific detail beyond that, but the schema fully covers the single parameter, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Get') and the resource ('attachment metadata'), which is specific enough to distinguish it from siblings like add_attachment and get_issue. It stops short of a 5 because it does not explicitly differentiate itself from potential related tools or define what 'metadata' includes relative to the attachment content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not state when to use this tool, when not to use it, or mention any alternative such as add_attachment for uploading or other issue-related retrieval tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of indicating behavior; 'Get' conveys a read-only retrieval operation and no destructive side effects. However, it does not mention permissions, not-found behavior, or what the response contains, leaving some behavioral uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the key operation and resource. It wastes no words, though it is close to merely restating the tool name in title case.
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 two-parameter lookup with 100% schema coverage, the description is minimally adequate. The absence of an output schema and annotations means the agent cannot know the return shape or error behavior, but the operation itself is low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both linkId and issueIdOrKey already have clear descriptions. The tool description adds little beyond the word 'ID', so it does not compensate further, but it does not need to because the schema is self-sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('remote issue link') with a scope qualifier ('by ID'), so an agent can tell it from get_remote_issue_links, which returns all links for an issue. It does not explicitly name the sibling or mention that an issueIdOrKey is also required, but the core purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to call this tool versus get_remote_issue_links or the create/update/delete variants. The only hint is the implicit 'by ID' qualifier; there are no explicit conditions, exclusions, or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'Get all labels' implies a complete retrieval, but the pagination parameters suggest this tool returns only one page; the description does not disclose that fact or explain how to obtain all labels.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three words long, with no filler, and every word contributes meaning. It is a model of concise, front-loaded clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with optional pagination parameters, the description is minimally viable for a basic call. However, it lacks context about pagination behavior and return format, which matters when the agent needs to retrieve all labels beyond the default page size.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 parameters 'startAt' and 'maxResults' are already fully documented in the schema. The description adds no additional meaning beyond what the schema provides, matching the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all labels' uses a specific verb ('Get') and a clearly identified resource ('all labels'), and there are no sibling tools with a similar or overlapping purpose, so an agent can unambiguously tell what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The name makes the intended use implicit: call this when labels need to be retrieved. However, the description gives no explicit guidance about when to prefer this tool, whether pagination should be iterated to truly get 'all' labels, or any exclusions/alternatives.
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:

[![jira MCP server](https://glama.ai/mcp/servers/pascalhubacher/jira/badges/card.svg)](https://glama.ai/mcp/servers/pascalhubacher/jira)

Score Badge

Copy to your README.md:

[![jira MCP server](https://glama.ai/mcp/servers/pascalhubacher/jira/badges/score.svg)](https://glama.ai/mcp/servers/pascalhubacher/jira)

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/pascalhubacher/jira'

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