Skip to main content
Glama
embedded-society

altium-designer-mcp

by embedded-society
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

Write a SchLib

write_schlib
Destructive

Writes Altium schematic symbols and their primitives (pins, shapes, text, parameters, footprints) to a .SchLib file, creating a new library or appending to one that exists.

Instructions

Write schematic symbols to an Altium .SchLib file (set 'append': true to add to an existing library instead of replacing it). Each symbol is defined by its primitives: pins, rectangles, round_rects, lines, polylines, polygons, arcs, pies, images, text_frames, beziers, ellipses, elliptical_arcs, labels, and text — plus its designator, parameters (Value, Manufacturer, ...) and footprint links ('footprints', name + optional library_path). Multi-part symbols set 'part_count' and tag each pin with 'owner_part_id'. Coordinates must be in schematic units (10 units = 1 grid square, not mm); a pin's (x, y) is its body-attach end and 'orientation' is the direction it points outward — the response echoes each pin's computed body_end and tip. No text field may contain '|', the separator of Altium's record format; Altium's own editor stores it as '¦' (U+00A6).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
appendNoIf true, append to existing file; if false, create new file
symbolsYesArray of symbol definitions
filepathYesPath to the .SchLib file to create/modify

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.2.0
    • addedInput schema / properties / symbols / items / properties / images / items / properties / image_compressed
      Added value: +{
+  "description": "Set by read_schlib only for an image whose compressed /Storage entry this server would not reproduce (another writer's zlib): the entry exactly as read, reused while it still holds image_data. Pass back unchanged; omit when authoring or replacing an image.",
+  "type": "string"
+}
    • addedInput schema / properties / symbols / items / properties / pins / items / properties / name_code_page
      Added value: +{
+  "description": "Set by read_schlib on a pin a script authored: the ANSI code page its name was widened through, so a rewrite stores the name as Altium did. Pass back unchanged; omit when authoring.",
+  "enum": [
+    874,
+    1250,
+    1251,
+    1252,
+    1253,
+    1254,
+    1255,
+    1256,
+    1257,
+    1258
+  ],
+  "maximum": 1258,
+  "minimum": 874,
+  "type": "integer"
+}
  2. Changed1 schema field changed
    • addedInput schema / properties / symbols / 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"
+}
  3. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true and readOnlyHint=false, but the description adds substantial context beyond them: append:false replaces the file, coordinates are in schematic units not mm, pin (x,y) is the body-attach end with orientation pointing outward, and no text field may contain '|' (with the '¦' workaround). These are real behavioral disclosures an agent must know before authoring.

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?

It is a single dense, front-loaded paragraph: the core action and append behavior come first, followed by primitives, multi-part, units, pin orientation, and the text restriction. No sentence is wasted, though the run-on structure of enumerating all primitives is slightly heavy.

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 very rich schema with no output schema, the description covers the essential behavioral facts an agent needs: file semantics, coordinate system, pin geometry, and text constraints. It even notes the response echoes computed pin body_end/tip, compensating for the absent output schema.

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 description coverage is 100%, so the baseline is 3. The description lifts this by clarifying coordinate units, pin orientation semantics with a concrete example, multi-part handling via part_count/owner_part_id, and the '|' text restriction that the schema does not mention. It adds modest value on top of a schema that already documents most parameters.

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: 'Write schematic symbols to an Altium .SchLib file'. It immediately distinguishes itself from siblings like read_schlib and write_pcblib and clarifies the append-vs-replace mode. An agent can tell what the tool does without opening the schema.

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?

Gives clear context for the append flag ('set append: true to add to an existing library instead of replacing it'), which is the primary when-to-use decision for this tool. It does not name alternative sibling tools (e.g. write_pcblib, update_component) or explicitly state when not to use it, so it stops short of full 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