Export a partial Logisim netlist

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds meaningful behavioral traits: 'coordinate-endpoint nets with explicit loss markers' and the explicit non-inference of geometry/junctions/behavior. This goes beyond the annotations and gives the user a clear picture of what the output will and won't contain. No contradiction with annotations.

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?

Two concise sentences with no fluff. The first sentence states the action and the second clarifies limitations. Information is front-loaded, and every word earns its place. Perfectly sized for the tool's complexity.

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?

With an output schema present, the description needn't detail return values. It covers the core semantics (coordinate-endpoint nets, loss markers, non-inference) and limitations. It could elaborate on pagination behavior or the purpose of expectedProjectDigest, but these are either inferable or present in the schema. Given the tool's moderate complexity, the description is nearly complete but not exhaustive.

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 60%, covering path, circuit, and expectedProjectDigest, but limit and cursor lack descriptions. The tool description adds no parameter-specific details, so it doesn't compensate for the gaps. However, the parameter names (limit, cursor) are self-explanatory, and the title's 'partial' hints at pagination. The schema plus implicit naming provide a baseline understanding, so a 3 is appropriate.

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 clearly states the tool exports simulator-neutral coordinate-endpoint nets with loss markers, which is a specific verb+resource. It also distinguishes itself by noting what it does not infer (gate geometry, mid-segment junctions, behavior), giving it a defined scope beyond a generic export. However, it doesn't explicitly name sibling alternatives, so it falls short of a 5.

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?

The description implies usage through its limitations: 'does not infer unmodeled gate geometry, mid-segment junctions, or behavior' tells the user this is for partial netlists only. It provides useful context but does not explicitly say when to use this tool versus alternatives like crumb_export_netlist, nor does it state exclusions. This is adequate but lacks clear guidance.

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