Skip to main content
Glama

obj_delete

Find and delete schematic or PCB objects by type and property filter, with a required confirmation when the filter is empty to prevent deleting every object of that type.

Instructions

Find and delete schematic or PCB objects.

For several scope/type/filter sets at once, use obj_batch_delete , one IPC round-trip vs one LLM turn per delete.

A PCB type (eTrackObject, eViaObject, ...) deletes from the active board, and matches a footprint's own primitives and a polygon's hatching too unless the filter says "InComponent=false" and "InPolygon=false". To take up routing, pcb_unroute does that with the right exclusions built in.

Args: object_type: Altium object type constant (see obj_query) scope: "active_doc", "project", "doc:PATH", or "lib_component:NAME" (a named symbol in the active SchLib). A PCB type takes only "active_doc". filter: Pipe-separated property=value conditions (AND logic). WARNING: empty filter deletes ALL objects of the type. confirm_delete_all: Must be True to delete all objects when filter is empty.

A filter that is not Name=Value pairs (an Altium query expression such as OnLayer('TopLayer') Or ..., or a bare name) is refused, and nothing is deleted.

Returns: Dictionary with "matched" count (number deleted)

Input Schema

NameRequiredDescriptionDefault
scopeNoactive_doc
filterNo
object_typeYes
confirm_delete_allNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.1

TDQS

A4.8/5.0
Behavior5/5

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

No annotations exist, and the description carries the full burden well: it warns that an empty filter deletes ALL objects of the type, that confirm_delete_all must be True in that case, that PCB types also match footprint primitives and polygon hatching, and that a non-Name=Value filter is refused with nothing deleted. That is exactly the destructive-behaviour and safety-gate context 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 and information-dense, but the empty-filter danger is stated twice (prose warning plus the confirm_delete_all arg note) and the invalid-filter refusal appears both in the Args block and again as a standalone paragraph. Slight duplication and stray leading indentation cost it a point.

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

Completeness4/5

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

For a destructive, unannotated tool the description covers scope rules, filtering syntax, refusal cases, and the bulk-delete confirmation gate; return values are already covered by the output schema. It only omits whether a deletion is undoable or should be preceded by app_checkpoint, which matters for an irreversible mutation.

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%, yet the Args section documents all four parameters: object_type as an Altium constant (pointing to obj_query), scope with its four literal forms, filter as pipe-separated property=value AND conditions with a warning, and confirm_delete_all as the guard for empty-filter deletion. This fully compensates for the empty schema metadata.

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?

Opens with a specific verb+resource ("Find and delete schematic or PCB objects") and immediately differentiates itself from two siblings: obj_batch_delete for bulk scope/type/filter sets and pcb_unroute for routing. An agent can pick this tool versus neighbours 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?

Explicit routing rules: use obj_batch_delete for several scope/type/filter sets at once (noting the round-trip cost), and use pcb_unroute to remove routing because it applies the right InComponent/InPolygon exclusions. It also states scope constraints (a PCB type takes only "active_doc"), which further narrows when this tool is the right choice.

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

Deploy Server

Other Tools