Skip to main content
Glama
embedded-society

altium-designer-mcp

by embedded-society
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

Write a SchLib

write_schlib
Destructive

Write schematic symbols to Altium .SchLib files by defining pins, shapes, parameters and footprint links. Append to an existing library or create a new one.

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. 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"
+}
  2. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, openWorldHint=false, and readOnlyHint=false. The description adds valuable specifics: the '|' character restriction in text fields, coordinate units (10 units = 1 grid square), pin body_end/tip echo behavior, and the distinction between append and replace. It does not explicitly warn about overwriting existing content when append=false, but the append note conveys the replace semantics.

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?

The description is a dense paragraph of about 200 words. It front-loads the core purpose and append semantics, but the second half packs several distinct concepts (units, pin geometry, separator restriction) into one long sentence, which reduces readability and may bury the most critical operational constraints.

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 a 3-parameter tool with 100% schema coverage and no output schema, the description covers the essential operational context: file format, append behavior, coordinate system, pin orientation, multi-part handling, and a key text constraint ('|'). It omits explicit mention of what happens to an existing file when append=false (though implied) and does not list all supported primitive types in the schema scope, but the schema enumerates them.

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. The description goes beyond the schema by explaining coordinate systems ('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'), the '|' separator constraint not in the schema, and the multi-part design pattern (part_count + owner_part_id).

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 clarifies the file format and the append-vs-replace semantics, distinguishing it from read_schlib (read) and write_pcblib (PCB footprints).

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 explains the append flag's effect, which implicitly signals when to use the tool versus alternatives, but it does not explicitly state when to choose this over write_libpkg or import_library, nor does it warn about the destructiveHint=true behavior (overwrite) beyond the append note.

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