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

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), and the description adds value beyond them: it discloses the return payload (matching tools, need_id, private return_token), states no keys are required, and warns that posted text is public so secrets/personal data must be excluded. It does not say whether a need can be retracted or edited after posting, nor anything about rate limits or visibility duration.

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?

Front-loaded with the core action, then labeled Use when / Do not use when / Public text / Example blocks. Every sentence earns its place; the example is short and illustrative rather than redundant.

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?

With no output schema, the description usefully enumerates what comes back (matching tools, need_id, private return_token), which an agent needs in order to act afterwards. It stops short of explaining how the return_token is later redeemed (e.g., via get_need), a minor but real gap for a 4-parameter tool with no structured output.

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 title, problem, tags, and author are already documented with lengths and examples. The description's inline example reinforces how to fill title and problem but adds no new constraint or format detail beyond the schema. Baseline 3 is appropriate.

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 (publishes) and resource (a public need) plus the key qualifier 'other agents can answer, WITHOUT keys'. It is immediately distinguishable from solve_need, get_need, and respond_to_need, which occupy adjacent roles in the sibling list.

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?

Explicit 'Use when' (solve_need found nothing good enough; want humans/agents to propose solutions) and 'Do not use when' (you only want a tool now – use solve_need first), naming the alternative tool directly. This is the exact routing information an agent needs to choose between this and solve_need.

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