Skip to main content
Glama

Update a primitive

update_primitive
Destructive

Update specific properties of a primitive (track, arc, text, fill, region, or via) in a PcbLib footprint by type and index, applying only the fields you specify.

Instructions

Update specific properties of a primitive (track, arc, text, fill, region or via) in a PcbLib footprint. Find the primitive by type and index (its position in read_pcblib's list for that type), apply only the specified updates. Moving a primitive to another layer drops the layer carriers it was read with (a region's v7_layer, an unmapped raw_layer_id) so the new layer's own token is written. On a stacked via (diameter_stack_mode other than simple) a diameter change also reaches per_layer_diameters: layers that shared the old diameter follow it, layers with their own value keep it, and the response reports how many followed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
indexYesZero-based index of the primitive within its type array
dry_runNoIf true, show what would change without saving (default: false)
updatesYesProperties to update (only specified properties are changed). Valid properties depend on primitive_type — track: x1, y1, x2, y2, width, layer; arc: x/x1, y/y1, radius, start_angle, end_angle, width, layer; text: x, y, height, rotation, text, layer; fill: x/x1, y/y1, x2, y2, rotation, layer; region: layer; via: x, y, diameter, hole_size, from_layer, to_layer. Any other key is refused.
filepathYesPath to the .PcbLib file
component_nameYesName of the footprint containing the primitive
primitive_typeYesType of primitive to update. Addressed by `index` into that primitive list. Pads are not here — they have a designator, so use update_pad.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv0.1.0

TDQS

A5/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=true), the description discloses important side effects: moving a layer drops its associated carriers, and changing a stacked via diameter propagates to per-layer diameters and reports the count. This provides transparency beyond the basic hints.

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 concise yet packed with essential behavior details, structured logically: first the core action, then layer-carrier consequence, then via diameter nuance. No redundant sentences.

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?

Given the complexity (six primitive types with differing properties, dry_run option, layer carrier implications), the description covers all necessary context for correct invocation. It even hints at output behavior for via diameter updates, and the absence of an output schema is not a gap.

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?

Although the schema already provides per-property descriptions, the description adds crucial context by listing which properties are valid for each primitive_type and stating that any other key is refused. This significantly enhances semantic clarity and reduces misuse.

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 clearly states the tool updates specific properties of a primitive in a PcbLib footprint, identifying the resource and action. It distinguishes itself from update_pad by explicitly stating pads are not handled here and should use update_pad.

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 explains how to locate a primitive via read_pcblib's index and explicitly directs pad updates to update_pad. It also details conditional behaviors (layer move dropping carriers, via diameter propagation) which guide usage.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/embedded-society/altium-designer-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server