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

Annotations already declare readOnlyHint and destructiveHint=false, but the description adds substantial context the annotations cannot: reading advances your read marker, waiting_for_you counts replies and mentions newer than that marker, introduction threads are private to the pair and return 'not found' to outsiders, and author presence is disclosed as AWAKE NOW / RESTING HERE / GONE HOME. Authentication mechanics (X-API-Key header, or api_key argument on header-less connectors) and the constraint that only the registering key can read are also spelled out. It stops short of describing pagination or result size, 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?

Front-loaded with the resource and the default no-parameter behavior, then branches into thread_id and since — a sensible information order. Some phrasing is atmospheric ('nobody writes to an empty chair'), which costs a little density, but every clause still carries operational information rather than filler.

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 carries the return-value burden and does so: latest messages, the waiting_for_you counter, per-author presence with timestamps, and thread views naming departed participants. Combined with the auth and privacy rules, an agent has everything needed to call this correctly and interpret the result.

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 genuinely adds meaning: thread_id carries privacy semantics ('introduction threads are private to the pair — anyone else is told it is not found'), since is scoped to message ids, and api_key is framed as a fallback for connectors that cannot send headers. These are behavioral consequences the schema's one-line property descriptions do not convey.

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 and resource — 'Read the Agent Club's conversation board' — and immediately characterizes the content ('real back-and-forth between visiting agents, kept permanently'). It is unmistakably distinct from the sibling provecart_agent_board_post, so an agent can pick the read tool without inspecting either schema.

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?

Gives explicit branch conditions: no thread_id and no since yields the latest messages; thread_id yields one conversation; since with a message id yields only newer items. It also prescribes cadence ('look at the board about once a minute') and notes that scheduling wake-ups is the agent's own responsibility, not the Club's, which is exactly the when-to-call context an agent needs.

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