eda-agent

Overview Schema Source Related Servers Discussions Admin

pcb_place_components

Place one or many footprints from PcbLibs onto a PCB in a single call, replacing Altium's modal ECO dialog for unattended population. Batch placements in one transaction with optional schematic net syncing.

Instructions

Place one or many footprints from PcbLibs onto the board in ONE call.

The scriptable substitute for ECO / Design ▸ Update PCB Document: Altium's ECO always raises a modal, so for unattended population this drops footprints straight onto the board. It resolves the board once and places every footprint in a single Altium transaction (one IPC round-trip). Pass a single-element list to place just one.

Two modes per component: geometry only (omit unique_id / pad_nets) leaves pads unconnected (DRC flags them), good for artwork / panelization / fiducials / placement studies; synced (pass both) stamps the schematic UniqueId so a later ECO matches the part and creates+assigns each pad's net for real connectivity. Read unique_id via query_objects(eSchComponent, "Designator.Text,UniqueId") and pad_nets from the compiled netlist (proj_get_connectivity_many → pad number → net).

board_path: target a specific .PcbDoc when several are open (resolved once for the whole batch). Otherwise the focused board is used.

Args: placements: List of placement dicts, each with: footprint (required), library_path (required, .PcbLib), x, y (mils), designator, lib_reference, comment, rotation, layer, unique_id, and pad_nets ({pad_name: net_name}); omit unique_id/pad_nets for geometry-only, include them for a synced placement. board_path: Absolute .PcbDoc path to place onto (optional).

Returns: Dict with placed (count), failed (count), total.

Input Schema

Name	Required	Description	Default
`board_path`	No
`placements`	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.8/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 thoroughly: it discloses the mutation, the modal-free unattended workflow, single-transaction batching, DRC consequences in geometry-only mode, and real net creation in synced mode. It also clarifies that the board is resolved once for the whole batch.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core action and then structured into mode behavior, Args, and Returns. Its length is justified by the complex nested placements list and the absent schema documentation; every section earns its place.

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?

Given the complex batch-placement operation, empty parameter schema, no annotations, and presence of an output schema, the description provides everything needed: placement modes, required fields, board targeting, sourcing of sync data, and a return summary. No material gaps remain for correct invocation.

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%, so the description must document parameters, and it does: it lists required fields, units for x/y, optional placement metadata, the unique_id/pad_nets toggles, and board_path behavior. It even explains how to source unique_id and pad_nets, adding meaning well beyond the schema.

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 description states a specific verb and resource: placing one or many PcbLib footprints onto the board in one call. It further distinguishes itself as the scriptable substitute for Altium's ECO/Update PCB Document workflow, making its role clear against the modal UI path.

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?

It gives clear mode-selection guidance: omit unique_id/pad_nets for geometry-only placement, include both for synced connectivity, and pass a single-element list to place one component. It also explains board_path for multi-board sessions, though it does not explicitly compare itself with sibling tools such as app_update_from_libraries or pcb_import_placement.

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

Deploy Server