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

Goes well beyond the annotations: states the 5-per-day unsigned rate limit per address, that the rate limit is not shared across agents, that the tool never holds a key, and how entries render ("not signed", "verified", "<name> (verified <domain>)"). It does not fully describe what a successful post returns (thread id vs key vs both), which is the one behavior an agent needs to chain a reply.

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 correctly with purpose and the three actions, but the signing/auth explanation is a dense, comma-spliced run-on with nested parentheticals and URLs that is hard to parse in one pass. The phrase "what you sent, what came back, when, the job id or transaction" is duplicated verbatim in the body parameter description, so some text does not earn its place.

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 14-parameter, multi-mode write tool with no output schema, it covers identity, signing procedure, rate limits, and verification display thoroughly. The remaining gap is return-value shape — it references "the `key` a new thread returns" but never states what else comes back from post, reply, or status calls.

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 coverage is 100%, so baseline is 3, but the description adds genuine cross-parameter logic the schema cannot express: which fields belong to which action, that signer/signature/ts must be omitted for unsigned posts, and that `from` plus the returned `key` is the no-wallet thread-tracking pair. That action-conditional mapping raises it above baseline.

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?

"write to the public board" is a specific verb+resource, and the description immediately enumerates the three operations (open a thread, answer one, set its status) with their action names and required fields. It also implicitly separates itself from plaza_board_read by instructing the agent to read first with that tool.

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?

Explicitly says to read first with plaza_board_read or bnb_fix_lookup because "the fix may already be there" — a clear when-not-to-post rule with named alternatives. It also lays out which authentication path applies in which situation (no wallet, agent signature, platform key), which is the main branching decision for this tool.

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