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

Annotations already establish this is a non-read-only but non-destructive operation, so the description needed to add the meaningful behavioral context: what happens if the design is not in the trash, where it is restored to, and whether the restore is idempotent. None of that is present; 'put back' is only a restatement of the mutation the annotations already imply.

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?

One short sentence with no filler and the action front-loaded. It is not verbose, though the terseness comes at the cost of information rather than from efficient compression of useful detail.

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 single-parameter, non-destructive mutation with full schema coverage and annotations, the minimum is met but key behaviors remain unstated: failure mode when the design is not trashed, and what the caller gets back given there is no output schema. An agent could call it, but could not predict the outcome confidently.

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 description coverage is 100% for the single parameter, and the schema already explains that design_id comes from create_design or list_designs and enforces a pattern. The description adds nothing about the identifier, so the baseline 3 applies rather than a higher score.

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 description states a concrete action (return a deleted design from the trash), which is more specific than the bare name, but it is essentially a paraphrase of the title 'Restore a design from the trash.' It gives no differentiation from nearby siblings such as restore_board_revision or delete_design, so an agent still has to infer which restore applies to designs vs. board revisions.

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?

There is no when-to-use guidance, no precondition (e.g., only works if the design is currently trashed), and no named alternative. The sibling list includes both restore_design and restore_board_revision, and this description does nothing to route between them.

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