Skip to main content
Glama

proj_sync_pcb

Push schematic changes into the PCB by running the ECO update, which blocks on a modal dialog until a human confirms Execute Changes; not for unattended runs.

Instructions

Push schematic changes to PCB (ECO): Design ▸ Update PCB Document.

IMPORTANT: this is NOT silent. Altium's ECO (change-review) dialog is non-suppressible by design, so this fires the real ECO and then BLOCKS on a modal dialog until a human clicks "Execute Changes". Do not call it in an unattended/headless run: it will hang the Altium-side polling loop until someone interacts. (There is no documented silent flag; the prior implementation called a non-existent process id and silently did nothing.)

The server:

  1. Compiles the project and records before-state mappings (matched, extra-in-schematic, extra-in-pcb).

  2. Focuses the project's PCB and invokes WorkspaceManager:Compare (ObjectKind=Project, Action=UpdateMe): import the schematic's changes into that PCB. The modal ECO dialog opens here.

  3. After the user accepts, recompiles and reports the after-state delta (how many components were added/removed).

THE DIRECTION DEPENDS ON FOCUS, so the tool sets it. A schematic in focus makes Altium refuse with "Cannot compare a source document against its owner project"; the PCB in focus with Action=UpdateOther updates the SCHEMATIC from the board, which is what this tool used to send, and an ECO came up with the SchDoc as the affected document. Refuses with WRONG_FOCUS when the PCB cannot be focused. Before executing, check that the ECO's affected documents are the PcbDoc.

What the result does NOT tell you: whether the dialog was accepted. dialog_outcome_verified is always false, because the handler returns as soon as the modal closes and cannot see which button was pressed. components_added_to_pcb and its siblings are recounts, so they catch a change in component PRESENCE and miss everything else an ECO carries: footprint swaps, designator and parameter edits, net changes. Unchanged counts therefore mean "nothing was added or removed", not "nothing happened". To learn what the dialog actually says, call app_list_open_dialogs, which reads Altium over Win32 and so answers while the modal is blocking the bridge.

For unattended board population without a schematic, use pcb_place_components instead (places geometry only: see its note about leaving the project unsynced).

Returns: Dictionary with success, pcb_path, before/after mapping counts, components_added_to_pcb, components_removed_from_pcb, components_in_sync (component presence only, see above), and dialog_outcome_verified.

Input Schema

NameRequiredDescriptionDefault

No arguments

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, so the description carries the full burden and does: it discloses the non-suppressible modal block, the internal compile/Compare/recompile sequence, the focus-dependent direction, and the WRONG_FOCUS refusal. It also candidly states what the result does not prove (dialog_outcome_verified always false; component counts miss footprint/net/parameter edits).

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 warning, then numbered steps, then result caveats – well organized and every section is substantive. Slightly long, with some repeated phrasing around the focus/direction issue, but nothing is padding.

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?

An output schema exists, and the description still adds the crucial interpretive caveats the schema cannot convey (counts measure presence only, dialog outcome unverifiable), plus a pointer to app_list_open_dialogs for reading the blocking dialog.

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 the 4 baseline applies; the description correctly spends no words on parameters and instead covers the implicit preconditions (project focus) that govern a call.

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: push schematic changes into the PCB via an ECO, naming the exact Altium menu command. It explicitly distinguishes itself from the inverse operation (proj_sync_schematic behaviour it 'used to send' with Action=UpdateOther) and from pcb_place_components.

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?

Gives an explicit prohibition ('Do not call it in an unattended/headless run') with the consequence (hangs the polling loop on the modal), and routes to the stated alternative, pcb_place_components, for unattended board population. Also states the WRONG_FOCUS precondition.

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