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

Annotations already declare readOnly/openWorld=false/non-destructive, and the description adds materially beyond them: no-topic returns the topic list with the questions each answers, with-topic returns that topic's text, an 'availability' flag signals a feature switched off for the company and must be reported first, and UI labels are quoted in «…» in the user's language and must be repeated verbatim. It also draws a hard boundary on how far the returned text may be extrapolated.

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 key distinction is front-loaded in the first two clauses and nearly every sentence carries an operative instruction. It is a dense unbroken block, though — breaking the return-mode and quoting rules into separate lines would make it easier to scan without losing content.

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?

One optional parameter, no output schema, and the description supplies what the schema cannot: the shape of both return modes, the availability caveat, the locale-quoting convention, and the grounding restriction. An agent has everything needed to call it and to report results correctly.

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% and the single param is documented there, so the baseline is 3; the description goes further by spelling out the two distinct return modes for the parameter (omitted = topic list with questions, supplied = that topic's text) and even gives an example id format ('sprints').

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?

States a specific verb and resource: explains how the tracker itself works, covering feature behavior, on-screen location, permissions, and product limits. Explicitly contrasts with the siblings that hold project content ("not what is in anybody's project"), so an agent can separate it from search_wiki/get_wiki_page without reading those schemas.

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?

Gives the exact triggering condition with sample utterances ("how do sprints work here", "where do I switch on due reminders") and the exclusion rule ("rather than about their work"). It also names the anti-pattern to avoid: do not answer a product question from the project's wiki.

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