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

Annotations already flag destructiveHint=true and readOnlyHint=false, but the description adds material context beyond them: it discloses that archiving is reversible ('false brings it back'), which softens the destructive flag, and notes the governance model ('no approval card, every change attributed'). Still silent on auth requirements or rate limits, so not 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 sentences, front-loaded with the verb and the field list, with the operational detail (archive semantics) in the middle and provenance last. The parenthetical about archiving is dense but earns its place; slightly overstuffed for a single tool but no wasted sentences.

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 6-param mutation with no output schema, the description covers mutation semantics, reversibility, id provenance, and governance. The only gap is the workspace parameter, which the description ignores but the schema documents, so an agent has what it needs to call correctly.

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?

At 50% schema coverage the description has to carry weight, and it does: it explains the semantics of name, description, visibility, and archived, plus the id provenance (napkin_boards_list). Only the workspace parameter is left entirely to the schema, so it adds real value over structured fields.

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 (edits) and resource (board details) and enumerates exactly which fields can change: name, description, visibility, archived. This separates it cleanly from the napkin_boards_create/get/list/view siblings without the agent needing to open any 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?

Usage is implied rather than stated: the archived-field explanation gives a clear scenario ('recovery move for a board you created by mistake') and 'Board ids come from napkin_boards_list' supplies the prerequisite. But there is no explicit when-to-use/when-not-to-use statement or named alternative tool, so guidance remains inferred.

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