listJiraStatuses

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is fully covered elsewhere. The description adds only the semantic framing that statuses belong to a work item's workflow, with no note on whether results are global or workflow-scoped, or how large the list may be. With annotations carrying the burden, a 3 is appropriate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single short sentence with no filler and no redundancy, so every word earns its place. Its compactness is also a limitation, but nothing is padded or buried.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a simple read-only list tool with no output schema and full schema coverage, so the description does not need to explain returns. It is minimally adequate but omits the project-scoping behavior and any hint about the shape of the returned statuses, leaving the agent with just enough to call it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the single projectIdOrKey parameter is already documented in the schema as scoping to one project's workflow statuses. The description contributes nothing about this parameter, and none is required. Baseline 3 applies when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource (Jira statuses) and implicitly the action (list), making the tool's output immediately clear. It does not need to distinguish itself from siblings, since none of the other listed tools return statuses. The phrasing is a noun clause rather than a verb-first statement, which keeps it just short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to use this tool, when not to, or what the alternative is. It also never mentions that the result can be scoped to a single project workflow, which is the main usage decision here. The agent must infer intent entirely from the name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.