Skip to main content
Glama

sch_mirror_component

Mirror a placed schematic component horizontally by reflecting its primitives and setting the IsMirrored flag, so the part actually flips on the canvas and survives library updates.

Instructions

Mirror a placed schematic component horizontally.

USE THIS RATHER THAN WRITING IsMirrored. Setting that property with obj_modify does not mirror anything: measured on AD26, the flag is set, it reads back, Altium's own Properties panel shows Mirrored ticked, and the part does not move. The canvas draws from the component's primitives, so a flag-only write leaves nothing new to draw and no redraw call can rescue it.

Altium's own mirror does both halves at once, setting the flag AND reflecting the primitives, and so does this. That matters twice over: a part mirrored here is identical on disk to one mirrored by hand, and the flag is instance data, so the result survives Update From Libraries. Reflecting the primitives alone would be undone the next time anyone re-instantiates the symbol.

Args: designator: component to mirror, e.g. "U1" mirrored: True or False for an absolute state; omit to toggle. Asking for the state it already has is a no-op, not a second reflection. doc_path: sheet to act on. Defaults to the focused schematic.

Every primitive is reflected about the component's X: pins (left and right swap), lines and rectangles by both ends, polygons, polylines and Beziers by every vertex, and arcs by their centre with their sweep mirrored. A primitive kind it cannot reflect is left where it was and counted in primitives_skipped.

Returns: Dictionary with designator, mirrored (the resulting state), primitives_moved, primitives_skipped, and changed.

Input Schema

NameRequiredDescriptionDefault
doc_pathNo
mirroredNo
designatorYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.1

TDQS

A4.9/5.0
Behavior5/5

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

No annotations are provided, and the description carries the full burden well: it discloses mutation semantics (flag plus primitive reflection), idempotency ('asking for the state it already has is a no-op'), persistence across Update From Libraries, and degraded behavior via primitives_skipped. It also lists exactly which primitive kinds are reflected and how.

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?

Front-loaded with the action, then rationale, then args, then returns — good structure. Some redundancy ('That matters twice over', the extended AD26 war story) that could be tightened without losing information.

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?

A mutation tool with no annotations and a zero-coverage schema is fully covered: rationale, parameter semantics, edge cases, and an enumerated return dictionary (designator, mirrored, primitives_moved, primitives_skipped, changed). Nothing an agent needs in order to call it correctly is missing.

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?

Schema coverage is 0%, so the description must compensate, and it does: designator is exemplified ('U1'), mirrored is defined as absolute state with omit-means-toggle and no-op semantics, and doc_path is given a default ('focused schematic'). All three parameters carry meaning absent from the schema.

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 (mirror a placed schematic component, horizontally) and immediately distinguishes itself from the sibling obj_modify path by explaining why this tool exists. An agent can select it without opening any schema.

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?

Explicitly says 'USE THIS RATHER THAN WRITING `IsMirrored`' with obj_modify named as the wrong alternative and the empirical reason it fails. It also covers the mirrored parameter's three usage modes (true/false/omit for toggle), leaving nothing to inference.

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