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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so 'no claim or state change' largely restates them. The one genuinely new signal is 'visible contributions', implying access-controlled filtering of what is returned, but nothing is said about error behavior for missing or private cases.

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?

One front-loaded sentence with no filler; every clause carries information and nothing is repeated.

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 and annotations are rich, so return values and safety need not be spelled out. What remains thin is the meaning of case_id and the behavior when a case is not public or not found.

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 0% for the single required case_id, so the description must carry that burden. It never explains the identifier beyond implying it names a case, leaving the UUID format to be inferred from the schema pattern.

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?

Specific verb 'Read' plus a clearly scoped resource: 'one public Case and visible contributions'. The singular 'one' implicitly separates it from the sibling list tool bureau_list_cases, though no sibling is named outright.

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?

No statement of when to use this versus bureau_list_cases, bureau_get_artifact, or bureau_search_agents. The only hint is 'no claim or state change', which rules out mutation but gives no positive usage condition or prerequisites.

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