Server Quality Checklist

Tool Scores

• run_spiceC
  2.4/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It only states that the tool runs a deck and returns parsed measurements. It does not mention the optional timeout, potential resource implications of 'arbitrary' decks, error behavior, or whether this is a pure simulation with no side effects. The phrase 'arbitrary' hints at permissiveness, but important behavioral context is missing.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence with no redundancy or filler. However, the conciseness comes at the cost of crucial information such as parameter semantics and usage context. It is efficient but under-specified for a tool definition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Although the tool has a simple parameter set and an output schema, the description omits usage guidance and parameter details. The presence of a sibling like 'simulate_subcircuits' creates selection ambiguity that this description does not resolve. An agent could call it, but not with confidence about when it is the correct choice.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters1/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 0% description coverage for parameters, so the description must compensate. It references the 'deck' only implicitly and says nothing about the intended format or content of the deck string. The 'timeout_s' parameter is not mentioned at all. With only two parameters, this is a significant omission.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Run'), the resource ('an arbitrary SPICE deck'), and the outcome ('return the parsed measurements'). It is specific and conveys the core function effectively. However, it does not explicitly distinguish itself from the sibling tool 'simulate_subcircuits', so it stops 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.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives like 'simulate_subcircuits'. There is no mention of prerequisites, use cases, or exclusion criteria. An agent is left to infer the appropriate context from the name and the generic description.

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

• simulate_subcircuitsC
  2.6/5.0
  Behavior2/5

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

  No annotations are provided, so the description must carry the full burden of behavioral disclosure. It does reveal a meaningful conditional ('run them if a simulator is present') and the comparison step, but it does not mention side effects such as writing testbench files, whether results are returned or persisted, or what happens when no simulator is present. This leaves uncertainty about a potentially mutating operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single dense sentence that front-loads the main action and avoids filler. However, it packs three workflow steps into one clause string, leaving no room for usage caveats or parameter context. It is appropriately concise but slightly too compressed for the tool's complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with four parameters, no annotations, and a multi-step behavior, the description is materially incomplete. It omits parameter meanings, simulator prerequisites, behavior when run=false or tolerance_pct is set, and any routing guidance among close sibling tools. The presence of an output schema helps return-value understanding but cannot compensate for the missing operational context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters1/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, yet the description does not explain any of the four parameters. schematic_path, run, tolerance_pct, and follow_hierarchy are all undocumented in both the schema and the description, so an agent cannot reliably know how to set them. The only vague connection is the phrase 'run them,' which hints at the run flag but does not clarify its semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a clear verb-resource relationship: generate.SPICE testbenches, run them, and compare against analytical values. It conveys a specific workflow that goes beyond a generic label, though it does not explicitly name sibling tools to distinguish itself from run_spice or export_spice_netlist.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No when-to-use or when-not-to-use guidance is provided. It does not say when to choose this over run_spice, export_spice_netlist, or veriy_netlist, and it does not mention any prerequisites or exclusions. The only implicit signal is that it operates on 'subcircuits the detectors found.'

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

• pcb_statisticsC
  2.8/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden for behavioral disclosure. It suggests a read-only summarization but does not state that explicitly, nor does it mention what kind of statistics are returned, whether a valid PCB file is required, or how the tool handles missing or invalid paths.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single telegraphic line with no filler, and the key concept 'Board statistics' is front-loaded. It could be improved by adding a verb, but it is appropriately sized for the information it conveys.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple: one required string parameter and an output schema exists, so the description does not need to detail return values. However, it omits file-format expectations and does not position the tool against its list-oriented siblings, leaving some context gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The sole parameter, pcb_path, is self-descriptive as a path to a PCB, but the 0% schema description coverage means the description should compensate. It does not explain the expected file format, path type, or any constraints beyond the schema's required flag.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description identifies 'Board statistics' and enumerates the concrete data areas (layers, dimensions, footprints, tracks, vias, zones), so an agent can tell it summarizes board characteristics. It lacks an explicit verb like 'get' or 'compute', but the noun 'statistics' conveys the operation clearly.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance on when to use pcb_statistics instead of sibling tools such as list_footprints, list_components, or pcb_connectivity. The contrast between 'statistics' and 'list' is only implicit, so the agent must infer selection criteria.

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

• trace_connectionsC
  2.8/5.0
  Behavior2/5

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

  With no annotations provided, the description bears the full burden of disclosing behavior. It states that connections are traced but does not describe whether hierarchy is traversed, whether only logical connectivity is returned, or how exhaustive the trace is. The follow_hierarchy parameter introduces important behavior that the description omits.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is one short, front-loaded sentence with no wasted words. It immediately states the primary action and the optional focusing parameter, making it easy to process.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with four parameters, no annotations, and zero schema descriptions, the description is too sparse to be complete. It covers the core idea but omits paramter semantics, hierarchy behavior, and any boundary conditions. The presence of an output schema reduces the need to document return values, but does not compensate for the missing input guidance.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 for all four parameters. It hints at the roles of reference and pin ('from a component, or from one specific pin'), but it does not explain schematic_path or follow_hierarchy, leaving significant meaning unresolved.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a clear verb ('Trace') and resource ('connections') and identifies the two invocation modes: from a whole component or from a specific pin. It does not explicitly differentiate this from sibling tools like list_nets or pcb_connectivity, so it is clear but not fully distinguished.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives no guidance about when to use this tool versus alternatives such as list_nets, pcb_connectivity, or export_spice_netlist. The intended context must be inferred entirely from the word 'trace', which is insufficient for an agent deciding between similar connectivity-related tools.

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

• list_netsB
  3/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It reveals the geometric derivation approach and the lack of a KiCad dependency, but it does not state whether the tool is read-only, whether it writes files, or what side effects or failure modes might occur.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences with no filler. The main purpose is front-loaded and the KiCad independence note is a distinct, useful addition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Although an output schema exists and return values do not need to be described, the definition omits sibling differentiation, optional parameter semantics, and side-effect disclosure. For a tool with three parameters and no annotations, this is not complete enough for reliable agent selection and invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must explain parameter meaning, but it only implies the schematic_path input via 'schematic files'. It gives no explanation of name_contains or follow_hierarchy, leaving the optional parameters underspecified.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action (derive the netlist), a resource (schematic files), and a distinctive method (geometrically, no KiCad installed). It is clear, though it does not explicitly name or contrast a sibling such as export_spice_netlist.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'Works with no KiCad installed' gives a useful environmental context for when this tool is appropriate, but there is no explicit guidance about when not to use it or which sibling to prefer, such as export_spice_netlist. The usage guidance is implied rather than fully stated.

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

• pcb_connectivityB
  3.1/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It usefully explains the analysis categories (fully routed, unrouted, split islands) and implies a read-only analysis, but it does not explicitly state that the tool makes no modifications, nor does it mention any side effects or input requirements beyond the schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence that front-loads the core concept and immediately explains what the tool reports. Every word contributes meaning, and there is no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple with one parameter and an output schema, and the description captures the essential result categories. However, it omits any parameter guidance and usage context, so an agent may know what the tool does but not exactly how to supply the pcb_path or when to choose this tool over related siblings.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description does not mention pcb_path at all. The property title 'Pcb Path' gives a minimal clue, but the description fails to compensate for the missing parameter documentation by explaining what path should be supplied or any format expectations.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource (copper connectivity) and the outcome (which nets are fully routed, unrouted, or split into islands). It is specific enough to distinguish from list_nets or pcb_statistics, though it lacks an explicit verb and does not directly name sibling tools for differentiation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided about when to use this tool over alternatives like trace_connections or verify_netlist. The description gives no context on prerequisites, expected design state, or exclusions, leaving the agent to infer usage.

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

• add_componentB
  3.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the burden of behavioral disclosure. It explicitly states the library fallback behavior ('installed KiCad symbol libraries when available, otherwise a built-in symbol set') and that the tool 'writes atomically,' which are meaningful behavioral details beyond the bare mutation. It does not mention side effects or failure modes, but the disclosed behaviors are concrete.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two tight sentences with no filler. The primary action is front-loaded, followed by two high-value behavioral facts. Every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the high parameter count, multiple sibling tools, and absence of annotations, the description is too thin to fully support correct invocation. It omits critical guidance such as valid lib_id sources, coordinate units, whether schematic_path must already exist, and how add_component differs from add_generic_ic. The output schema reduces the need to describe return values, but the input-side gaps remain significant.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 for the eight parameters. It does not explain lib_id format, coordinate units, rotation conventions, value/reference/footprint semantics, or schematic_path expectations. The library-selection sentence hints at lib_id meaning but is far from sufficient.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description names a clear operation and resource: 'Add a component to a schematic.' It does not explicitly differentiate from the sibling tool add_generic_ic, which appears to overlap in function, so it is clear but not sibling-specific.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is given about when to use this tool versus add_generic_ic, add_wire, add_label, or other schematic-editing siblings. The description states facts about library selection and atomicity but does not explain under what conditions an agent should choose this tool over an alternative.

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

• list_componentsB
  3.2/5.0
  Behavior2/5

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

  With no annotations, the description is the only safety/behavior source, and it only confirms a read-style listing operation with filters. It omits the meaningful default behavior of follow_hierarchy (true), which affects whether sub-schematic components are included, and discloses no other behavioral traits.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  One front-loaded sentence conveys the action, resource, and main filtering options without wasted words. Every element earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The definition is minimally viable for selecting and calling the tool, and an output schema exists to cover return structure. However, the critical follow_hierarchy semantic is absent, and with no annotations the description should give more context about scoping the listing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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. It clarifies 'prefix' as a reference-prefix filter and implies 'value_contains' as a value filter, but it says nothing about follow_hierarchy, leaving a required-in-practice parameter meaning unexplained.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List'), names the resource ('components in a schematic'), and advertises optional filters. This clearly distinguishes the tool from siblings like list_nets and list_footprints, which operate on different resources.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives no explicit guidance on when to use this tool versus alternatives, and it names no sibling tools or exclusions. Usage must be inferred from the obvious 'list components' purpose.

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

• add_labelB
  3.3/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden, and it does add behavioral context: labels join nets either within one sheet or across the design. It does not discuss persistence, overwrite behavior, or prerequisites, but the additive 'Place' action and net-joining semantics are the most relevant traits.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two tight sentences front-load the core action and then explain the key parameter semantics. Every sentence earns its place; there is no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is sufficient for basic placement and for choosing local vs global, but it leaves 'hierarchical' undefined and gives no guidance on coordinates or placement context. With an output schema present, not describing the return value is acceptable, but the parameter gaps still leave room for missing calls.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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. It explains 'kind' and its local/global effect, but the required text, x_mm, y_mm, and schematic_path parameters are not described beyond their schema titles.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Place a net label', a clear verb+resource statement that names the object created. It differentiates the tool from siblings like add_wire and add_component mostly through the label-specific terminology, but it does not explicitly contrast with those alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives concrete guidance for choosing the kind parameter (local vs global labels), which helps an agent select the right variant. However, it does not say when to prefer add_label over sibling tools or state any exclusions.

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

• component_pin_positionsB
  3.3/5.0
  Behavior3/5

  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 does convey that this is a read-only reporting operation through the verb 'Report'. However, it does not disclose coordinate system, units, behavior when a component is not placed, or other side-effect-free details beyond the verb's implication.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no filler. Every clause earns its place: the resource, the action, and the purpose are all present.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter query tool, the description covers the basic intent and purpose, and an output schema exists to describe return values. However, it lacks explicit parameter semantics and usage guidance, so an agent may still need to infer how to populate the arguments or when to prefer this over sibling tools.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  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 by explaining the parameters, but it does not. 'reference' and 'schematic_path' are understandable from their names and the phrase 'placed component', yet the description adds no explicit meaning about formats, required context, or how they affect the reported coordinates.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Report') and a clear resource ('pin coordinates of a placed component'), and the stated purpose of drawing wires makes the function evident. It does not explicitly differentiate itself from sibling tools such as trace_connections or list_components, but the coordinate-reporting function is distinguishable by content.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The purpose clause 'so wires can be drawn to exactly the right points' implies the tool should be used before wiring, but it gives no explicit when-to-use/when-not-to-use guidance or mention of alternatives. There is no stated exclusion or condition routing the agent to a sibling tool.

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

• export_spice_netlistB
  3.3/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It does disclose one non-obvious behavior: active devices are listed as skipped rather than guessed. However, it does not mention whether it overwrites output files, what happens when output_path is null, or how follow_hierarchy affects the export.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences with the core action front-loaded and the behavioral caveat placed second. There is no redundant wording or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Although an output schema may cover return values, the description is incomplete for selection and invocation: it lacks usage guidance, parameter semantics, and side-effect information. The description feels like a brief note rather than a complete tool contract.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description needed to explain the parameters, but it adds almost no parameter-level meaning. 'From the schematic' only weakly maps to schematic_path, while output_path and follow_hierarchy remain unexplained.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description names a specific verb ('Export') and resource ('SPICE netlist') and clearly ties it to the schematic. The added caveat about active devices being skipped rather than guessed distinguishes it from related netlist/simulation tools like verify_netlist or run_spice.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance is given about when to use this tool versus alternatives such as simulate_subcircuits, run_spice, or verify_netlist. There are no exclusions, prerequisites, or context hints that would help an agent choose among sibling tools.

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

• create_kicad_projectB
  3.4/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral disclosure burden and does provide some useful detail by listing the created file types and the optional board outline. However, it does not disclose whether the directory must already exist, whether existing files would be overwritten, or any failure behavior for name collisions.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence with no filler, and the primary action is front-loaded. Every word adds useful information about the tool's purpose and optional behavior.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is adequate for a simple create operation and benefits from the presence of an output schema, but it leaves important operational details unstated, such as directory handling and overwrite behavior. It is minimally viable but not complete enough for an agent to call it with full confidence in edge cases.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema description coverage is 0%, so the description must compensate, but it only hints at board_width_mm and board_height_mm via 'optionally with a board outline.' It does not explain the semantics of name or directory, such as whether extensions are added automatically or whether the directory must exist.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb and resource ('Create a new KiCad project') and even names the three file extensions produced, which leaves no doubt about the tool's primary function. It clearly separates this creation tool from the many analysis/modification siblings by focusing on project creation and optional board outline.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no explicit guidance about when to use this tool versus alternatives like add_component or analyze_project. The intended use is only implied by the verb 'create' and the project context; no exclusions or routing cues are provided.

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

• add_wireA
  3.5/5.0
  Behavior3/5

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

  The description discloses useful behavioral details beyond the name: coordinates are in millimeters and are snapped to the 1.27 mm grid, and 'Draw' implies a mutating operation. However, it does not describe what changes happen to the schematic file or any validation/failure behavior, and there are no annotations to fill that gap.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that starts with the action and includes only necessary specifics. There is no filler or redundant restatement of the tool name.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple drawing command with five required parameters and an existing output schema, the core invocation data is present. The description still leaves usage-selection and side-effect details underspecified, making it minimally viable rather than fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has no parameter descriptions (0% coverage), so the description's mention of 'two points', 'mm', and grid snapping adds real meaning to x1_mm, y1_mm, x2_mm, and y2_mm. It does not clarify schematic_path semantics or the coordinate reference/origin, so it only partially compensates for the schema's silence.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Draw') and a concrete resource ('a wire between two points'), making the tool's function unambiguous. The added details about millimeters and the 1.27 mm grid further distinguish this from sibling tools like add_component or add_label.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives no explicit guidance on when to use this tool versus siblings such as trace_connections or add_label. It does not mention prerequisites, exclusions, or alternatives; the intended usage is only weakly implied by the word 'wire'.

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

• add_generic_icA
  3.6/5.0
  Behavior2/5

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

  No annotations are present, so the description carries the full burden for behavioral disclosure. It only states the action 'Add' and the target symbol; it does not disclose side effects on the schematic, permission requirements, input validation, or error behavior, which is especially sparse for a write operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short sentences front-load the core action, then add the decision rule and the most important parameter detail. Every sentence earns its place with no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The output schema exists, so return values need not be explained, and the description does provide a use case plus pins_json format. However, for an 8-parameter tool with no annotations and 0% schema coverage, this is under-specified: key parameters like lib_id, coordinate semantics, reference, and footprint are left unexplained.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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. It clarifies the structure of the opaque string parameter pins_json ('[[number, name, electrical_type], ...]'), but it leaves the semantics of schematic_path, lib_id, x_mm, y_mm, value, footprint, and reference unaddressed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a specific action ('Add') on a specific resource ('generic rectangular IC symbol') and the method ('by pin list'). The condition 'Use when the part is not in any installed library' further disambiguates it from library-based tools like add_component.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides an explicit trigger condition: 'Use when the part is not in any installed library.' It does not name the alternative tool or state a when-not condition, so it lacks full exclusionary guidance but still offers clear context for selection.

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

• analyze_projectA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description bears the full transparency burden. 'Full review' and 'analysis' imply a read-only inspection rather than a mutation, and the listed domains disclose the analytical scope. However, it does not state whether any files are written, how it behaves when the PCB is omitted, or what assumptions are made about project validity.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The entire definition is two sentences with no filler. The first sentence front-loads the tool's purpose and scope, and the second sentence gives the exact input requirements. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a high-complexity review tool with 0% schema description coverage, the description covers core inputs and high-level capabilities, and an output schema exists to explain return values. Still, it lacks guidance on when to prefer this tool over its many siblings and leaves the hierarchy-following parameter semantically unaddressed, so the invocation context is only partially complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description adds useful mapping not present in the schema: schematic_path should be a '.kicad_sch' file, and pcb_path is optional '.kicad_pcb'. Since schema description coverage is 0%, this compensation matters, but the third parameter, follow_hierarchy, is left entirely unexplained beyond its default.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description names a specific verb ('Full review') and resource ('KiCad project'), and enumerates concrete analysis domains: components, nets, analog/digital analysis, PCB routing, and DFM. This makes it clear the tool is a broad analysis entry point, though it does not explicitly name sibling tools or state how it differs from more targeted tools like list_components or verify_netlist.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The first sentence establishes clear usage context: use this when a comprehensive review of a KiCad project is desired. It also specifies invocation inputs (schematic, optionally PCB). No explicit when-not-to-use guidance or alternative tool routing is given, so it falls short of the strongest level.

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

• list_footprintsA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It communicates a read-only listing behavior and an optional side filter, but it does not detail filtering semantics, accepted side values, or error behavior. For a simple list operation this is adequate but not rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is one short sentence with no filler; the main action is front-loaded and the optional filtering behavior is stated compactly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple and has an output schema, so the minimal description is mostly sufficient. However, with no annotations and no guidance on valid side values or usage boundaries, the definition leaves some gaps for an agent to resolve.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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. It adds meaning to the side parameter by describing it as an optional one-side filter, but it does not define valid values or clarify that null means both sides. pcb_path is not elaborated, though its schema title makes its purpose reasonably clear.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action and resource: 'List PCB footprints', which clearly differentiates it from sibling tools like list_components and list_nets. The added clause about optional side filtering defines the tool's scope precisely.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies that this tool is for retrieving PCB footprints from a PCB file, but it does not state when to prefer it over alternatives such as list_components or verify_netlist. No exclusions or when-not-to-use guidance is provided.

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

• verify_netlistA
  3.7/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. 'Cross-check' implies a read-only verification action rather than a mutation, and the description adds the practical dependency on KiCad being installed and the authoritative status of the result. However, it does not disclose error behavior, output details, or whether the operation is safe to run repeatedly.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the core action. The first sentence says what it does, the second gives a hard prerequisite, and the third reinforces its role. Every sentence earns its place, though no additional useful behavioral or parameter guidance is included.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the essential purpose and the KisCad dependency, and an output schema exists so return values don't need explaining. But for a two-parameter tool, it omits the meaning of follow_hierarchy and does not help an agent decide between verify_netlist and related netlist tools beyond labeling itself authoritative. This is adequate but not complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description should compensate, but it does not mention either parameter. The name 'schematic_path' is reasonably self-explanatory, but 'follow_hierarchy' is not explained, and the description gives no additional meaning about how these inputs affect the verification.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly names the action ('cross-check'), the object ('our geometric net tracing'), and the reference ('KiCad's own netlist exporter'). It also frames itself as the authoritative correctness check, which distinguishes it from related sibling tools like trace_connections and export_spice_netlist.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It gives clear context: this is the authoritative verification step, and it explicitly states the key prerequisite that KiCad must be installed. It doesn't explicitly name alternatives or exclusions, so it stops just short of a 5, but the intended usage is clear.

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

• capabilitiesA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral disclosure burden. It transparently states what the tool reports: server abilities, deliberate non-abilities, and external-tool discovery. The verb 'report' clearly implies a read-only operation, and the mention of deliberate exclusion adds useful behavioral context beyond the bare schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that immediately states the purpose and then adds two meaningful specifications: deliberate exclusions and external tool discovery. There is no wasted wording, and the key information is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  As a parameterless, read-only meta-tool with an output schema available, the description fully covers what the agent needs to know to invoke it correctly. It conveys the tool's scope and its unique role among the siblings, and the output schema can define the return structure.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool takes zero parameters, so there is no parameter semantics to document. The description appropriately focuses on the output's subject matter rather than inputs, matching the baseline expected for a parameterless tool.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description names a specific action—'Report'—and a clear resource: the server's capabilities, including deliberate exclusions and discovered external tools. This strongly differentiates it from the sibling tools, which are all concrete EDA/PCB operations rather than a meta-level discovery tool.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description makes it evident this is a discovery tool for understanding server capabilities, which clearly implies it should be used before acting on specific domain tools. It does not explicitly name alternatives or state 'use this first,' so it stops short of a perfect score, but the context is unmistakable.

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