dpar_create

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

With no annotations provided, the description carries the full burden, and it delivers: it discloses that IC-CAP has no direct DPar constructor, that parameters materialize from $dpar declarations, that circuit='model' affects every DUT while circuit='dut' is DUT Test Circuit only, that prior declarations are replaced, and that parameters are verified after writing. This is thorough behavioral disclosure for a mutation tool.

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?

The description is economically written: core purpose first, then mechanism, then behavior details, then prerequisite and verification. Every sentence adds necessary information and there is no filler or repetition of schema content.

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 tool with no output schema and no annotations, the description covers the creation mechanism, circuit semantics, overwrite behavior, post-write verification, and the DUT prerequisite. The only minor gap is lack of explicit return-value or error behavior, but since the tool performs side effects and verifies internally, the description is sufficiently complete for an agent to invoke it 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?

Schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining what 'circuit' actually means semantically ('model' appears in every DUT's parameter set vs 'dut' DUT Test Circuit only) and how parameters come into existence. Param names/values are already well covered by schema examples.

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 verb and resource: 'Create DUT parameters by declaring them in a circuit page.' It also explains the distinctive mechanism ($dpar declarations) and explicitly distinguishes creation from checking by pointing to dpar_exists/dpar_get for verification, so an agent can tell it apart from related siblings like dpar_set or dpar_get.

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 provides useful context: which circuit page receives declarations, default behavior for 'model', the prerequisite that the DUT must exist, and a pointer to verify with dpar_exists/dpar_get. However, it never explicitly contrasts this tool with alternatives such as dpar_set for modifying existing parameters or says when not to use it; the usage guidance is implied rather than explicit.

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