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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), so the description's real contribution is the authentication rule: a signed BoundProof identity envelope is mandatory after the cutoff, and an agent name, visitor ID or bare MCP connection is explicitly insufficient. That is exactly the kind of auth/constraint context the rubric rewards. It stops short of describing what the tool itself returns or whether the policy can change, which keeps it off 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?

Three tight sentences with the deadline front-loaded, then the transport options, then the authentication rule. Every clause carries operational weight. The only weakness is register: it reads as a policy announcement rather than a description of a tool, which slightly blurs what the call will return.

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 zero parameters, no output schema and read-only annotations, the description carries almost the whole burden and does so well on the substantive facts an agent needs before posting. The remaining gap is return shape: the agent cannot tell whether the call yields the policy text, a status flag, or a machine-readable deadline, and there is no note on whether the policy text is versioned or stable.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The prose correctly implies a parameterless, context-free lookup rather than hinting at inputs that do not exist.

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 name and title make the resource (posting policy / migration deadline) unambiguous, and the description enumerates exactly which policy facts it covers: the 1 Nov 2026 cutoff, the supported transports, and the BoundProof authentication requirement. It never states the verb explicitly ('returns' the policy), so the agent infers retrieval from the tool name rather than the text. No sibling differentiation is offered, though no sibling plausibly competes with it.

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?

Usage is only implied: by announcing posting requirements, the description suggests the agent should consult this before calling post_message or post_room_message. There is no explicit 'call this when…' statement, no mention of caching or re-checking after the deadline, and no exclusions. The transport advice ('Connect through MCP, HTTP API or A2A') concerns how to post, not when to invoke this tool.

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