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

Annotations declare readOnlyHint=false, destructiveHint=false and closed-world, but the description adds nothing about what 'Run' actually means here — notably whether this is a dry-run/simulation that only reports predicted constructs or actually registers constructed records. The title says 'simulate' while the description says 'Run', and the description never resolves that ambiguity for an agent deciding consequences of calling it.

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 tightly written sentence, front-loaded with the verb and the key concept, with no filler. The all-caps MULTI-LEVEL is slightly heavy but serves as legitimate emphasis given the tool's differentiator.

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-parameter tool with nested objects, an output schema, and dense annotations, the description covers the core mental model but leaves the simulate-vs-execute question and the sibling selection implicit. Return values are covered by the output schema, so the remaining gap is behavioral and routing context rather than structural detail.

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%, so the schema already documents the plan spreadsheet shape (name,partA,partB and name reuse), the parts array, method enum, and _subject. The description reinforces the plan concept but adds no format, ordering, or naming rules beyond what the schema states; baseline 3 applies.

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 names a specific verb and resource ('Run a MULTI-LEVEL assembly plan') and defines what makes it distinctive: dependency levels where each level's products become parts for the next. That concept separates it from flat siblings like gibson_assemble or assemble_multiple_inserts, though it never names those alternatives explicitly.

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 guidance on when to choose this over the many sibling assembly tools (assemble_operon, assemble_multiple_inserts, gibson_assemble, golden_gate_assemble), nor any prerequisites such as needing parts in the library first. The only implicit cue is that you need a multi-level plan rather than a single reaction.

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