eda-agent

Overview Schema Source Related Servers Discussions Admin

pcb_add_testpoints_for_net_class

Place testpoint pads on nets in a specified net class that lack testpoint coverage, setting fab and assembly flags for bed-of-nails or probe fixtures.

Instructions

For each net in a netclass that does NOT already have a testpoint, place a new pad above the board outline with the net assigned and the standard IsTestpoint / IsAssyTestpoint flags set.

Typical workflow:

Set up a netclass in Altium called TestPoints and add the signals you want probed (clocks, power rails, reset, debug signals).
Call this tool with net_class="TestPoints" and the pad geometry your bed-of-nails fixture requires.
Open the PCB; the new pads sit in a row above the board, with the right net + testpoint flags already set.
Drag them into their final positions (or run pcb_move_components if you've pre-computed where they go).

Coverage detection: a net is treated as "already covered" if any pad or via on it carries ANY of the four testpoint flags (so DFM tools, fab-side bed-of-nails vendors, and assembly- side probe vendors all see the same coverage). Pass force=True to override and place anyway.

Agent-friendly: no GUI, results returned for follow-up.

Args: net_class: Netclass name to scan. type: "smd" (top-layer SMD pad, no hole) or "through_hole" (multi-layer pad with drill). pad_size_mils: Outer pad size in mils. Default 40. hole_size_mils: Drill diameter, only used for through-hole testpoints. Default 20. fab_top: Set IsTestpoint_Top (top-side bed-of-nails). fab_bottom: Set IsTestpoint_Bottom. assy_top: Set IsAssyTestpoint_Top (top-side assembly probe). Default True. assy_bottom: Set IsAssyTestpoint_Bottom. force: Ignore existing testpoint coverage and always place a new pad.

Returns: Dict with {net_class, type, placed, skipped_already_covered, placed_nets[], skipped_nets[]}.

Input Schema

Name	Required	Default
`type`	No	smd
`force`	No
`fab_top`	No
`assy_top`	No
`net_class`	Yes
`fab_bottom`	No
`assy_bottom`	No
`pad_size_mils`	No
`hole_size_mils`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.6.1Oct 29, 2026

TDQS

A4.5/5.0

Behavior4/5

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

No annotations exist, so the description carries the full burden and largely meets it: it discloses the exact side effect (new pads placed above the board outline, not in final position), the precise coverage-detection rule across four testpoint flags, and the force override. It omits whether an open PCB document or edit permission is required and whether the placement is undoable.

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?

Front-loaded with the core behavior, then cleanly sectioned into workflow, coverage rule, and Args. Slightly padded in the parenthetical about DFM/fab/assembly vendors, but no section is truly wasteful.

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?

For a nine-parameter mutation tool with zero annotation and zero schema-description coverage, the description supplies purpose, workflow, edge-case semantics, per-parameter detail, and (redundantly but harmlessly) the return shape despite an output schema existing. An agent has everything needed to invoke it correctly.

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

Parameters5/5

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

Schema coverage is 0%, and the description fully compensates by documenting all nine parameters with meaning and defaults. It is especially valuable for `type`, whose schema is a bare string with no enum — the description supplies the two allowed values and what each produces (SMD top-layer pad vs. multilayer drilled pad).

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 verb+resource with exact scope: 'For each net in a netclass that does NOT already have a testpoint, place a new pad above the board outline with the net assigned.' This distinguishes it unambiguously from siblings like pcb_place_pad (single explicit pad) and pcb_place_thieving_pads.

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 numbered 'Typical workflow' section gives clear preconditions (netclass must exist in Altium with signals added) and names an alternative for the follow-up step (pcb_move_components for final positioning). It does not explicitly state when to prefer this over hand-placing pads with pcb_place_pad, which keeps it just short of a 5.

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

Deploy Server