Skip to main content
Glama

pcb_autoplace

Places a PCB's parts with an in-house engine as a background job, returning a job ID and previewable moves, wirelength changes, overlaps, and DRC verdict before applying.

Instructions

Place the focused board's parts with the in-house placer, as a job.

Reads the board exactly (pcb.get_layout_model), then places it in the background and returns a job id at once. Poll design_job_status; design_job_result gives the moves, the wirelength before and after, any overlaps, and the exact DRC's verdict on the placed board (unrouted). Nothing is moved on the board until pcb_autoplace_apply.

Two strategies. "blocks" plans the board by sub-circuit first: each IC with its decoupling, pull-ups and filters in columns round it, connectors with the parts on their lines, passives in rows, repeated channels as identical tiles in a grid, the blocks placed in signal-flow order from the connectors; its result also lists the blocks (name, rectangle in mils, members) and every part the legaliser had to move, with the moves over 80 mil flagged as floorplan problems. "analytic" places by wirelength alone (quadratic placement, spreading, legalising, refinement).

Parts keep their side. Locked parts, and parts whose designator starts like a connector, mounting hole, fiducial, test point, switch or battery, stay where they are unless named in parts: they sit where they do for mechanical reasons. The board's own routing does not move with its parts: place before routing, or take the routing up first with pcb_unroute.

This is the in-house engine: no Altium auto-placer, no external program.

Args: expect_file: full path of the board to place. The read refuses on the first reply if the focused board is another one. parts: designators to move; every other part stays. None moves every part that is not locked or mechanical (see above). compact: spread the parts over only as much room as they need, round where their connections pull them, instead of over the whole board. For a small circuit on a large board; over the benchmark boards it routes slightly worse, so it is off by default. Analytic strategy only. strategy: "blocks" or "analytic"; None takes the placer's default, "blocks". A board where the floorplan has to push more than a quarter of its parts out of place is placed by "analytic" instead, and the result says so under fallback.

Returns: {"job_id", "board", "strategy", "read": {...}}, or {"error": ...} when the strategy is unknown, or the read failed or found another board.

Input Schema

NameRequiredDescriptionDefault
partsNo
compactNo
strategyNo
expect_fileYes

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?

No annotations are provided, so the description carries the full burden — and it does: asynchronous job with immediate job_id return, deferred mutation gated behind an apply call, parts keeping their side, locked/mechanical parts pinned unless named, and an automatic fallback to 'analytic' when the floorplan pushes more than a quarter of parts, reported under 'fallback'.

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 async contract and side-effect boundary, then strategy detail, then Args/Returns — a sound ordering given the tool's complexity. It runs long and a few clauses (e.g. the exhaustive list of block contents, the 'no Altium auto-placer' aside) are more than an agent strictly needs, but nearly every sentence carries operational meaning.

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 four-parameter, mutation-deferred job tool with no annotations, the description covers the entire lifecycle: read, job dispatch, polling, result contents (moves, wirelength before/after, overlaps, DRC verdict, blocks) and the separate apply step. The return shape is documented in prose and backed by an output schema.

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 description compensates fully for all four parameters: expect_file (full path, read refusal on mismatched focused board), parts (designator list, None = all non-locked/non-mechanical), compact (behavior, default, analytic-only restriction), strategy (accepted values, None default 'blocks', fallback rule). Nothing essential is left to the bare 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?

States a specific verb and resource ('Place the focused board's parts with the in-house placer, as a job') and immediately distinguishes itself from the apply step and from pcb_autoroute. An agent can tell it apart from pcb_place_components, pcb_move_components or pcb_plan_placement 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 spells out the workflow: nothing moves until pcb_autoplace_apply, poll design_job_status, read design_job_result. It also names the when-not ('place before routing, or take the routing up first with pcb_unroute') and gives the selection rule for the two strategies, including why compact is off by default.

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