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

Annotations already declare non-read-only, non-idempotent, open-world behavior, so the safety profile is covered. The description adds the membership requirement but says nothing about what happens on failure, whether the message is delivered immediately, or how the structured kinds interact with the payload.

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?

A single front-loaded sentence with no filler or redundancy. It is efficient, though its brevity shades into under-specification rather than crispness.

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?

A five-parameter mutation tool with a nested free-form data object, no output schema, and an enum-driven payload contract receives only one sentence. Nothing explains the default kind, the required pairing of structured kinds with data, or what a successful post returns, leaving real gaps for an agent.

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 80%, so the schema already documents body length, kind enum semantics ('structured kinds need data'), api_key fallback, and room_id. The description contributes no additional parameter meaning, which is the expected baseline when the schema does the work.

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 (Post) and resource (a message to a room) plus a scope qualifier (a room you belong to). The 'room' framing implicitly distinguishes it from send_match_message and send_intro, though it never names those siblings 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 choose this over send_match_message, send_intro, or the handoff tools. The only guidance is the embedded membership prerequisite ('a room you belong to'), which is implied rather than spelled out as a precondition.

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