eda-agent

Overview Schema Source Related Servers Discussions Admin

pcb_set_mech_layer_kind

Assigns a purpose kind to a PCB mechanical layer so courtyard, assembly, 3D, and via treatments use it; supports paired Top/Bottom kinds and clears conflicting single-kind assignments.

Instructions

Set what a mechanical layer is FOR, not what it is called.

Renaming a layer "Courtyard Top" does not make it one. The KIND is a separate property, and it is what every feature resolving a layer by purpose reads: courtyard checking, assembly drawings, 3D body placement and the IPC-4761 via treatments. A layer with no kind is skipped by all of them, so the outlines get drawn and nothing uses them.

A SINGLE kind such as "Fab Notes" belongs to ONE layer at a time. If another layer already holds it, that layer is cleared first and named in cleared_from, because leaving two layers claiming one purpose is a state the stack manager does not intend.

A PAIRED kind, meaning any name ending in Top or Bottom, works differently: it is held by the layer PAIR rather than by either layer, under a separate set of names with the side dropped. So "Courtyard Top" is stored as the pair kind "Courtyard" across the two layers, and partner_layer is required to say which layer carries the other side. Writing it without a partner is refused rather than silently doing nothing.

The write is READ BACK before reporting success. A refused assignment raises nothing here, so trusting it would report success for having changed nothing.

Args: layer: Mechanical layer, e.g. "Mechanical13". kind: A kind name such as "Courtyard Top", "Assembly Top", "3D Body Top", "Component Outline Top", "Fab Notes" or "Not Set". A bare number is also accepted, so a kind added by a later Altium release can be set without waiting for the name map to catch up. Read the current assignment with pcb_get_mech_layer_names. partner_layer: The mechanical layer carrying the other side, required when kind ends in Top or Bottom and ignored otherwise. The two layers are joined as a pair, which is what the kind is then written to.

Returns: Dict with layer, kind, kind_id, paired, pair_kind, partner_layer and cleared_from.

Input Schema

Name	Required	Description	Default
`kind`	Yes
`layer`	Yes
`partner_layer`	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.7/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 burden and does it well: it discloses that a conflicting single kind is cleared from another layer and reported via cleared_from, that a paired write without a partner is refused, that the value is read back before success is reported, and that refusals do not raise. Those are exactly the side effects and failure modes an agent must anticipate.

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 key distinction is front-loaded in the first line and the paragraphs are ordered by importance (purpose, single vs paired semantics, read-back). It runs long and a few sentences are rhetorical rather than informational, but no paragraph could be dropped without losing 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 mutation with real side effects, no annotations and an untyped schema, the description supplies the permissions-free but state-mutating consequences, the pairing rule, and the verification step. An output schema exists, yet the description still names the return keys, so an agent knows cleared_from and paired will be reported back.

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: it documents layer with an example, enumerates accepted kind names plus the 'Not Set' case, explains that a bare number is allowed for forward compatibility, and states partner_layer is required only for Top/Bottom kinds and ignored otherwise.

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 states a specific verb and a specific property: setting what a mechanical layer is FOR (its kind), not its name. It explicitly separates KIND from name, which is the exact distinction an agent needs to pick this over the rename siblings such as pcb_set_mech_layers or lib_set_mech_layers.

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 concrete conditions: single kinds are exclusive and steal from other layers, Top/Bottom kinds require partner_layer and are refused without one, and current assignments should be read with pcb_get_mech_layer_names first. What is missing is an explicit statement of when NOT to use this tool, e.g. versus the name-setting siblings that appear alongside it.

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

Deploy Server