eda-agent

Overview Schema Source Related Servers Discussions Admin

lib_delete_footprint_primitives

Delete primitives from one PCB library footprint, scoped by library path, footprint name, and object type or layer so edits never hit an unnamed board. Pads stay protected unless explicitly included.

Instructions

Delete primitives inside ONE footprint of a PCB library.

THE ONLY LIBRARY-SCOPED PRIMITIVE DELETE. obj_delete and pcb_delete_object both resolve a BOARD, and when no board is focused that lookup opens the first PcbDoc any open project holds. Aimed at a library they do not fail; they remove primitives from a board you never named, and the reply does not say which one. This is the tool for editing a footprint.

SCOPED THREE WAYS, all of which must agree before anything is removed: the library by path, the footprint by name, and the object type or layer. The library is verified AFTER it is brought to the front, so a delete aimed at one that never focused is refused rather than landing in whichever did.

PADS ARE EXCLUDED unless include_pads. Deleting a pad changes the part's connectivity rather than its drawing, and clearing graphics off a layer should not quietly cost you the pinout.

THE FOOTPRINT ON SCREEN IS EDITED FROM ANOTHER. The footprint the editor shows keeps its primitives on the library board, which is written back into it at the next switch, so removing from it in place came undone. When the target is on screen, another footprint is made current for the delete (a temporary one in a single-footprint library, removed afterwards) and the target is shown again at the end; was_current says this happened.

Args: footprint_name: The footprint to edit. Required: deleting from whichever footprint the editor happens to show is the mistake this avoids. object_type: PCB object type, e.g. "track", "arc", "text", "region", "fill". Give this or layer. layer: Restrict to one layer, e.g. "TopOverlay", or a name the library's stack gives it, such as "Top Assembly". A name the stack does not have is refused, with the names it does have. library_path: The .PcbLib. Defaults to the focused document. include_pads: Allow pads to be removed. Off by default. confirm: Required. Read the footprint first with lib_probe_footprint and pass True once the filters are what you mean.

Returns: Dict with library, footprint, removed, examined, layers, pads_included and was_current.

Input Schema

Name	Required	Description	Default
`layer`	No
`confirm`	No
`object_type`	No
`include_pads`	No
`library_path`	No
`footprint_name`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.6.1Oct 29, 2026

TDQS

A4.9/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so: pads are excluded by default and why, the library is verified after focusing so a stale target is refused, deleting from the on-screen footprint is performed via a temporary stand-in footprint with ``was_current`` reporting it, and confirm is mandatory. These are exactly the non-obvious behaviors an agent needs.

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 action and the sibling warning, then organized into scoping, pads, and the screen-editing caveat. Some phrasing is ornamental ('quietly cost you the pinout') and the prose is longer than strictly necessary, but nearly every sentence carries a real constraint.

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 destructive six-parameter tool with no annotations, the description covers scoping, defaults, refusal conditions, the on-screen indirection, and the return keys. An output schema exists, so the brief Returns section is sufficient rather than redundant.

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 description coverage is 0%, so the description must compensate, and it does for all six parameters: footprint_name's rationale, object_type examples, layer examples plus the refusal-with-valid-names behavior, library_path default, include_pads semantics, and confirm's two-step protocol. It adds substantial meaning beyond bare types.

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 and resource (delete primitives inside ONE footprint of a PCB library) and immediately distinguishes itself from obj_delete and pcb_delete_object, explaining why those siblings are wrong for library editing. An agent can select this tool without opening any schema.

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

Usage Guidelines5/5

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

Explicitly names the alternatives and the condition that selects them (obj_delete/pcb_delete_object resolve a board, this edits a footprint), gives a prerequisite (read with lib_probe_footprint then pass confirm=True), and states the three-way scoping requirement. When-to-use and when-not-to-use are both covered.

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

Deploy Server