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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds real context beyond that: what the check reports (site counts, flanking vs. internal classification) and why it matters (internal sites mis-cut the part), which is the diagnostic semantics an agent needs to interpret results.

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 sentence, front-loaded with the timing constraint and followed by the three things the check reports. No filler, no restatement of the tool name.

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?

An output schema exists and all five parameters are documented, so the description only needs to frame intent and scope, which it does. Minor gaps remain around how non-library parts and the _files/_subject context are resolved, but nothing blocks correct invocation.

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% and the nested _subject/_files plumbing is documented in-schema, so the baseline is 3. The prose adds only the notion of an enzyme-driven Type-IIS check and says nothing about the selectable "enzyme" parameter (BsaI default) or when to set "include_subject", leaving those to the schema.

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 gives a specific verb (check) plus resource (parts) and even the output's content: per-part recognition site counts, the two deliberate flanking sites, and internal sites. That distinguishes it well from golden_gate_assemble (which performs the assembly) and from generic restriction-site tools, though it never names a sibling 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?

"Check parts BEFORE a Type-IIS assembly" is a clear, actionable usage trigger embedded in the first clause. It lacks explicit exclusions or named alternatives (e.g., design_split_sites, domesticate_part, scrub_restriction_sites) that would help an agent reroute when parts fail the check.

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