Skip to main content
Glama

pcb_place_3d_body

Place a STEP model directly on an open PCB as a free 3D body, not inside a component or library footprint. Use it for fixtures, enclosures, or test devices that are not parts.

Instructions

Place a STEP model directly on the open PCB, as a free 3D body.

The equivalent of Altium's Place > 3D Body > Generic STEP Model: the model lands on the document itself, not inside a component.

USE THIS RATHER THAN lib_link_3d_model WHEN THE MODEL IS NOT A PART. That tool writes into a .PcbLib footprint, so putting a fixture, an enclosure or a device-under-test onto a board with it means inventing a library, authoring a footprint, placing it and then deleting all of that again. Reach for it only when the model genuinely belongs to a component in a library.

Rotation cannot be set from here. IPCB_ComponentBody exposes no Rotation, and the rotation that does exist lives on the model behind an undocumented four-argument call, so the reply reports rotation_applied: false rather than guessing. Rotate in the editor if the orientation is wrong.

Args: model_path: absolute path to the .step / .stp file. x: body origin X in mils. This is the model's own origin, so where it lands depends on how the STEP was authored; check it against a known feature such as a silkscreen outline rather than assuming it is centred. y: body origin Y in mils. layer: board layer to attach it to. Default TopLayer. standoff_height: height in mils of the body's underside above the board. 0 sits it on the surface.

Returns: {"success": true, "model_path": ..., "x": N, "y": N, "layer": ..., "standoff_height": N, "standoff_applied": bool, "rotation_applied": false, "note": ...}. The x and y are READ BACK from the placed body, not echoed, because the position is the one thing that cannot be checked without opening the 3D view.

Input Schema

NameRequiredDescriptionDefault
xNo
yNo
layerNoTopLayer
model_pathYes
standoff_heightNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.1

TDQS

A4.7/5.0
Behavior4/5

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

With no annotations, the description carries full burden and does well: it discloses that rotation cannot be applied and why, that x/y are read back from the placed body, and that standoff is a height in mils. It stops short of stating prerequisites (an open PCB document is implied) or what happens on re-placement over an existing body.

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 core action, then use/avoid routing, then the rotation caveat, then args and returns — a sensible order. Some prose is expansive (the library round-trip aside), but every sentence still conveys actionable 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 purpose, alternative routing, a hard capability limit (no rotation), all parameters with units and pitfalls, and the return payload despite an output schema existing. Nothing an agent needs to call this correctly 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%, so the description must compensate, and it does for all five parameters: absolute path for model_path, mils plus an origin caveat for x/y, layer defaulting to TopLayer, and standoff_height as underside height with 0 meaning flush. The origin/centering warning adds real meaning absent from 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?

States a specific verb and resource ('Place a STEP model directly on the open PCB, as a free 3D body') and immediately anchors it to the Altium menu command, making the operation unambiguous. It explicitly contrasts with the sibling lib_link_3d_model, so an agent can distinguish the two without reading schemas.

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 when-to-use ('when the model is not a part', fixtures/enclosures/DUT) and when-not-to ('reach for lib_link_3d_model only when the model genuinely belongs to a component in a library'). This is the strongest possible routing guidance.

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