altium-designer-mcp

Overview Schema Source Related Servers Discussions Admin

Write a PcbLib

write_pcblib

Destructive

Write complete PCB footprints to Altium .PcbLib files, defining pads, tracks, vias, silkscreen, and 3D bodies with precise millimeter coordinates.

Instructions

Write footprints to an Altium .PcbLib file (set 'append': true to add to an existing library instead of replacing it). Each footprint is defined by its primitives: pads (with position, size, shape, layer), tracks, vias, fills, arcs, regions, text and component_bodies. The AI is responsible for calculating correct positions and sizes based on IPC-7351B or other standards. All coordinates and dimensions must be in millimetres (mm). A footprint authored without a '.Designator' text receives one on the Top Overlay automatically, just above its topmost pad, so every placed part shows its reference designator: supply your own to control its placement, or set 'auto_designator': false to omit it; a footprint echoed back from a read (carrying primitive_order) is never touched. The response 'bodies' array echoes each footprint's 3D body height and source; a footprint with no STEP model and no component body reports source 'none'. Set 'auto_3d_body': true to have an extruded placeholder body (default height 1.0 mm, flagged 'assumed_height': true) added to such footprints, then confirm or override it by supplying 'component_bodies' explicitly. The response also includes a 'warnings' array flagging silkscreen (overlay) tracks that overlap a pad (silk-on-pad) so you can move them clear. No text field may contain '|', the separator of Altium's record format, which cannot hold it.

Input Schema

TableJSON Schema

Name	Required	Description
`append`	No	If true, append to existing file; if false, create new file
`filepath`	Yes	Path to the .PcbLib file to create/modify
`footprints`	Yes	Array of footprint definitions
`auto_3d_body`	No	If true, footprints with pads but no STEP model and no component body get a placeholder extruded 3D body (1.0 mm tall, flagged assumed_height). Default false: nothing is added unless you ask, since many footprints (fiducials, test points, mounting holes) legitimately have no body. Prefer supplying real heights via component_bodies.
`auto_designator`	No	If true (default), a footprint authored without a '.Designator' text gets one on the Top Overlay just above its topmost pad, so the placed part shows its reference designator. Never applied to a footprint echoed back from read_pcblib/get_component (one carrying primitive_order): Altium's own library footprints carry no designator text, and a read-modify-write must not add primitives. Set false to author a footprint without one.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv1.1.0Sep 25, 2026

changed

Input schema / properties / footprints / items / properties / component_bodies / items / properties / identifier / description

Previous value: -"The body's IDENTIFIER, a user-visible name (any Unicode; stored as code points on disk). Default: empty"New value: +"The body's IDENTIFIER, a user-visible name (any Unicode; stored as UTF-16 code units on disk). Default: empty"

addedInput schema / properties / footprints / items / properties / pads / items / properties / polygon_connect

Added value: +{
+  "description": "The pad's own polygon-connect style (Altium: Pad Stack > Thermal Relief), overriding the design rules for how a polygon pour joins the pad. Omit to follow the rules (the default); a key left out takes Altium's default.",
+  "properties": {
+    "air_gap": {
+      "description": "Gap between the pad and the pour in mm. Default: 0.254 (10 mil)",
+      "minimum": 0,
+      "type": "number"
+    },
+    "auto_conductors": {
+      "description": "Let Altium choose the conductor count. Default: false",
+      "type": "boolean"
+    },
+    "conductor_width": {
+      "description": "Width of each relief conductor in mm. Default: 0.254 (10 mil)",
+      "minimum": 0,
+      "type": "number"
+    },
+    "conductors": {
+      "description": "Number of relief conductors. Default: 4",
+      "enum": [
+        2,
+        4
+      ],
+      "maximum": 4,
+      "minimum": 2,
+      "type": "integer"
+    },
+    "min_distance": {
+      "description": "Minimum distance used with auto_conductors when min_distance_enabled is set, in mm. Default: 0.381 (15 mil)",
+      "minimum": 0,
+      "type": "number"
+    },
+    "min_distance_enabled": {
+      "description": "Apply min_distance (Altium's Min Distance checkbox). Default: false",
+      "type": "boolean"
+    },
+    "rotation": {
+      "description": "Conductor angle in degrees. Default: 90",
+      "enum": [
+        45,
+        90
+      ],
+      "maximum": 90,
+      "minimum": 45,
+      "type": "integer"
+    },
+    "style": {
+      "description": "How the pour joins the pad. Default: relief",
+      "enum": [
+        "relief",
+        "direct",
+        "no_connect"
+      ],
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

addedInput schema / properties / footprints / items / properties / regions / items / properties / raw_contours

Added value: +{
+  "description": "Base64 of the region's contour bytes exactly as read_pcblib emitted them (outline and hole vertices). Altium stores a vertex as a double in internal units and a poured polygon's copper sits on fractional ones, so the bytes are replayed while they still describe the vertices above; an edited outline drops them. Pass back unchanged; omit when authoring.",
+  "type": "string"
+}

addedInput schema / properties / footprints / items / properties / vias / items / properties / polygon_connect

Added value: +{
+  "description": "The via's own polygon-connect style (Altium: Pad Stack > Thermal Relief), overriding the design rules for how a polygon pour joins the via. Omit to follow the rules (the default); a key left out takes Altium's default.",
+  "properties": {
+    "air_gap": {
+      "description": "Gap between the via and the pour in mm. Default: 0.254 (10 mil)",
+      "minimum": 0,
+      "type": "number"
+    },
+    "auto_conductors": {
+      "description": "Let Altium choose the conductor count. Default: false",
+      "type": "boolean"
+    },
+    "conductor_width": {
+      "description": "Width of each relief conductor in mm. Default: 0.254 (10 mil)",
+      "minimum": 0,
+      "type": "number"
+    },
+    "conductors": {
+      "description": "Number of relief conductors. Default: 4",
+      "enum": [
+        2,
+        4
+      ],
+      "maximum": 4,
+      "minimum": 2,
+      "type": "integer"
+    },
+    "min_distance": {
+      "description": "Minimum distance used with auto_conductors when min_distance_enabled is set, in mm. Default: 0.381 (15 mil)",
+      "minimum": 0,
+      "type": "number"
+    },
+    "min_distance_enabled": {
+      "description": "Apply min_distance (Altium's Min Distance checkbox). Default: false",
+      "type": "boolean"
+    },
+    "rotation": {
+      "description": "Conductor angle in degrees. Default: 90",
+      "enum": [
+        45,
+        90
+      ],
+      "maximum": 90,
+      "minimum": 45,
+      "type": "integer"
+    },
+    "style": {
+      "description": "How the pour joins the via. Default: relief",
+      "enum": [
+        "relief",
+        "direct",
+        "no_connect"
+      ],
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

Changed3 schema fields changedv1.0.5Sep 16, 2026

addedInput schema / properties / footprints / items / properties / additional_parameters

Added value: +{
+  "description": "The footprint's Parameters keys other than HEIGHT, captured verbatim on read whenever the block is not the plain five-key block this tool writes from scratch: the PATTERN and DESCRIPTION bytes, the UNICODE twins that carry a name or description outside ASCII, the item and revision GUIDs of a managed footprint, a UI-authored AREA, and any key a newer Altium version writes. Each entry is a [key, value] string pair. Pass back unchanged on a read-modify-write so nothing is dropped (a PATTERN, DESCRIPTION or twin that no longer matches the name or description is rebuilt from it); omit when authoring, or to have the block rebuilt in Altium's current shape.",
+  "items": {
+    "items": {
+      "type": "string"
+    },
+    "maxItems": 2,
+    "minItems": 2,
+    "type": "array"
+  },
+  "type": "array"
+}

addedInput schema / properties / footprints / items / properties / height

Added value: +{
+  "description": "Overall component height in mm — Altium's HEIGHT parameter, written as its mil string. Default: 0",
+  "minimum": 0,
+  "type": "number"
+}

addedInput schema / properties / footprints / items / properties / param_key_order

Added value: +{
+  "description": "The footprint's Parameters keys in stored order, as read_pcblib emitted them; the writer replays this order so the block stays byte-faithful. Pass back unchanged; omit when authoring (canonical order).",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

Changed1 schema field changedSep 13, 2026

addedInput schema / properties / footprints / items / properties / storage_name

Added value: +{
+  "description": "The CFB storage the component was read from, as read_pcblib/read_schlib emit it. Pass it back unchanged on a read-modify-write so the component stays where Altium looks for it (Altium re-derives a short name's storage and maps a long one through SectionKeys, so a moved storage is a component it cannot load); omit when authoring or renaming, and the storage name is derived as Altium would: / \\ : ! * become _, then a cut at 31 characters.",
+  "type": "string"
+}

First observedv0.1.0Sep 7, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations carry only destructiveHint=true; the description adds substantial behavior beyond that: append-vs-replace semantics, auto-designator placement (and the read-echo exemption via primitive_order), auto-3D-body extrusion with assumed_height flag, the warnings array flagging silk-on-pad, the mm unit requirement, and the '|' separator restriction. No contradiction with the annotations. It stops short of disclosing failure modes or side effects on read-echoed footprints, but the disclosure is well above baseline.

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?

Roughly seven dense sentences, purpose front-loaded, and every sentence earns its place — append mode, primitives list, mm units, auto-designator with echo exception, bodies/warnings output, and the pipe-character constraint. For a tool authoring footprints across eight primitive types, the length is proportional to complexity, not padded. Slightly long but not bloated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (pads, tracks, vias, fills, arcs, regions, text, component_bodies) and a 100%-coverage schema, the description covers the essentials: output shape (bodies and warnings arrays) despite no output schema, the read-echo exemption, unit and character restrictions, and the standards the AI must apply. Minor gaps remain (no error/validation behavior, no return-value detail), but the schema already carries the heavy load for parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: the mm unit mandate, the AI's responsibility to compute positions/sizes per IPC-7351B, the auto_designator default-true behavior and its read-echo exemption, and the auto_3d_body default-false rationale (fiducials/test points legitimately lack bodies). These enrich the schema's per-parameter notes, which already carry units and defaults. The description compensates the schema rather than repeating it.

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 description opens with a specific verb+resource: 'Write footprints to an Altium .PcbLib file'. It distinguishes from siblings by file type (.PcbLib vs .SchLib for write_schlib, .LibPkg for write_libpkg) and direction (write vs read_pcblib's read). The append flag is named, so an agent can tell this writer apart from related write tools without opening schemas.

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?

The description provides operational guidance: 'set append: true to add to an existing library instead of replacing it', the auto_designator and auto_3d_body toggles, and IPC-7351B as the sizing standard. However, it never explicitly routes to alternatives — it does not say 'use write_schlib for schematic symbols' or 'use update_pad/update_primitive for a single-edit change'. Usage context is implied by the resource type rather than stated as when-not/alternatives.

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

Write a PcbLib

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools