Skip to main content
Glama

pcb_get_rule_properties

Read a named PCB design rule to retrieve its metadata and human-readable constraint descriptor; clearance rules also return gap_mm for numeric clearance checks.

Instructions

Read properties of a named PCB design rule.

Returns metadata (name, rule_kind, enabled, priority) plus a descriptor string that contains the rule's constraint values in human-readable form, e.g.:

"Width Constraint (Min=0.102mm) (Max=5.08mm) (Preferred=0.127mm) (All)"
"Clearance Constraint (Gap=0.127mm) (All),(All)"
"Hole Size Constraint (Min=0.1mm) (Max=4mm) (All)"
"Routing Via (Templates Used To Check Via: v30h10m0mx0, ...) (All)"

WHY THE DESCRIPTOR AND NOT THE NUMBERS. Constraint values live on per-kind subtype interfaces (IPCB_ClearanceConstraint, IPCB_MaxMinWidthConstraint, ...). This handler holds a base IPCB_Rule, where those members do not exist, so reading them gives nothing and the descriptor is what is offered instead. Parse it client-side if you need numeric values.

THAT IS A LIMIT OF THIS READ, NOT OF THE API, and the difference matters because the sentence above has already been read as "constraints are unreachable" and stopped someone who then reported a rule as unwritable. DelphiScript DOES narrow an interface, but only at iterator return, so a typed local assigned straight from BoardIterator.FirstPCBObject reaches the constraint members. pcb_set_rule_properties writes them that way. To CHANGE a value, use that tool. obj_modify will not do it: it dispatches through the base reference and reports a match while changing nothing.

A clearance-family rule also returns gap_mm, read from the rule itself; for Board Outline Clearance the descriptor says Gap=0mil whatever the rule holds, so read gap_mm.

Args: name: Design rule name (e.g., "Clearance", "Width", "RoutingVias").

Returns: Dict with name, rule_kind, enabled, priority, descriptor, and gap_mm for a clearance-family rule.

Input Schema

NameRequiredDescriptionDefault
nameYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.1

TDQS

A4.8/5.0
Behavior5/5

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

No annotations exist, so the description carries the full burden and does so: it discloses that constraint values are only available as a parseable descriptor string, why (base IPCB_Rule vs. per-kind subtypes), and the Board Outline Clearance edge case where the descriptor reports Gap=0mil and gap_mm must be read instead. It also preempts a real misreading that caused a false 'rule is unwritable' report.

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?

Purpose is front-loaded, and the descriptor examples are genuinely load-bearing. The middle section is somewhat editorial ('that sentence has already been read as...'), spending several lines on the history of a misunderstanding where one sentence about DelphiScript interface narrowing would suffice.

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?

An output schema exists, yet the description still adds value by explaining the descriptor's human-readable format and the gap_mm special case, which are semantic details a schema cannot convey. For a one-parameter read tool, nothing an agent needs in order to call it or interpret the result is missing.

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 0%, so the description must compensate; the Args section defines the single parameter as the design rule name and gives concrete example values ('Clearance', 'Width', 'RoutingVias'). It does not mention how to enumerate valid names (e.g., via pcb_get_design_rules), which is the one remaining gap for a name-keyed lookup.

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?

Opening line states a specific verb and resource: 'Read properties of a named PCB design rule.' It also enumerates what is returned (name, rule_kind, enabled, priority, descriptor), which separates it cleanly from the list-oriented sibling pcb_get_design_rules and the write-oriented pcb_set_rule_properties.

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 routes the agent: 'To CHANGE a value, use that tool' (pcb_set_rule_properties) and warns 'obj_modify will not do it: it dispatches through the base reference and reports a match while changing nothing.' That is a rare, concrete when-not-to-use with a named alternative.

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