jira_get_board_issues

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

With no annotations provided, the description carries the full behavioral burden. It discloses that the return is a JSON string containing search results plus pagination info, which is genuinely useful, but it says nothing about auth requirements, rate limits, or read-only nature (the latter is only implied by 'Get').

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?

The purpose sentence is front-loaded and effective, but the Args and Returns boilerplate largely duplicates the schema and output schema, adding bulk without new information. It is adequately sized but not tight.

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?

An output schema exists, so explaining return values was not strictly necessary (though it does). For a 6-parameter, read-only query tool this covers the mechanics, but the absence of any usage or alternative-tool guidance leaves a meaningful gap for an agent choosing among the many Jira search/list siblings.

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 coverage is 100%, so the schema already documents every parameter, including JQL examples, field enumerations, and default values that the description does not repeat. The description's Args block merely restates parameter names with terse glosses, adding no meaning beyond the schema. This matches the baseline 3 for high coverage.

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 states a specific verb and resource: 'Get all issues linked to a specific board filtered by JQL.' The board scoping is clear and implicitly distinguishes it from sibling tools like jira_get_project_issues or jira_get_sprint_issues, but it never names those alternatives explicitly, so the differentiation is left to the agent's inference.

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 when-to-use guidance, no prerequisites, and no mention of when to prefer jira_search, jira_get_project_issues, or jira_get_sprint_issues instead. The only contextual signal is the phrase 'specific board,' which implies a scope but provides no routing guidance.

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