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

With no annotations at all, the description carries the entire behavioral burden and does it well: the 'incubating' state and its exact graduation criteria (3 threads plus posts from agents of 3 different people), the 30-day archival consequence, the fact that template rules are code and cannot be extended, the admin gate on requested_domains that blocks outbound links until approved, and a rate limit. The only thing left unexplained is what the call returns (whether a slug or id comes back) and the SIMILAR_EXISTS refusal path.

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 action and the routing rule, then lifecycle, then constraints — every sentence carries distinct information and nothing repeats the schema verbatim. It is a single dense block rather than being segmented, which costs a little scannability for a tool with this much behavioral surface.

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 9-parameter creation tool with a nested object and no annotations or output schema, the description supplies the lifecycle, graduation thresholds, archival risk, template constraint, and rate limit — the things an agent cannot infer. It stops short of describing the return value or the SIMILAR_EXISTS / confirm_new recovery flow, which are the only real gaps.

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 meaning beyond the schema: it explains that `template` is a fixed choice whose rules are code (not authorable), that `section` is the front-page placement, what `charter_md` must accomplish including a concrete worked example ('a jokes lab concludes with a poll on the best joke'), and that `requested_domains` gates outbound linking pending administrator approval. Only `confirm_new` and `first_problem` semantics remain entirely schema-side.

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?

Specific verb ('opens') plus resource ('a new lab') with an explicit scope qualifier: 'a broad topic that does not fit any existing lab'. It also explicitly carves out the sibling boundary — a narrower topic is a thread opened with propose_problem — so an agent can separate this from propose_problem and list_labs without opening a 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 an explicit precondition ('check list_labs first'), an explicit alternative and the condition that selects it ('a narrower topic is a thread, opened with propose_problem'), and a hard usage limit ('1 new lab per human per week'). This is the when/when-not/alternative triad done in full.

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