Skip to main content
Glama

obj_batch_modify

Batch-apply multiple filter+set operations to modify many design objects (pins, parameters, components) in a single transaction instead of separate calls.

Instructions

Apply many filter+set operations in ONE IPC round-trip.

PREFER THIS over looping obj_modify whenever you have more than one change to make, especially when each change targets a different object (different designator, different pin name, different sheet). A single obj_batch_modify call touches N objects in the same Altium transaction; N separate obj_modify calls cost N LLM round-trips plus N IPC round-trips. The wall-time difference is typically 10-100x on a multi-item edit.

Use it for: moving multiple pins to specific positions, re-laying component placement, per-sheet title changes, bulk designator rewrites, any workflow where each object gets its own value.

A DESIGNATOR BATCH IS WORTH A NETLIST CHECK AFTERWARDS. There is no transaction rollback here: if an op fails part way the earlier ones stay applied, and duplicate designators are not an error Altium reports. Two parts left sharing D? had their separate nets MERGED by the netlister, which is silent and survives File > Revert All (reported on a live project, issue #23). proj_annotate renumbers a whole project in one operation and cannot leave duplicates, so prefer it when that is what you want.

Args: operations: List of operation dicts, each with: - scope: "active_doc" (default), "project", "doc:C:\path\to\file.SchDoc", or "lib_component:NAME" -- a named symbol in the active SchLib. Mixing lib_component scopes across ops edits many library symbols in ONE call, no per-symbol lib_set_current_component round-trip. - object_type: Altium object type (e.g., "ePin", "eParameter", "eSchComponent", "eNetLabel"), or a PCB type such as "eTrackObject", which edits the active board and takes only scope "active_doc" - filter: Pipe-separated filter conditions (e.g., "Designator.Text=U1", "Name=VDD") - set: Pipe-separated property=value assignments (e.g., "Location.X=300|Location.Y=-100|Orientation=2")

Returns: Dictionary with operations_processed, operations_skipped, total_matched, and a per-operation results list. Each result row carries its own matched count plus a note -- an op that matched nothing reports note="no_objects_matched" instead of being silently counted as successful.

Example, edit pins across THREE different library symbols in ONE call: obj_batch_modify(operations=[ {"scope": "lib_component:R_0402", "object_type": "ePin", "filter": "Designator=1", "set": "Name=A"}, {"scope": "lib_component:C_0402", "object_type": "ePin", "filter": "Designator=1", "set": "Name=+"}, {"scope": "lib_component:LED_0603", "object_type": "ePin", "filter": "Designator=1", "set": "Name=K"}, ])

Example, reposition 10 pins on a library symbol in ONE call (vs. 10 separate obj_modify calls, each a full LLM turn): obj_batch_modify(operations=[ {"scope": "active_doc", "object_type": "ePin", "filter": "Name=S1", "set": "Location.X=200|Location.Y=-100|Orientation=2"}, {"scope": "active_doc", "object_type": "ePin", "filter": "Name=S2", "set": "Location.X=200|Location.Y=-200|Orientation=2"}, {"scope": "active_doc", "object_type": "ePin", "filter": "Name=VDD", "set": "Location.X=800|Location.Y=-100|Orientation=0"}, ... # 7 more pins ])

Example, update 4 parameters across every project sheet in ONE call: obj_batch_modify(operations=[ {"scope": "project", "object_type": "eParameter", "filter": "Name=Engineer", "set": "Text=John Smith"}, {"scope": "project", "object_type": "eParameter", "filter": "Name=Revision", "set": "Text=2.0"}, {"scope": "project", "object_type": "eParameter", "filter": "Name=Organization", "set": "Text=Acme Corp"}, {"scope": "project", "object_type": "eParameter", "filter": "Name=CompanyName", "set": "Text=Acme Corp"}, ])

Example, different titles on specific sheets in ONE call: obj_batch_modify(operations=[ {"scope": "doc:C:\path\TopLevel.SchDoc", "object_type": "eParameter", "filter": "Name=Title", "set": "Text=Top Level"}, {"scope": "doc:C:\path\PSU.SchDoc", "object_type": "eParameter", "filter": "Name=Title", "set": "Text=Power Supply"}, ])

Input Schema

NameRequiredDescriptionDefault
operationsYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.1

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 behavioral burden and does so unusually well: it discloses there is no transaction rollback, that earlier ops stay applied on partial failure, that duplicate designators are not reported as errors, and that the resulting net merge is silent and survives File > Revert All (issue #23). It also explains the per-op note 'no_objects_matched' so an agent can distinguish a no-op from a success.

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 correctly: purpose, then preference, then failure caveats, then args, then returns, then examples. It is lengthy and the four examples overlap considerably (three are all 'one op per target object'), so a sentence or two could be trimmed without loss of information.

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?

Covers scope resolution, object typing, filter/set syntax, failure semantics, and the non-obvious gotcha of silent netlist merges. An output schema exists, yet the description still adds the per-op 'note' behavior, which is genuinely useful beyond the schema. Nothing an agent needs to construct a correct call is missing.

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 single param is a loosely typed array, so the description must compensate — and it does, enumerating every nested key (scope, object_type, filter, set), their allowed values/defaults (active_doc default, project, doc:path, lib_component:NAME), the PCB-type caveat restricting scope to active_doc, and the pipe-separated syntax for filter and set. Four worked examples show the exact nesting an agent must emit.

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 opening sentence states a specific verb and resource: 'Apply many filter+set operations in ONE IPC round-trip.' It immediately distinguishes itself from the sibling obj_modify, explaining that this tool is the batch form and naming the per-call alternative, so an agent can pick between them without opening either 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: 'PREFER THIS over looping obj_modify whenever you have more than one change to make,' with the condition spelled out (multiple changes, especially different objects) and the cost rationale (10-100x wall-time). It also names a competing tool for a specific case: 'proj_annotate renumbers a whole project in one operation and cannot leave duplicates, so prefer it when that is what you want.' The 'Use it for:' list further pins down intended workflows.

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