eda-agent

Overview Schema Source Related Servers Discussions Admin

pcb_get_mech_layer_names

Lists all enabled mechanical layers on a PCB and optionally counts the primitives on each, helping you identify spare layers and verify board geometry usage.

Instructions

Every enabled mechanical layer on the board, and what is on it.

WHAT IS ON THE LAYER IS THE PART YOU CANNOT GET ELSEWHERE. A PcbLib header carries USEDBYPRIMS; a PcbDoc does not, so on a board there is no way to ask which mechanical layers the geometry occupies. This counts, because moving kinds around on a board you cannot inspect is how an assembly drawing gets orphaned. primitive_count of 0 is a layer that is genuinely spare; -1 means the count was not attempted or failed.

ENABLED, NOT DISPLAYED. This used to list only layers the view happened to be showing, so a layer carrying the whole fab drawing was missing from the answer whenever it was toggled off. Display is a view setting and is reported separately as displayed.

Each entry carries its kind, which is what the layer is FOR rather than what it is called. Read it before setting one: a kind belongs to a single layer, so assigning it moves it, and a PAIRED kind is held by the layer pair. kind_id of -1 means this Altium build has no mechanical layer kinds.

Args: count_primitives: Count what sits on each layer. The board is walked once per enabled layer, so pass False when only the names are wanted.

Returns: Dict with mechanical_layers (each: layer, number, name, enabled, displayed, kind, kind_id, primitive_count), count, occupied_count, counted_primitives and scanned_to, the layer number the scan stopped at.

Input Schema

Name	Required	Description	Default
`count_primitives`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.6.1Oct 29, 2026

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description carries the load well: it discloses the cost model ('the board is walked once per enabled layer'), sentinel semantics ('primitive_count of 0 is genuinely spare; -1 means not attempted or failed'), and 'kind_id of -1 means this Altium build has no mechanical layer kinds'. It stops short of stating any document/permission requirement or whether the scan is bounded by the scanned_to limit under normal conditions.

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

Conciseness3/5

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

Purpose is front-loaded and the Args/Returns blocks are well formed, but the prose is padded with rhetorical asides ('This counts, because moving kinds around on a board you cannot inspect is how an assembly drawing gets orphaned') and the kind paragraph partly addresses a setter concern ('assigning it moves it') rather than this read-only call. Several sentences could be trimmed without losing an agent-relevant fact.

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 single-parameter read on an opaque Altium concept, everything an agent needs is present: scope (enabled vs displayed), sentinel values, cost of the flag, and a return-field inventory. An output schema exists, yet the description still names the keys so the agent can reason about partial scans via scanned_to.

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 description coverage is 0%, so the description must compensate, and it does: count_primitives is defined functionally ('Count what sits on each layer') plus operationally ('the board is walked once per enabled layer, so pass False when only the names are wanted'). That is both meaning and a decision rule for the flag.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource: 'Every enabled mechanical layer on the board, and what is on it', and the 'ENABLED, NOT DISPLAYED' section clarifies the scope against the display-oriented view of the same data. It does not name a sibling tool, so the differentiation is conceptual rather than explicit (pcb_get_layer_display is never mentioned), which keeps it just below a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is motivated rather than routed: 'WHAT IS ON THE LAYER IS THE PART YOU CANNOT GET ELSEWHERE' explains why to call it, and the args note says when to pass False. There is no explicit when-not, no named alternative tool, and no statement of prerequisites (e.g. a PCB must be the active document).

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

Deploy Server