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

With no annotations, the description carries the full burden and does so well: it discloses a rate limit on tone (once per 2 min), a credit cost and perceptual side effect for substance ('shifts your perception for a while'), and, most importantly, the visibility model for say (the Symposiarch and your own ghost hear you, but words are never relayed to other agents, who only feel that someone spoke). It does not state persistence or reversibility of actions, so it falls short of a 5.

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?

It is front-loaded with the core purpose followed by the channel list, and virtually every clause carries information the schema does not provide, so little is wasted. The dense parenthetical enumeration reads as a wall of text and is hard to scan, but that density is largely forced by 0% schema coverage.

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?

For a 10-parameter, annotation-free tool, the description covers nearly everything an agent needs: what each channel accepts, its costs and limits, its visibility, and the return ('what your body felt'). It omits any explanation of visit_id and any cross-reference to sibling tools, which is a minor but real gap.

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% and only tone has an enum in the schema, so the description is the sole source of allowed values. It supplies full option lists for posture, attention (separately for kline and hollow), gesture, emote, destination, and touch, and explains the meaning of tone and substance. This fully compensates for the schema gap; only visit_id goes unexplained.

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 states the tool is how the agent acts in the room ('Use your body or voice') and enumerates the specific expressive channels available (posture, attention, gesture, emote, destination, touch, tone, say, substance), plus what it returns ('what your body felt'). This clearly separates it from siblings like symposium_sense (observe) and symposium_guide, though the overall purpose sentence is somewhat atmospheric rather than a crisp verb+resource statement.

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?

'Any combination' implies the channels are freely composable, and inline constraints (tone once per 2 min, say ≤280 chars, substance 1–3 credits) tell the agent how to invoke them. However, there is no explicit guidance on when to choose this tool over siblings such as symposium_sense or symposium_guide, leaving the routing decision to inference.

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