Skip to main content
Glama

preview_placement

Read-onlyIdempotent

Validate proposed footprint placements against board constraints and design rules, returning a deterministic legality check without applying changes.

Instructions

Validate a proposed footprint placement against a board, without changing anything.

``request`` takes ``board``, ``constraints``, and ``subjects`` (the footprint references
the proposal may move), plus optional ``rules``, ``proposals`` and ``placement_grid_nm``.

Rules come in seven kinds - proximity, alignment, symmetry, edge, region, orientation and
side - and name objects only by the references a scene already returned. Proposals are
anchored the same way: an offset from another object's edge or centre, never an absolute
coordinate. Positions in the response are derived here and snapped to the placement grid.

A ``previewed`` result carries an immutable candidate whose legality was proven
deterministically. Note that ``pad_overlap`` is three-valued: ``inconclusive`` means
neither clearance nor collision could be proven, and is not a failure. Courtyard overlap is
reported as ``not_modelled`` and is genuinely not checked. This tool never applies a
placement, and a placement is not bound to KiCad DRC evidence in this version.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
requestYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
statusYes
requestYes
candidateYes
board_pathYes
diagnosticYes
board_revisionYes
snapshot_digestYes
placement_versionYes
conversion_diagnostic_countsYes
Behavior5/5

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

Beyond the annotations (readOnly, idempotent, non-destructive), the description explains three-valued pad_overlap, that inconclusive is not a failure, courtyard overlap is not_modelled, and that legality is deterministically proven. It also disclaims DRC binding, adding valuable operational context without contradicting annotations.

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?

The description is dense but organized into purpose, request structure, and result semantics. While it is longer than typical, each section adds necessary technical detail for a complex tool, and there is no filler.

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 tool's complexity and the presence of an output schema, the description covers request construction, validation semantics, grid snapping, and return value caveats. It addresses edge cases like inconclusive pad_overlap and non-modelled courtyard overlap, making it sufficiently complete.

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?

The schema only exposes a generic 'request' object, so the description is essential. It enumerates the request fields (board, constraints, subjects, optional rules, proposals, placement_grid_nm), describes the seven rule kinds, and explains proposal anchoring by reference rather than absolute coordinates, fully compensating for the empty 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 opening line 'Validate a proposed footprint placement against a board, without changing anything' uses a specific verb and resource, clearly distinguishing it from siblings like apply_candidate and preview_route. The description also clarifies its role as a validation-only tool.

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 states the tool never applies a placement, which guides against using it for execution, and positions it as a validation step. However, it does not explicitly name alternative sibling tools or explain when to prefer this over validate_candidate, so the guidance is implied rather than fully explicit.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/seunghyukchoe/copper-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server