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

Annotations already indicate non-read-only (readOnlyHint: false) and idempotent (idempotentHint: true), so the description isn't the sole carrier of safety info. It adds that the conversation array is needed for reproduction, implying data will be transmitted, but it doesn't explain side effects, persistence, or confirmation. This adds some context but leaves behavioral gaps.

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 description is two sentences: first states the purpose, second gives a specific instruction. No redundant content, front-loaded with action, and efficient.

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?

The tool is simple, but the description omits parameter details and doesn't mention any return behavior or confirmation. Given there's no output schema and annotations are minimal, the description could be more complete, especially for a tool that likely sends data. It's adequate for a basic bug-report tool but leaves gaps.

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%, so the description should explain each parameter. It only mentions the 'conversation array' (corresponding to the 'conversation' parameter), leaving 'message' and 'context' unexplained. The required 'message' parameter, the core input, lacks any description of its format or role. This is a significant gap.

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 clearly states the tool's action: report a bug, missing feature, or send feedback. It also instructs to include the conversation array for reproduction, which reinforces the purpose. Sibling tools like authenticate or connect are unrelated, so there's no ambiguity.

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?

The description explicitly mentions the scenarios (bug, missing feature, feedback) and provides a guideline to include the conversation array for reproduction. While it doesn't list exclusions or alternatives, the sibling set makes the appropriate usage obvious, so the context is clear.

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