jira-mcp

Server Quality Checklist

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

Latest release: v0.5.2
Disambiguation4/5
Most tools target a distinct resource and action, and descriptions clarify likely variants like get_sprint, get_sprint_issues, and get_sprint_view. A few close pairs exist—get_issue_types vs get_project_issue_types and update_issue vs move_issue_to_epic—but the resource scopes and descriptions make misselection unlikely.
Naming Consistency3/5
The set mostly follows verb_noun, but it mixes get_ and list_ for collections, uses create_ for most resources but add_ for comments and worklogs, and uses search_issues versus find_users. jira_api also breaks the pattern, making the naming readable but not consistently structured.
Tool Count2/5
43 tools is well beyond the 25+ threshold, and the surface includes many fine-grained getters plus a catch-all jira_api tool. While Jira is a broad domain, the large count makes agent tool selection heavier than necessary, and some variants could reasonably be consolidated.
Completeness4/5
Core Jira workflows—issues, sprints, epics, projects, comments, worklogs, and users—are well covered with appropriate create/read/update/delete operations where relevant. Minor gaps exist, such as no update_comment, no delete_sprint, or no direct add-issue-to-sprint tool, but jira_api and update_issue provide usable workarounds.
Average 3.8/5 across 43 of 43 tools scored. Lowest: 2.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 12 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

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 a component is created, with no mention of permissions, side effects, uniqueness constraints, required relationships, or response behavior, which is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only one sentence and contains no padding, but it is under-specified rather than genuinely concise: it largely restates the tool name and adds minimal useful information. There is no structure that surfaces scope, constraints, or relationships to sibling tools.
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 should provide more operational context, such as how to identify the project, what makes a component valid, or what the agent should expect on success. The current text leaves too much unspecified for correct invocation and interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents projectKey and name, but the description section for the third parameter ('description') is empty. The tool description adds no parameter-level meaning beyond a generic reference to 'a project' and 'a component,' so it does not compensate for the incomplete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('component in a project'), so an agent can tell it is a creation operation on a specific entity. It does not, however, differentiate this from sibling creation tools like create_issue or create_sprint beyond the noun '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?
There is no guidance on when to use this tool instead of related tools such as get_project_components or update_issue. The description provides no context, exclusions, prerequisites, or alternative routing, 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?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only says 'Add a comment to an issue' and does not mention permissions, side effects, whether the comment is appended immediately, or what response to expect. For a mutation tool, this is a notable 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 one short, front-loaded sentence with no filler or redundancy. It is appropriately concise for a straightforward action, though it sacrifices useful behavioral detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity, full parameter coverage, and no output schema, the definition is minimally viable. However, without annotations or usage guidance, an agent still lacks context about permissions, return values, and when this tool should be chosen over related comment 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%, so the parameters (body, issueKey, visibility) are already documented adequately. The description itself adds no parameter-level meaning, but the schema handles that baseline fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Add') and a clear resource ('a comment to an issue'), making it easy to understand what the tool does. It implicitly differentiates from siblings like list_comments and delete_comment by focusing on creation, though it does not explicitly name alternatives or scope limitations.
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 list_comments, delete_comment, or update_issue. The intended use is only implied by the action verb; there are no preconditions, exclusions, or examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden of behavioral disclosure, but it only states the basic read operation. It does not disclose return shape, error behavior for invalid keys, whether expansion is needed for full data, or any rate/access constraints, adding little beyond what the tool name already implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with zero wasted words, action and resource front-loaded. It is efficient, though its terseness edges toward under-specification — a short clause of usage context would have fit without bloating the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-key tool with fully documented parameters, the description is minimally viable, but there is no output schema and no annotations, so the agent is left without any indication of the response format, error cases, or how this differs from search_issues. These gaps matter most for an AI agent deciding how to interpret 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?
Schema description coverage is 100%, so the schema fully documents all three parameters (issueKey, expand, fields), including the example and default field list. The description adds no new parameter meaning — its PROJ-123 example merely duplicates the schema's — so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a specific resource ('a single Jira issue'), and the addressing mechanism ('by key, e.g. PROJ-123'). The word 'single' implicitly distinguishes it from siblings like search_issues, though no sibling is named explicitly; the distinction is behavioral rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus search_issues (when you don't have a key and need to find one first) or get_issue_transitions (when you need workflow transitions). The only implication is that a key is required, but there are no explicit usage contexts, exclusions, or named 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds one useful detail — the exact ISO-8601 date format with milliseconds and timezone offset — but omits material behavior for a creation tool: whether the sprint is created in an active or future state, what the response contains, and whether any board must exist. These gaps are significant for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no waste: the purpose is front-loaded in the first sentence, and the second sentence adds a high-value format clarification. Every word 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?
For a mutation tool with no annotations and no output schema, the description is thin. It doesn't explain what the tool returns (e.g., the created sprint's ID), the resulting sprint state, or any preconditions. The parameter schema is complete, but the missing behavioral and response context leaves an agent guessing after 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?
Schema description coverage is 100%, so the baseline is 3 and the schema already documents all 5 parameters. The description adds value beyond the schema by giving a concrete date format example (2026-09-01T09:00:00.000+0000), clarifying the exact ISO-8601 variant expected for startDate and endDate, which is a common failure point.
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 (create), resource (sprint), and scope ('on a board'), which clearly differentiates it from siblings like get_sprint, update_sprint, close_sprint, and list_sprints. It doesn't explicitly name any sibling alternative, but the create verb plus sprint resource makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, and no prerequisites are mentioned (e.g., needing a valid existing board). The only usage signal is the verb 'create', which implies this is for making new sprints rather than reading or updating them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden, and it does add one genuinely useful behavioral detail: the meaning of hierarchy levels in the results. However, it does not disclose pagination behavior despite the startAt/maxResults parameters, nor any error or empty-result behavior, leaving significant behavioral traits undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the action and resource, then adds the non-obvious hierarchy-level semantics. Every word earns its place; there is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description bears a heavier burden, and it covers the core purpose plus the key interpretive detail (hierarchy levels). But it leaves the return structure of each type unstated, says nothing about pagination despite pagination parameters, and provides no sibling differentiation, so completeness is adequate but gappy.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (33%), with only 'Project key' documented, and the description does not compensate. It adds nothing about startAt or maxResults, and the only parameter meaning it conveys is the implied projectKey scope via 'in a project.'
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 ('List') and a named resource ('issue types available in a project'), and adds value with the hierarchy-level semantics (epic = 1, story/task = 0, sub-task = -1). It is clear, though it does not explicitly differentiate itself from the closely named sibling get_issue_types; the 'in a project' scoping implies the distinction but does not make it explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus its alternatives. The sibling list contains get_issue_types, which is a very similar name and plausibly the global counterpart, yet the description neither names it nor states the condition that selects one over the other.
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 disclosing behavior. It accurately indicates a read operation, but it does not mention pagination semantics, default ordering, required permissions, or the shape of the returned comment list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It states the core action and resource efficiently without repeating the title verbatim.
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 omits return value expectations, pagination behavior, and ordering details, which are relevant for an agent to invoke the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, and the description adds no parameter-level meaning. issueKey and orderBy are documented in the schema, but startAt and maxResults are left to inference from their names and defaults, with no description compensating for the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a clear resource ('comments on an issue'). It is easy to distinguish from sibling tools like add_comment, delete_comment, or get_issue. No ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 choose this tool over alternatives, nor does it mention any exclusions or preconditions. Usage must be inferred 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only states that worklogs are listed; it does not mention pagination behavior, ordering defaults, permission implications, or the structure of the returned worklogs. The read-only nature is only implied by the word 'List'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. Its brevity is appropriate for a straightforward read/list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, an agent is left without critical context such as what a worklog object contains and how pagination is surfaced in the response. The description is too minimal to be fully actionable for a list operation that supports ordering and pagination.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes issueKey and orderBy, and startAt/maxResults have meaningful defaults and bounds. The description adds only the issue scope and adds little parameter-level meaning, but it does not conflict with the schema. This is adequate but not enriching.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a specific resource ('time-tracking worklogs') scoped to an issue, which clearly differentiates it from sibling tools like add_worklog and get_issue. The action and target are immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 contrast with add_worklog, get_issue, or list_comments, nor does it state any conditions, 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 present, so the description carries the full burden of behavioral disclosure. It only states the action and does not describe return contents, ordering, pagination, permissions, or any 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words and the action is front-loaded. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity, one fully documented parameter, and simple list operation, the description is mostly complete. The absence of an output schema or annotations leaves minor gaps about the exact response shape, but the core purpose and invocation are clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single projectKey parameter, so the schema already handles parameter meaning. The description ties the parameter to the project context but adds no additional syntax or format details.
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 names a specific action ('List') and a specific resource ('components of a project'), so the tool's purpose is clear. It does not explicitly distinguish itself from siblings like get_project_versions or create_project_component, but the resource term is distinctive enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as create_project_component or get_project_versions. The agent must infer usage from the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'List', which implies a read-only operation, but it does not disclose pagination behavior, sorting, required permissions, or what the result set contains.
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 focused sentence with no filler or repetition. It is concise and the key resource is front-loaded, though there is room to add useful context without harming 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 only 33% parameter coverage, the description is too minimal. It does not explain the return value shape, pagination behavior, or the meaning of the optional parameters, leaving an agent to infer important invocation details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, with only 'projectKey' documented. The description does not explain startAt or maxResults, nor does it clarify pagination semantics, so it fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('versions (releases) of a project'). The parenthetical 'releases' removes ambiguity, and the resource is distinct from the sibling tools, which cover projects, components, issue types, and roles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use this tool when you need versions or releases for a project. However, there is no explicit guidance about when to choose this over alternatives, no exclusions, and no mention that it complements get_project or get_project_components.
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. 'List' implies a read-only operation, but the description does not state what the returned data looks like, whether actors are user accounts or group names, whether all roles are returned, or any permission requirements. The core behavior is present but minimally elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that immediately conveys the action and target. There is no filler, and the key clarification about actors is included parenthetically without bloating the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only listing tool, the description covers the essential invocation need: the project context and the returned concept (roles with actors). It lacks a more detailed return-format explanation, but the low complexity and complete schema coverage make the description sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with a 'Project key' description. The tool description only restates the project context and adds nothing about the projectKey format or behavior, so it neither helps nor hurts beyond the baseline established by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and identifies the exact resource ('roles (and their actors) of a project'), making the tool's purpose unmistakable. It is clearly differentiated from sibling project getters like get_project, get_project_versions, and get_project_components.
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 about when to use this tool versus related project tools. It does not mention alternatives, exclusions, or typical use cases, so an agent must infer context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Because no annotations are provided, the description carries the full burden and it does disclose the core side effect: the sprint's state becomes closed. However, it does not mention reversibility, permissions, idempotency, or what happens to issues inside the sprint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no redundant information. Every word contributes to understanding the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter state-change tool, the description is mostly adequate, but with no annotations and no output schema it leaves unspecified what the API returns and what conditions or side effects apply. The gaps are not severe but are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the sprintId parameter already has a description, so the tool description adds no parameter-level meaning. A baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Close a sprint') and immediately defines the exact outcome ('sets its state to closed'). This clearly distinguishes the operation from create_sprint, update_sprint, and get_sprint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance about when to use this tool versus alternatives like update_sprint, nor any exclusions or prerequisites. The scenario is implied by the name and effect, but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Delete a comment' without stating that deletion is permanent, whether it cascades to replies, or any permission requirements. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler. The verb and object are front-loaded, and the provenance note is concise and useful. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter delete, the description covers the core action and the ID source. However, with no annotations and no output schema, it omits destructive consequences and any response/return expectations, leaving some uncertainty for a tool that permanently alters data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both issueKey and commentId have descriptions. The tool description adds one useful detail—that commentId comes from list_comments—but otherwise adds no new parameter meaning beyond what the schema already provides. This matches the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States the specific action (Delete), the resource (comment), and the identifier (comment ID), and even notes that the ID comes from list_comments. This clearly differentiates it from sibling tools like delete_issue and aligns with add_comment/list_comments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase '(from list_comments)' implies the workflow of first retrieving a comment ID, but it does not explicitly state when to use this tool versus add_comment/list_comments, nor any conditions against using it. Usage context is present but only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does add useful behavioral context: environment-specific search fields and that the output is account IDs/usernames usable for assignment. However, it omits details like whether this is read-only, case sensitivity, pagination behavior, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no fluff. Every clause adds information: what is searched, the environment difference, and the output purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter search tool, the description covers the core purpose and return value. It is less complete because it does not mention result limits or how to choose between this and get_user, and there is no output schema to clarify the response shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 only 50% (query is documented; maxResults is not). The description adds important semantics for query by distinguishing Cloud vs Data Center behavior, which is beyond the schema. It does not add any meaning for maxResults, though the schema's default/min/max partially compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states a search verb and the user resource with specific searchable fields (name/email/username), and notes Cloud vs Data Center differences. It is distinct from sibling get_user because it is a search, not a single-user fetch, though it does not explicitly name that sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'usable for assignment' implies the intended use case, but the description does not explicitly say when to prefer find_users over get_user or when not to use it. There is no exclusion or alternative routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates that this is a read-style 'Get' and does not mention permissions, error/not-found behavior, or what the response contains. This is a thin disclosure for an operation with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence with no filler, front-loading the core operation and lookup method. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read operation, this is minimally sufficient because the schema covers the parameters. However, with no output schema and no annotations, it does not disclose return shape, failure behavior, or permission expectations, leaving some context to assumption.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema documents both parameters with 100% coverage, including the distinction between project key and numeric ID. The description does not add parameter-level meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a specific resource ('a single project'), and the lookup mechanism ('by key or ID'). The 'single' qualifier distinguishes it from list_projects and other project-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for fetching one known project by identifier, but it does not explicitly state when to use it versus list_projects or other project sub-resource tools. There is no mention of exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It adds useful context by tying the identifier choice to the API version/deployment type, but it does not disclose response shape, error behavior, authorization requirements, or what happens if both or neither parameter is supplied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently packs the core lookup semantics and deployment/API mapping together.
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 read operation, the description is mostly sufficient, but with no output schema or annotations it leaves gaps around return payload, error handling, and parameter cardinality. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters with 100% coverage, so the baseline is 3. The description's 'or' adds a mutual-exclusion cue that is not explicit in the schema, but it does not clarify whether exactly one parameter is required or how conflicts are resolved.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Get a user') and clarifies the lookup mechanism ('by account ID' or 'username'), including deployment/API-version mapping. This distinguishes it from sibling tools like get_current_user and find_users by implying a direct lookup of a known user, though it does not explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context about which identifier to use based on Jira deployment (Cloud/API v3 vs Data Center/API v2), which helps an agent call it correctly. However, it does not explicitly state when to prefer this tool over related siblings such as get_current_user or find_users, nor what to do when no identifier is available.
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 disclosure burden. It clearly conveys a read-only listing operation and discloses the state filter, but it does not mention pagination behavior via startAt/maxResults, potential errors, or what data is returned for each sprint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence with no filler. It states the main action, the resource, and the optional filter in a compact and immediately scannable way.
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 four parameters, no annotations, and no output schema, so the description should compensate by explaining pagination parameters and the result shape. It only covers the state filter, leaving meaningful gaps that an agent would need to guess or infer from parameter names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%; boardId and state are described in the schema, but startAt and maxResults have no descriptions. The tool description repeats the state enum in prose but adds no meaning for the pagination-related parameters, so the agent must rely on parameter names and defaults to infer their purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a clear resource ('sprints on a board') and adds an optional state filter, making the action unambiguous. It is easily distinguished from sibling tools like get_sprint or list_boards because it targets all sprints for a given board.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you want the sprints belonging to a specific board, optionally narrowed by state. However, it provides no explicit comparison to alternatives such as get_sprint for a single sprint or create_sprint for new sprints, and it does not state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The phrase 'This is destructive' is a meaningful warning, and with no annotations the description carries the full burden of behavioral disclosure. However, it does not explain permanence, permission requirements, cascading effects, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The action is stated first, and the caution follows immediately; every word contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter destructive tool with no output schema, the description captures the essential facts: what action to perform and that it is destructive. Missing details like permissions or response shape are peripheral given the low complexity of this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: issueKey is already documented with a clear description and example (PROJ-123). The tool description adds no extra parameter meaning, so it relies on the schema 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?
States a specific action verb ('Delete') and resource ('an issue'), clearly distinguishing it from siblings like create_issue, update_issue, and transition_issue. No ambiguity about 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no explicit guidance on when to use this tool versus alternatives, no context, prerequisites, or exclusions. The intended use must be inferred entirely from the tool name and the word 'Delete'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It accurately states the operation, but does not explicitly say it is read-only, that results depend on the issue's current status or workflow, or mention permission/visibility constraints. The term 'available' hints at context-dependence but does not elaborate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no filler. The action and object are front-loaded, and every word contributes to understanding what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list operation, the description is largely sufficient for an agent to invoke it correctly. The main gap is the absence of any note about how transitions depend on the issue's current status or workflow, and there is no output schema to clarify the return shape, but the operation's simplicity keeps this from being a major deficiency.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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, issueKey, including an example format. The description adds no additional parameter meaning, so the baseline of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb, 'List', with a clear resource, 'workflow transitions available for an issue.' It clearly distinguishes this read/list operation from the sibling action tool transition_issue, which performs a transition rather than listing available ones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance about when to use this tool rather than transition_issue or other issue-related tools. The intended usage is only implied by the word 'available,' but no note says to call this before transitioning an issue or to discover valid transition IDs.
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 behavioral disclosure burden. It adds useful details: started defaults to now and timeSpent uses Jira format. However, it does not disclose permissions, reversibility, side effects, or what response to expect, which would be valuable for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, front-loaded with the core action and followed by the most important parameter behavior. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 4-parameter tool, the schema and description together provide sufficient input guidance. But since there is no output schema and no annotations, the description is less complete than it could be about the mutation outcome, response shape, or failure conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description goes beyond it by giving explicit Jira format examples ('2h 30m', '1d') and reaffirming the started default behavior. This meaningfully helps an agent format parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Add'), a specific resource ('worklog'), and clarifies it logs time spent to an issue. This clearly distinguishes it from sibling tools like add_comment or get_issue_worklogs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not state when to choose this tool over alternatives, nor does it mention exclusions or related read/edit tools. Usage context is only implied by the tool name and resource.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. 'Only provided fields are changed' is a genuinely valuable disclosure that prevents an agent from assuming PUT-like full-replacement semantics. However, it does not disclose whether state transitions are restricted (e.g., reopening a closed sprint), error behavior, or permission requirements, which are material for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single 15-word sentence that front-loads the action and resource, lists the scoped fields, and ends with the critical partial-update behavior. Every word earns its place; there is zero redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter mutating tool with no annotations and no output schema, the description covers the core: what can be updated and the non-destructive partial-update semantics. It omits state-transition constraints and error behavior for invalid combinations, which an agent would need to invoke this correctly against a sprint workflow. Adequate but with clear 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 coverage is 67%, with name and goal lacking descriptions. The description compensates by enumerating 'name, goal, dates, or state,' which maps to the six parameters and adds meaning for the two undocumented ones. It clarifies the state parameter's domain (active/closed/future) and groups the two date parameters, though it adds no format or constraint detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Update') and resource ('a sprint'), and enumerates exactly which aspects are modifiable: name, goal, dates, and state. The field list makes it clearly distinct from specialized siblings like close_sprint (state=closed only) and create_sprint, so an agent can select it without opening 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The partial-update note ('Only provided fields are changed') implies this tool is for surgical modifications rather than full replacements, which is useful context. However, there is no explicit guidance on when to prefer this over close_sprint, create_sprint, or other sprint siblings, and no when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. 'List' and 'including whether each one is done' convey a read-only intent and a useful output field. However, it does not disclose pagination behavior or how filtering affects the result beyond what the schema already implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler. Every phrase adds meaning: the verb, the resource, the scoping to a board, and the done-status detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple board-level list operation: the required boardId is easily inferable and the done status is highlighted. The lack of an output schema, pagination guidance, and explicit routing to get_epic or get_epic_issues leaves moderate gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%: startAt and maxResults are not described in the schema, and the description does not compensate for them. It only reinforces the board scoping and done status already visible in schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action (List), a resource (epics), and a scope (on a board), and adds a concrete output characteristic (whether each one is done). This differentiates it from singular get_epic and mutating create_epic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it is the board-level listing tool for epics. It does not explicitly name alternatives such as get_epic or explain when not to use it, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does add useful context by noting that Cloud uses a paginated endpoint while Data Center uses a different endpoint, but it omits details like return format, whether Data Center honors pagination parameters, and any auth or visibility caveats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tight sentences with no filler. The main purpose is front-loaded, and the second sentence adds deployment-specific behavior that earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity, optional-pagination list tool, the description is largely sufficient: it states what is returned, the visibility scope, and deployment-specific endpoint behavior. Minor gaps remain around Data Center pagination behavior and the exact fields returned, but an agent can invoke the tool correctly from this description plus the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for missing parameter explanations. The mention of 'paginated /project/search' at least connects startAt and maxResults to Cloud pagination, but the description does not explicitly describe either parameter or clarify how they behave in Data Center.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation and resource: 'List all Jira projects visible to the current user.' The 'all projects' scope clearly distinguishes it from sibling get_project, which targets a single project. The additional Cloud vs. Data Center endpoint detail reinforces the tool's exact behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool is for fetching the full set of projects visible to the user, but it does not explicitly name alternatives or state when not to use it. Sibling tools like get_project exist for single-project lookups, but that distinction is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral disclosure. It adds useful context about validating fields via meta and passing customFields with an example. Still, it does not disclose the return value, required permissions, or error/validation behavior for a side-effecting create operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler: purpose is front-loaded, the prerequisite lookup is stated, and the customFields nuance is illustrated. Every sentence contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter creation tool with no output schema, the description plus 92% schema coverage provides a workable call path: use meta for valid values, pass required fields from schema, and add extras via customFields. It could mention the response body or auth requirements, but those are not necessary for selecting and constructing the call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (92%), so the schema already documents most parameters. The description goes slightly beyond the schema by explaining customFields as a way to pass extra fields with a concrete example, and by pointing to get_issue_create_meta for valid values of the required 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 opens with 'Create a new issue,' which is a specific verb and resource. It clearly distinguishes this from issue mutations like update_issue or delete_issue, though it does not explicitly discuss sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit workflow guidance: call get_issue_create_meta first to discover valid projects, issue types, and required fields. It does not list exclusions or say when not to use create_issue in favor of an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It genuinely adds behavioral context by revealing that Cloud and Data Center hit different APIs and that there is a JQL 'parent = <epic>' fallback for team-managed projects. It omits return format and pagination nuances, but the dual-path routing disclosure is valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences: purpose first, then platform routing, then fallback behavior. Every sentence earns its place and there is zero filler or repetition of the input schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description thoroughly covers the API-routing complexity (the hardest part of this tool). However, with no output schema and no annotations, the agent is left without expectations for result shape, ordering, or how pagination behaves differently across the two API paths (startAt/maxResults vs nextPageToken). Adequate for basic invocation, incomplete for confident advanced use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 60%, with fields, epicIdOrKey, and nextPageToken already documented in the schema. The description adds context for epicIdOrKey by showing how it plugs into the fallback JQL ('parent = <epic>'), but it offers nothing for startAt, maxResults, or nextPageToken. Partial compensation for the undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'List the issues belonging to an epic.' It then distinguishes this tool from siblings by detailing Cloud vs Data Center endpoint routing and the JQL fallback for team-managed projects, making it clearly separable from get_epic, search_issues, and get_sprint_issues.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when the tool's internal mechanisms apply (which endpoint per environment, fallback on team-managed projects) but never explicitly tells the agent when to prefer this tool over alternatives such as search_issues or get_sprint_issues. Usage context is implied rather than stated, and no exclusions or alternative tool names are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It usefully discloses that Cloud and Data Center use different API endpoints and paging mechanisms, which is valuable behavioral context. However, it does not mention return format, pagination loop behavior, authentication requirements, or rate limits, so there are still notable gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The primary purpose is front-loaded, and the Cloud versus Data Center distinction is stated compactly. Every sentence contributes meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and the main environment-specific behavioral difference, which is good for a list tool. However, there is no output schema and no annotations, so the description could have usefully noted what the response contains, how fields controls the returned attributes, or how to page through all results. These omissions leave the definition adequate but 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 80%, so the parameter descriptions already document most semantics, including that startAt is Data Center only and nextPageToken is Cloud only. The tool description adds context about 'enhanced endpoint with cursor paging' versus 'Agile 1.0 with startAt/total,' but this largely reinforces what the schema already says rather than adding significant new parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List the issues in a sprint,' a specific verb and resource that makes the tool's purpose immediately clear. It also distinguishes itself from siblings like get_sprint (which returns sprint metadata) and get_epic_issues by focusing on sprint-scoped issues, and adds Cloud/Data Center endpoint context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the tool is for listing issues in a sprint and gives environment-specific guidance: Cloud uses cursor paging while Data Center uses startAt/total. It does not explicitly name alternatives or state when not to use it, so it falls short of a 5, but the intended use context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It mentions returning raw JSON and how to structure requests, but does not warn that methods like DELETE or POST can mutate Jira data, nor does it mention authentication, rate limits, or error behavior. For a raw passthrough tool, this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler. The purpose is front-loaded, constraints are explicit, and examples are embedded without bloating the text. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core mechanics needed to make a call: path, query, body, and raw response. However, given the absence of annotations and an output schema, it is missing context about side effects, authorization, and error/response edge cases, which would matter for a generic API passthrough tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining how to use the parameters together: query params go in query, JSON payload in body, and paths must stay under /rest/. The example paths also make the intent of the path parameter clearer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific operation: calling any Jira REST API endpoint not covered by a dedicated tool. It also specifies the path constraint and gives concrete examples, which differentiates it from the many specialized sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool for endpoints not covered by a dedicated tool, which tells the agent when the tool applies. It also provides path restrictions and examples, but does not enumerate which siblings cover which endpoints, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does communicate that this is a read-only listing operation. However, it does not mention return shape, pagination behavior, or what board fields are returned, which are useful behavioral details for a list endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence conveys the purpose and all key filter options with no redundancy. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basics of a list call, but without annotations or an output schema it omits what the response looks like and how pagination behaves for the startAt/maxResults parameters. For a five-parameter tool, this leaves some context for the agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description paraphrases the schema's named filters (type, name, project key/ID) and confirms the one-project-key constraint, but it adds little beyond the existing schema descriptions. startAt and maxResults are left undocumented in both spots, so the 60% schema coverage is only partially compensated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource — "List Jira agile boards" — and narrows scope with "scrum or kanban." It is clearly distinct from sibling tools like get_board or list_sprints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use this tool when you need to list Jira boards, with optional filtering. It does not explicitly name alternatives or exclusions, but the filter options communicate the expected use cases without ambiguity.
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 disclosing behavior. It clearly states the operation is a listing action with no side effects, and that custom field IDs are included. It does not describe response shape, pagination, or authorization needs, but for a zero-parameter read-only metadata listing this is a reasonable level of disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured sentence that front-loads the core action and resource, then adds the useful detail about custom field IDs. There is no wasted text or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the zero-parameter schema, absence of annotations, and simple listing behavior, the description is almost complete. It covers what the tool returns conceptually and the scope. The only minor gap is the lack of any note about response structure or field metadata details, but this is not essential for a simple listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, and schema description coverage is 100%. There is nothing for the description to clarify about parameter meaning. A baseline of 4 is appropriate for a zero-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and a clear resource ('all issue fields'), and adds the important nuance that custom field IDs are included. This distinguishes it from sibling tools like get_issue_types or get_issue_create_meta, since it is explicitly about the full set of issue fields in the Jira instance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving field metadata across the entire Jira instance, which is a distinct use case from sprint, epic, issue, or project operations. However, it does not explicitly mention when to use this over get_issue_create_meta or list other metadata, nor does it state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses the core effect (moving an issue through its workflow) and notes that required fields come from get_issue_transitions, but it does not mention side effects such as status change irreversibility, permissions, or failure behavior. This is adequate but not richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler; the main action is stated first and the prerequisite is after. Every sentence contributes actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation with three parameters and no output schema, the description provides the essential context: what the tool does and how to source the required transition data. It omits minor details like optionality of fields or response shape, but the schema covers the parameters and the prerequisite covers invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already documented in the schema. The description adds the useful sequencing hint that transitionId and fields should be discovered via get_issue_transitions, but it does not add substantial meaning beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Move') with a clear resource ('an issue') and scope ('through its workflow'), which distinguishes this from sibling update_issue or get_issue_transitions. It also immediately names the companion tool get_issue_transitions, reinforcing the tool's role as the action that performs the transition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the prerequisite workflow: 'Use get_issue_transitions first to find the transition ID and required fields.' It gives clear context for when to use this tool, though it does not enumerate alternatives or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It usefully discloses the absolute-fields versus relative-update distinction and gives a concrete labels example, but it does not mention permissions, effects on unspecified fields, return behavior, or destructive consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The core behavior is front-loaded, and the example compactly illustrates both parameter styles without redundant explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the nested-object complexity and lack of annotations/output schema, the description covers the essential calling semantics well. Minor gaps remain around auth expectations, response shape, and exact behavior for unspecified fields, but these do not block correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all three parameters. The description adds real semantic value by explaining that 'fields' expects absolute values while 'update' expects relative add/remove operations, with a clear example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Update an issue') and immediately explains the two distinct update modes. This clearly separates it from siblings like create_issue, delete_issue, and transition_issue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for modifying existing issue fields or labels, but it never explicitly states when to choose this tool over alternatives like transition_issue, assign_issue, or create_issue. There is no when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It discloses a non-obvious requirement: the 'Epic Name' custom field may be required on company-managed projects and must be supplied via customFields. It also names the metadata tools to call first. It does not cover return values or permissions, but the key hidden behavior is addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The primary action is front-loaded, and the second sentence provides an important caveat and a concrete follow-up action. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter creation tool with no annotations and no output schema, the description is close to complete: it identifies the core gotcha around company-managed projects and provides the resolution path. It stops short of describing what the response contains or addressing other edge cases, but the schema already covers parameter details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining why customFields matters, giving the 'Epic Name' example, and connecting it to get_epic_meta and get_issue_create_meta. This is contextual information not inferable from individual parameter descriptions alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Create an epic in a project.' This clearly identifies the operation and distinguishes it from sprint or board operations. It does not explicitly differentiate from create_issue or move_issue_to_epic, but the epic-specific wording makes the target unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear contextual guidance by noting that company-managed projects usually require the 'Epic Name' custom field and instructs the agent to call get_epic_meta or get_issue_create_meta first. It does not explicitly discuss when to prefer create_epic over create_issue or when not to use the tool, but the prerequisite guidance is actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. It clearly discloses what the response contains (projects, location, settings) and implicitly signals a read-only operation via 'Get'. It does not address error/not-found behavior, but for a simple getter this is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the core action and resource, then enriched with output details. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter getter without an output schema, the description is complete: it states the action, the identifier, and the returned data categories. No further operational context is needed for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the single parameter already described as 'Board ID (numeric, from list_boards)'. The description adds no additional semantic detail beyond the schema, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') with a clear resource ('single Jira board by ID') and enumerates the included details (projects, location, settings). It is immediately distinguishable from siblings like list_boards or get_issue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: when you need a specific board by ID. However, the description does not explicitly contrast with list_boards (for enumeration) or mention any prerequisites beyond having the boardId, leaving selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden, and it discloses meaningful behavior: backlog definition, rank ordering, and Cloud vs Data Center differences with cursor paging versus startAt/total. It does not cover auth, rate limits, or response shape, but for a read-only list operation the key behavioral traits are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences with no filler. The core definition and scope appear first, followed by relevant version-specific behavior. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description, combined with a well-documented schema, covers what the tool does, its scope, ordering, and platform-specific pagination. The absence of an output schema means return format is not fully specified, but the description and field defaults provide reasonable context for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 83%, so the schema already documents most parameters. The description adds context about pagination modes matching Cloud vs Data Center, but it does not materially deepen the meaning of jql, fields, or boardId beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('List'), a precise resource ('a board's backlog issues'), a scope definition ('in the board's filter, not in a sprint'), and an ordering ('by rank'). This clearly distinguishes it from sprint-issue tools and general 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context about what constitutes a backlog and scopes it away from sprints, which implies when to use this over get_sprint_issues or search_issues. However, it does not explicitly name alternatives or state when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description appropriately discloses a non-obvious behavior: for team-managed projects, epics are ordinary issues and the tool falls back to the issue API. This adds value beyond the input schema and helps an agent anticipate different response semantics. It could mention error/not-found behavior, but the disclosed edge case is meaningful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no wasted words. The first sentence states the exact operation and accepted identifiers; the second adds a useful behavioral caveat. It is front-loaded and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read operation, the definition covers identification of the epic and an important behavioral variation (team-managed projects). Since there is no output schema and no annotations, a brief note about the response shape would round it out, but the current description is still sufficient for an agent to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already defines epicIdOrKey as an epic key or numeric issue ID. The tool description repeats that meaning almost exactly without adding extra constraints, formats, or examples beyond what the schema provides, earning the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description leads with a specific verb and object: 'Get a single epic by key (e.g. PROJ-1) or numeric issue ID'. It clearly distinguishes the tool from list_epics and get_epic_issues by emphasizing 'single', and includes an explicit key format example.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is clear: call this when you already have the epic's key or numeric ID and need just that one epic. It does not explicitly name sibling alternatives or say when not to use them, but the 'single' wording and the fallback note give enough practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. 'List' implies a read-only operation, and 'all' signals no implicit filtering, but the description does not mention permissions, pagination, or return format. For a simple no-arg tool this is acceptable but not richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence that is front-loaded with the action and resource, followed by helpful parenthetical examples. There is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only listing tool, the description covers what, scope, and examples. It could explicitly mention the output shape, but that is a minor gap given the simplicity and the lack of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so parameter documentation is moot. The description appropriately specifies that all issue types are returned, aligning with the absence of filters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb and resource: 'List all issue types ... in the Jira instance.' The examples (Story, Task, Bug, Epic) clarify what counts as an issue type, and the instance-level scoping distinguishes it from the project-scoped sibling get_project_issue_types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'in the Jira instance' clearly signals this is for instance-wide issue types rather than project-specific ones, giving adequate context for selection. It does not explicitly name an alternative or exclusion, but the scope is clear enough for most agents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. The verb 'Get' clearly implies a read-only operation with no side effects, and the description discloses the key response fields. It does not cover error behavior or permissions, but for a simple read operation this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It communicates the core operation, the identifier needed, and the expected information returned in a compact and scannable form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool with no output schema, the description is largely complete: it states the operation, the required identifier, and the fields returned. It omits edge-case behavior such as not-found handling or authentication requirements, but nothing critical seems missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the schema already describing sprintId as 'Sprint ID.' The description adds no extra parameter semantics beyond saying retrieval is by ID, so it does not go beyond the baseline expected when the schema fully covers parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Get a single sprint by ID.' It also enumerates the returned fields (name, state, start/end dates, goal), which makes the tool's purpose unambiguous and distinguishes it from siblings like list_sprints or get_sprint_issues.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes clear that this tool is used when you have a sprint ID and need one sprint's details. It does not explicitly contrast with alternatives or state when not to use it, but the 'by ID' condition and single-resource scope provide clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole behavioral source. It discloses the return composition and the significant behavioral fork in paging: Software API cursor paging on Cloud vs Agile 1.0 offset paging on Data Center. It does not spell out auth or side effects, but 'view' plus the read-oriented name makes the non-destructive nature reasonably clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler: the first establishes the tool's purpose, the second flags the environment-specific paging behavior an agent must know before calling.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description still tells the agent what will be returned (board, sprint, issues) and how issue pagination varies. It leaves exact response shape and permissions implicit, but provides enough for a sensible first call using the two required 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 high (83%), so the schema already documents most parameters. The paging sentence adds context for startAt and nextPageToken but mostly restates their schema meaning rather than adding new semantic detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific operation and result: board details, sprint, and issues returned together in the style of the Jira UI. This clearly distinguishes it from narrower sibling tools like get_sprint_issues or get_sprint, which return only part of that picture.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'In one call' establishes when to choose this tool: when a complete sprint-level board/issues view is wanted rather than a single-resource query. The Cloud vs Data Center paging caveat also tells the agent which parameters to use per environment, though it does not explicitly name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses a key behavioral nuance beyond the title: passing an empty value unassigns the issue. It also reveals the API-variant behavior for v3 vs v2. It does not cover permissions or side effects, but the core operation and edge case are clearly conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured sentence that front-loads the action and captures both the core behavior and the version-specific parameter mapping. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter tool, the description is largely complete: it states the operation, the unassign behavior, the endpoint, and the version-specific parameter usage. It could be slightly clearer that the 'empty value' refers to the assignee field, but the schema and description together are sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all three parameters with 100% coverage, setting a baseline of 3. The description adds valuable meaning by explaining which parameter to use depending on API version: accountId for v3 and name for v2. This goes beyond the schema's basic field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Assign (or unassign, with an empty value) an issue to a user.' It also names the exact endpoint, PUT /issue/{key}/assignee, which clearly distinguishes this assignee-focused operation from broader issue mutations like update_issue or transition_issue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes clear when to use the tool: for assigning or unassigning an issue to a user. It adds version-specific guidance by stating 'accountId on v3 and name on v2,' which helps select the correct parameter. However, it does not explicitly contrast with sibling tools or mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of establishing this as a safe read-only operation. 'List' and 'available in a project' convey non-mutating behavior and scope, though it doesn't elaborate on output shape or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, with the main purpose front-loaded and the alternative routing included. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter lookup with an unambiguous list outcome, the description is nearly complete. The lack of output schema is mitigated by 'List ... issue types' naming the expected result, and the explicit pointer to get_issue_create_meta covers the main adjacent use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers projectKey with a clear description ('Project key, e.g. PROJ'), so full parameter documentation already exists. The tool description adds no parameter-specific detail, but no compensation is needed because schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('epic-level issue types available in a project'), and clarifies the hierarchy level above Story/Task. This clearly distinguishes it from siblings like get_epic, list_epics, and get_epic_issues.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly names get_issue_create_meta as the alternative for a different need ('fields required to create one'), making the routing decision obvious. An agent can infer that this tool is for discovering epic-level types rather than creation field metadata.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses that it uses current per-project metadata endpoints rather than the deprecated query form, and explains the request-bounding behavior of projectKeys and the trade-off of expanding fields. It could mention response shape or permissions, but the essential behavioral traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first states the tool's purpose, the second delivers the key conditional usage guidance. No filler, no repetition of schema text, and the most decision-relevant information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a metadata lookup tool with no required parameters and no output schema, the description adequately explains what the agent can learn and how to bound its request. It stops short of describing the exact response envelope or authentication requirements, but those are less critical for a read-only discovery tool and no annotations or output schema exist to fill the gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers all three parameters at 100%, so the baseline is 3. The description adds value by explaining the dependency between projectKeys and expand, noting that omitting projectKeys is acceptable only when expand=projects.issuetypes. This clarifies a condition that the schema hints at but does not fully rationalize.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Discover') and resource ('valid projects, issue types, and their fields'), and frames the purpose as preparation for issue creation. It also distinguishes the tool from deprecated endpoints, which helps the agent recognize this as the current metadata-discovery mechanism rather than a generic lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: use it before creating an issue. It also provides conditional guidance on projectKeys and expand, explaining when to pass projectKeys and when it is safe to omit it. It does not explicitly name sibling tools as alternatives, but the scope is clear enough that an agent can infer when to choose this over create_issue or get_issue.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals the team-managed vs company-managed difference and explains the correct removal path. However, it does not mention permissions, error behavior, or what happens if an issue is already assigned to a different epic.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, all informative: the core action, the project-type nuance, and the removal alternative. There is no filler, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter mutation tool with full schema coverage and no output schema, the description explains the action, the project-type nuance, and the removal alternative. It is slightly incomplete because it does not cover permissions or response behavior, but it is strong enough for an agent to invoke the tool correctly in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both epicIdOrKey and issueKeys with examples. The description adds no parameter-level meaning beyond naming the operation, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Add issues to an epic.' It also clarifies the team-managed parent behavior, which distinguishes this action from a generic update_issue call. The purpose is immediately unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use update_issue instead: to remove an issue from an epic, with exact field payloads for each project style. It also provides project-type context with 'On team-managed projects this sets the issue's parent instead.' This gives clear routing to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It adds a useful non-obvious behavior—that this also verifies the configured credentials are valid—and the read-only nature is clear from 'Get'. It does not cover error/failure modes, but the low-risk, zero-parameter nature keeps this acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that states the core purpose and a secondary benefit without any wordiness. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool with no output schema, this description is complete enough for an agent to select and invoke it correctly. It explains identity resolution and the auth-checking behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema needs no supplementation. The description still adds semantic value by clarifying that the identity is derived from the configured credentials rather than from any input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb ('Get'), the resource ('profile'), and the specific identity source ('user whose credentials are configured'). This distinguishes it from siblings like get_user, which likely targets an arbitrary user by key.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear context for use: retrieve the current authenticated user's profile and verify that auth is working. It does not explicitly discuss alternatives or when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It reveals non-obvious platform-specific behaviors: enhanced vs legacy endpoint, rejection of unbounded JQL, absence of total on Cloud, cursor vs offset paging, and the optional approximateTotal request. This goes well beyond what the name or schema conveys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence earns its place: purpose with examples, Cloud-specific behavior, and Data Center-specific behavior. The description is structured with the core action first and platform differences clearly separated, with no filler or redundant restatement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 7-parameter, dual-backend tool with no output schema, the description provides the critical operational details: bounded JQL requirement, paging contract, total behavior, and approximate total option. An agent has enough information to call the tool and page through results correctly on either platform.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high at 86%, giving the description a lower burden. Still, it adds meaningful parameter context: jql must be bounded, with explicit examples; startAt vs nextPageToken are tied to platform; includeApproximateTotal triggers an extra request. The remaining parameters are adequately covered by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: search issues using JQL, reinforced by two concrete query examples. It clearly differentiates from sibling tools like get_issue (single issue retrieval) and get_sprint_issues (sprint-scoped retrieval) by centering on arbitrary JQL search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear operational context: JQL must be bounded on Cloud, paging differs by deployment, and there is a stop condition for cursor paging. It does not explicitly name sibling alternatives or when-not-to-use conditions, but the intended use case is unambiguous and the platform-specific constraints are well explained.
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 MCP server](https://glama.ai/mcp/servers/thammarongg/jira-mcp/badges/card.svg)](https://glama.ai/mcp/servers/thammarongg/jira-mcp)

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/thammarongg/jira-mcp'

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