Skip to main content
Glama
embedded-society

altium-designer-mcp

by embedded-society
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

Manage symbol parameters

manage_schlib_parameters
Destructive

List, get, set, add, or delete parameters on an Altium .SchLib symbol. Names match case-insensitively, and changes are backed up before saving.

Instructions

Manage the parameters of one symbol in a .SchLib (Value, Manufacturer, Part Number and the like): list them, get one, set an existing one, add a new one, or delete one. Names match without regard to case, as Altium treats them; set refuses a name the symbol lacks (use add) and add refuses one it already has (use set). Every change backs the library up to a timestamped .bak beside it (the five newest are kept) before saving, and the reply carries the parameter as stored; list returns every parameter with a count. Use get_component or read_schlib to see parameters together with the symbol's pins and graphics, update_component to rewrite a symbol wholesale, and manage_schlib_footprints for footprint links, which are models rather than parameters.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
xNoX position in schematic units (optional for set, add)
yNoY position in schematic units (optional for set, add)
valueNoParameter value (required for set, add)
hiddenNoWhether the parameter is hidden (optional for set, add)
filepathYesPath to the Altium SchLib file
operationYesOperation to perform: list (all parameters), get (single parameter), set (update value), add (new parameter), delete (remove parameter)
unique_idNo8-char Altium unique ID (optional for set, add). Default: auto-generated
param_typeNoParameter type (0=String, 1=Boolean, 2=Integer, 3=Float) (optional for set, add). Default: 0
component_nameYesName of the symbol to manage parameters for
parameter_nameNoName of the parameter (required for get, set, add, delete); matched without regard to case, as Altium treats parameter names
read_only_stateNoRead-only state (0=editable, 1=read-only) (optional for set, add). Default: 0

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already mark this as destructive, but the description goes well beyond them: it discloses automatic timestamped .bak backups keeping the five newest, states that set refuses missing names and add refuses existing ones, and explains the reply carries the stored parameter and that list returns all parameters with a count. No contradiction with annotations.

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

Conciseness5/5

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

The description is long but every clause carries information: operation set, case-insensitivity, duplicate rules, backup behavior, output shape, and sibling routing. The core purpose is front-loaded, and the alternative-tool guidance is compactly placed at the end.

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 multi-operation tool with 11 parameters and no output schema, the description is unusually complete: it explains response contents, list return shape, backup side effects, parameter matching rules, and when each sibling should be used instead. An agent has nearly everything needed to invoke it correctly.

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 adds meaningful operational semantics beyond the schema: case-insensitive name matching, set-vs-add refusal behavior based on existing parameters, and which operations each parameter class applies to. It does not deeply enrich every individual field, but the schema already covers those details.

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: 'Manage the parameters of one symbol in a .SchLib' and enumerates the exact operations (list, get, set, add, delete). It also distinguishes itself from siblings by naming get_component, read_schlib, update_component, and manage_schlib_footprints as alternatives.

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

Usage Guidelines5/5

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

The description explicitly routes the agent to sibling tools and explains why: use get_component/read_schlib to see parameters with pins/graphics, update_component to rewrite a whole symbol, and manage_schlib_footprints for footprint models rather than parameters. It also clarifies when to use set vs add based on whether the parameter already exists.

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