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

With no annotations, the description carries the full load and does reasonably well: it enumerates the four validation classes and frames the tool as a blocking gate. It leaves implicit that the operation is read-only and non-mutating, and says nothing about failure reporting, but the output schema absorbs the return-value burden.

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 sentences, dense and front-loaded: the validation criteria come first, then the required-action precondition. No filler whatsoever.

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 validation gate with an output schema present, the description supplies the necessary criteria and the handoff precondition. The only real hole is the meaning of the 'file' input, which a one-clause note would have closed.

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?

The single 'file' parameter has 0% schema description coverage, so the description must compensate and does not. It never says whether 'file' is a filesystem path, a sketch name, or an ID, nor what format is expected.

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?

States a specific verb (Validate) and resource (a sketch) and enumerates the exact invariants checked, which separates it from the sibling fritzing_validate_part. An agent can tell immediately this is the whole-sketch gate, not a per-part check.

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?

"MUST pass before handing a design off or opening it in the GUI" gives a concrete precondition that pairs with the sibling fritzing_open_gui. It stops short of explicitly naming sibling alternatives or stating what to do on failure, so it is clear context rather than a full when/when-not rule.

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

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

With no annotations, the description must carry the behavioral load, and it does disclose the two most important traits: the exact output artifacts and the restart/scanned-at-startup caveat for install. It omits matters like whether existing parts are overwritten, error behavior on a malformed spec, or permission requirements, so it is useful but not complete.

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 sentences, zero filler, with the core action front-loaded and the caveat second. Every clause earns its place.

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 so return values need not be explained, and the description covers the generation action plus the key install lifecycle gotcha. It is close to sufficient for a 3-parameter generation tool, only lacking conflict/overwrite semantics.

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 all three parameters (spec_path, out, install) are already documented in the schema; baseline is 3. The description adds only marginal meaning, hinting at the --install flow and referencing the JSON spec the schema already points to.

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?

States a precise verb and resource ('Generate a custom part') and enumerates the concrete artifacts produced (fzp + 4 view SVGs) from a JSON spec. This clearly separates it from siblings like fritzing_validate_part or fritzing_place_part, though it never names an alternative 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?

The second sentence gives a real lifecycle rule (all 4 views required; restart Fritzing after --install because parts are scanned at startup), which is actionable usage context. However, it never says when to reach for this tool versus validate_part or set_properties, so 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.

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

No annotations exist, so the description carries the full burden. It usefully discloses the dual read/move mode, but says nothing about whether the change persists to the file (the 'file' param implies mutation), what happens on invalid ref, or whether coordinates are absolute relative to the sketch origin.

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 plus a parenthetical, with the action front-loaded and zero filler. Every clause earns its place.

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, so return values need not be explained. But for a 4-parameter mutation tool with no annotations, the undefined 'ref'/'file' semantics and unclear persistence behavior leave gaps an agent would need to resolve.

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 0% and the description only explains x and y (omit both to read); it says nothing about 'ref' or 'file' semantics, units, or coordinate origin. Two of four parameters remain entirely undocumented for an agent.

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?

States a specific verb ('Move') and resource ('a placed instance'), and the parenthetical clarifies the read-mode behavior. It does not explicitly differentiate from the sibling fritzing_place_part, so an agent must infer the new-vs-existing distinction.

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 parenthetical 'omit x/y to read its current position' gives a clear conditional for one mode, which is real usage guidance. However, there is no guidance on when to use this versus fritzing_place_part or fritzing_set_properties, both plausible siblings for changing a part's state.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. 'Empty' is useful context about the resulting sketch, but it says nothing about overwrite behavior (which the undocumented 'force' parameter implies), what happens if the path already exists, or filesystem/auth requirements.

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 single sentence is appropriately short and front-loaded, but its brevity here comes at the cost of under-specification rather than genuine economy. It is neither wasteful nor adequately informative.

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, so return values need not be explained. However, for a file-creating tool with an undocumented 'force' flag and no annotations, the description should clarify overwrite behavior and basic usage context. As written it leaves key agent-relevant questions unanswered.

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 only 50%: 'path' is documented in the schema, but 'force' has no description anywhere. The description adds no parameter meaning at all, so it fails to compensate for the coverage gap on the one undocumented parameter that clearly governs overwrite semantics.

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 specific verb and resource ('Create an empty Fritzing sketch bundle'), which is clear and distinct from siblings like fritzing_check, fritzing_render, or fritzing_create_part. It does not explicitly differentiate itself from other creation-oriented tools, but in practice it is the only sketch-creating tool in the sibling set.

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 or when-not-to-use guidance at all. The description does not say when an agent should create a fresh sketch versus opening or modifying an existing one, nor does it mention any prerequisites.

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

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

No annotations are provided, so the description carries the full burden. Saying it opens a GUI hints at a side effect on the host (spawning an application window) and that it's non-destructive, which is real behavioral value. But it does not disclose whether the call blocks until the window closes, whether it requires Fritzing to be installed/launched, or what happens on failure.

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, front-loaded with the verb and resource, with zero filler. Nothing about it is padded or restated from the title.

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, so return values need not be explained. But this is a side-effecting tool with no annotations in a 14-sibling family containing several visually overlapping names, and the description resolves none of that ambiguity nor states GUI/launch preconditions.

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% with a single 'files' array parameter documented as 'sketch paths to open'. The description adds no further parameter meaning (format of the paths, relative vs absolute, one vs many windows). Baseline 3 applies when the schema does the heavy lifting.

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?

Specific verb+resource+destination: 'Open sketch(es) in the Fritzing GUI for human review.' An agent immediately understands this launches a visual editor session rather than mutating files. However, it does not differentiate itself from nearby siblings like fritzing_show_sketch or fritzing_render, which sound like they also surface sketches visually.

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?

'for human review' implies the intended context (a human wants to inspect output interactively), which is useful implied guidance. But there is no explicit when-to-use vs when-not, no statement of prerequisites (e.g., a GUI/display must exist), and no routing to the visual-but-non-GUI siblings.

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

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

No annotations are provided, so the description carries the full burden. 'List' implies a safe read operation and the description states the return is JSON with connector fields, but it does not explicitly confirm read-only behavior, permissions, or side effects.

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 two short sentences that are front-loaded with the tool's function. The second sentence earns its place by clarifying how connector ids are used in wiring, and there is no wasted text.

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, so the description need not explain return values in detail. For a simple one-parameter read tool, it sufficiently covers what is listed and why connector ids matter, though it could add a brief note on when to call it.

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 sole parameter module_id is already well documented in the schema as coming from fritzing_search_parts. The description adds no additional syntax or meaning for the parameter itself, so the baseline 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 states a specific verb (List) and resource (a part's connector ids, names, and types), making the tool's operation immediately clear. It does not explicitly differentiate itself from sibling tools such as fritzing_wire or fritzing_search_parts, so it falls just 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 note that connector ids are what wire endpoints reference implies the tool is useful before wiring, but there is no explicit when-to-use guidance, no when-not-to-use guidance, and no named alternatives. Usage is inferable but not directly stated.

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

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

With no annotations provided, the description carries the full burden. It usefully discloses the coordinate system (90 DPI with an mm->px formula) and that the assigned ref comes back in the output, but says nothing about whether the sketch is persisted to disk, what happens if the file or module_id is invalid, or whether the operation is reversible.

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?

Three compact sentences with the core action front-loaded, followed by the two facts an agent actually needs (coordinate units and ref reuse). No filler.

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 so return values need no explanation, and the description covers the main gotcha (pixel units). However, for a 7-parameter mutation tool with 43% schema coverage and no annotations, it omits how to obtain module_id, the meaning of view, and the persistence/error behavior.

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 43%, so the description must compensate and only partly does: it explains x/y units and the significance of the returned ref. It leaves module_id (required, where to find it), props, and the file/view interaction undocumented in both places.

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?

States a specific verb and resource: 'Add a part instance to a sketch.' An agent can distinguish it from move/remove siblings by the placement verb, though the description never names an alternative to reinforce that distinction.

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?

Usage is only implied through the workflow hint 'use it for wire/move/props,' which tells the agent what to do after placing. There is no explicit when-to-use guidance versus fritzing_create_part, fritzing_search_parts, or fritzing_move_part, and no stated prerequisites such as needing an existing sketch file.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it delivers almost nothing. It implies a mutating, potentially destructive operation but does not disclose whether wires/connections attached to the part are also removed, whether the action is reversible, or what happens if the ref does not exist.

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?

It is a single short sentence with no waste and no padding, but its brevity comes from under-specification rather than discipline. Nothing is front-loaded because there is nothing else to order.

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, so return values need not be explained, but for a two-parameter mutation tool with zero annotation coverage and undocumented parameters the description is far too thin. It omits prerequisites, side effects on surrounding wiring, and identification of the target instance.

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 0%, so the schema documents neither parameter, and the description says nothing about 'file' or 'ref'. The agent must guess that 'ref' identifies the instance to remove and what format it takes; the description does not compensate for the coverage gap.

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 clear verb ('Remove') and a resource ('an instance from the sketch'), but it never explains what an 'instance' or a 'ref' is, and the terminology diverges from siblings like fritzing_place_part and fritzing_move_part that operate on parts. It stops short of differentiating this tool from its near-siblings.

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 prerequisites, and no mention of alternatives such as fritzing_set_properties or fritzing_move_part. The agent must infer everything from the tool name alone.

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

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

With no annotations, the description carries the full burden and does well: it discloses the file-writing side effect, the <name>_<view> output naming convention, the optional ImageMagick dependency for PNG, and the ~10 s first-render parts-DB load. It omits failure behavior and whether existing files are overwritten.

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 compact sentences, front-loaded with what the tool produces, followed by the side effect and latency warning. No filler.

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 so return values need no explanation, and the description adds the key operational facts (output location, latency, dependency). Only the density parameter's meaning is left entirely to the schema.

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 coverage is 50%. The description explains the PNG option (ImageMagick dependency) and indirectly the view via the <name>_<view> filename, but says nothing about density or accepted values, so it does not fully compensate for the coverage gap. Baseline 3 fits.

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?

States a specific verb (headless-render) and resource (sketch/es) plus the exact output artifacts (SVG, and optionally PNG). This clearly separates it from GUI-oriented siblings like fritzing_show_sketch or mutation tools like fritzing_move_part.

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?

It describes the intended workflow loop: render, read the PNG to inspect the design, adjust positions/wires, re-render. That gives clear context for when to reach for it, but it never names an alternative sibling or states when not to use it.

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

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

With no annotations, the description carries the full burden and does well: it discloses the return row format ('moduleId title [family] (source)'), the scope of the corpus, and a mandatory downstream call before wiring. It does not state read-only semantics or behavior when the query matches nothing, but a search tool's safety profile is self-evident.

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 short sentences, front-loaded with purpose, with the corpus size and the next-step instruction each earning their place. No filler.

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, so return-value explanation is not required, and the description still sketches the row shape. The only meaningful gap is the undocumented limit/verbose parameters, which leaves result-volume control ambiguous.

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 coverage is only 33% – only 'query' is documented in the schema, and limit (default 40) and verbose (default false) are undocumented everywhere. The description adds no meaning for limit or verbose despite the coverage gap, so an agent must guess at result-set sizing and verbosity behavior.

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?

States a specific verb (Search) and resource (Fritzing parts library), quantifies scope (2663 core parts + local custom parts), and returns a named result row shape. An agent can distinguish it from fritzing_part_connectors and fritzing_validate_part without opening a schema.

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?

Explicitly routes the agent to the next step: 'Call fritzing_part_connectors with a result's moduleId before wiring it.' That is real when-to-use guidance, though it does not state when to skip search (e.g. when a moduleId is already known) or discuss the limit parameter as a pagination strategy.

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

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

No annotations are provided, so the description carries the full behavioral burden. It signals a mutation with name=value pairs, but it does not disclose whether existing properties are overwritten, whether the file is modified, required permissions, or error behavior. This is insufficient for a write 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 single fragment is terse with no waste and is front-loaded with the verb, but for a three-parameter mutation tool it is under-specified rather than appropriately sized. It provides no structure beyond the bare action.

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, so return values need not be explained. However, with no annotations, 33% schema coverage, and a nested props object, the description leaves major gaps: file and ref semantics, when to use the tool, and overwrite behavior are all missing.

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 only 33%: only the props parameter has a description. The description adds 'name=value pairs' but does not explain the file parameter, the ref parameter, or expected property keys beyond what the schema already states.

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 uses a specific verb ('Set') and resource ('instance properties') and specifies the value format ('name=value pairs'). It is clear what the operation does, but it does not differentiate from sibling tools such as fritzing_place_part or fritzing_create_part, and it leaves 'instance' undefined.

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 use this tool versus alternatives, no mention of prerequisites such as a valid file or ref, and no context about when setting properties is appropriate. It only states the operation.

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

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

With no annotations, the description carries the whole behavioral burden. 'Dump' weakly implies a read, and it discloses the return format (JSON) and payload, but says nothing about side effects, whether the file must exist/be open in the GUI, or any permissions. Too thin for a no-annotation 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?

One tight sentence with the verb and payload front-loaded and no wasted words. Efficient, though its brevity contributes to the missing usage and parameter 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?

An output schema exists, so return values need not be re-explained, and the description does summarize them. However, with an undocumented parameter and no usage or prerequisite context, it is only minimally complete.

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?

The single 'file' parameter has 0% schema description coverage, so the description must compensate. It says nothing about what the file argument is (path? filename? format?) beyond the implicit connection to 'the sketch'.

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?

Specific verb ('Dump') plus resource ('sketch's instances') and it enumerates the payload contents (refs, moduleIds, positions, wires). It reads clearly as a read/inspect operation versus the mutation siblings (move_part, place_part, remove_part), 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?

No when-to-use guidance and no alternatives referenced. The agent can infer it is for inspecting a sketch, but nothing states when this is preferable to fritzing_check, fritzing_render, or the other read tools.

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

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

No annotations are provided, so the description carries the full burden. It does not say what validation is performed, whether the operation is read-only, what errors it surfaces, or whether it mutates the file.

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 single sentence is front-loaded and free of waste, but it is under-specified rather than genuinely concise for a tool whose schema and annotations add nothing.

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, so return values need not be explained, but with no annotations and 0% parameter coverage the description leaves the agent without enough to invoke the tool 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 0% and the single parameter fzp_path is undocumented. The description implies it is a file path but adds no format, relative-vs-absolute, or expected-location detail to compensate.

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?

States a specific verb (validate) and resource (.fzp part definition file), which is clear on its own. It does not, however, distinguish itself from the sibling fritzing_check, leaving overlap ambiguous.

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 use this tool versus fritzing_check or the other validation-adjacent siblings. No preconditions or context are given.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the key behavioral fact that this creates a persistent electrical <connect> element, implying a sketch mutation, but says nothing about whether connectors must already exist, what happens on duplicate wiring, or how failures are reported.

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?

A single tight sentence with the noun (connectors) and effect (<connect>) front-loaded. Nothing is wasted, though it is arguably too terse to be fully useful.

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, so return values need not be explained. However, for a mutation tool with zero annotations and 5 parameters, the description omits preconditions (e.g. parts must already be placed) and side effects, leaving it only minimally complete.

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 coverage is 80%, so the schema already documents the required 'ref.connectorId' format for ref_a/ref_b and the view/color options. The description adds no parameter meaning beyond that, so the baseline 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?

Clear specific verb ('wire') and resource ('two part connectors'), plus it clarifies the output is an electrical <connect> element. It distinguishes itself reasonably from siblings like fritzing_place_part or fritzing_move_part, though it never names an alternative to route selection.

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?

No when-to-use guidance, no prerequisites, and no mention of alternatives such as fritzing_part_connectors (which an agent would likely need first to discover valid connector ids). Usage must be inferred entirely from the name.

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