configure_netclasses

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 explains that KiCad would overwrite the change on next save, that replace_patterns drops all existing patterns (a destructive effect), and that priority 'lower wins' on overlap. It does not cover permissions or failure modes, but for a local file-editing tool the disclosure is strong.

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 purpose and the project-must-be-closed constraint are front-loaded before the args. The args block is long but every line documents a distinct key or behavior, so it earns its space; only mild verbosity keeps it off a 5.

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 5-parameter mutation tool with no annotations and an output schema already present, the description supplies the preconditions, per-field semantics, nesting example and destructive behavior needed to call it correctly. Nothing material is 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 0%, so the description must compensate, and it does: it enumerates the classes object keys (name required, nets with KiCad wildcard/root-sheet matching, current_a IPC-2221 sizing vs track_width_mm, clearance_mm, via_diameter_mm, via_drill_mm, priority) and explains project_path, temp_rise_c, copper_oz and replace_patterns, with a concrete example.

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+resource ('Create/update net classes and assign nets to them') plus the target artifact (.kicad_pro file). An agent can distinguish it from read-only siblings like list_netclasses and get_netclass_config 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?

Gives a critical precondition ('The project must be CLOSED in KiCad ... Reopen it afterwards') and the current-vs-fixed width choice. However it never explicitly routes to alternatives (e.g. use list_netclasses/get_netclass_config to inspect first), so it is clear context rather than full when/when-not/alternative guidance.

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