Skip to main content
Glama

lib_set_footprint_height

Directly sets a footprint's height in millimetres to correct missing or wrong 3D-model values and fix placement-collision DRC results.

Instructions

Set one footprint's Height directly, up or down.

The sweep can only derive a height from a 3D body, which leaves two cases it cannot serve: a part with no model, and a part whose model is wrong. There was no setter at all before this, so a footprint carrying an absurd height could be read and not corrected.

WHY TOO TALL IS WORSE THAN TOO SHORT. Footprint.Height drives placement-collision DRC. A footprint claiming 50mm when the part is 3mm fails against everything near it and blocks placements that are fine. A too-low height only fails to catch a real collision. The first floods the report and gets the rule switched off; the second is quiet.

ZERO IS ACCEPTED AND IS NOT NEUTRAL. It disables the rule for that footprint rather than relaxing it, so nothing is ever flagged against it however tall the real part is. The reply says so when zero is written.

Args: height_mm: the height in MILLIMETRES, not mils. Must be non-negative. footprint_name: which footprint. Empty uses the library's current component.

Returns: {name, old_height_mm, new_height_mm, changed, saved, save_note, note}. saved is always false: the library is modified in memory and left for you to review and save.

Input Schema

NameRequiredDescriptionDefault
height_mmYes
footprint_nameNo

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?

With no annotations, the description carries the full behavioral burden and does so thoroughly: it explains DRC consequences of too-tall vs too-short heights, the non-neutral effect of zero, and that changes are saved only in memory. This is unusually strong disclosure for a mutation tool.

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?

The description is front-loaded and every paragraph has a purpose, but the detailed DRC rationale, while useful, is more verbose than strictly necessary for selecting and invoking the tool.

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?

The description covers the mutation's side effects, edge cases, units, default component behavior, and return semantics. Even though an output schema exists, the returned fields and the important saved=false behavior are summarized enough for an agent to understand the outcome.

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 description coverage is 0%, so the description must compensate. It does: height_mm is explicitly millimetres rather than mils and must be non-negative, while an empty footprint_name is defined as using the library's current component.

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 states a specific verb and resource: set one footprint's Height directly. It also contrasts this with the sweep-based alternative, making the tool's distinct role clear against relevant siblings.

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?

It explicitly explains when this tool is needed: parts with no 3D model or with a wrong model, cases the sweep cannot serve. The alternative behavior of the sweep is described well enough to route correctly.

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