Skip to main content
Glama

pcb_set_rules_enabled

Bulk-toggle DRC-enabled flags on PCB design rules by name, wildcard, or kind to silence noisy rule classes during focused reviews and re-enable them before a release sweep.

Instructions

Bulk-toggle the DRC-enabled flag on design rules by name.

Useful for focused review passes: disable a noisy class of rules to surface the violations that matter (e.g. silence Silk-to-Silk while you sweep Clearance), or re-enable a set before a release sweep. Matches case-insensitively; supports trailing-* wildcards so a rule family can be targeted without listing every name ("DiffPair_*" hits every rule whose name starts with that).

Note that this flips DRCEnabled (whether DRC actually checks the rule), not Enabled (whether the rule exists in the rule list); the former is the right knob for review iteration.

Args: names: Rule names to toggle. With match="name" (default) each entry is matched case-insensitively against Rule.Name; a trailing * wildcards the suffix ("Clearance*"). With match="kind" each entry is a TRuleKind ordinal as a string (look up via pcb_get_design_rules). enabled: New value for DRCEnabled. True turns the rule ON in DRC; False disables it for this run. match: "name" (default) or "kind".

Returns: Dict with: - matched: rules that matched any pattern - updated: how many actually changed value - enabled: the requested target value (for confirmation) - items: per-matched {name, kind, prev_enabled, new_enabled}

Input Schema

NameRequiredDescriptionDefault
matchNoname
namesYes
enabledYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.1

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it states what flag is changed, clarifies the DRCEnabled versus Enabled distinction, explains case-insensitive and wildcard matching, and describes the return dictionary. It does not discuss permissions, persistence, or undo behavior, which are relevant 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 well structured and front-loaded with the core purpose, followed by usage rationale, caveat, args, and returns. It is somewhat long but every section is relevant; minor examples and return details add useful context rather than fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a mutation tool with no annotations, three parameters, zero schema description coverage, and an output schema, the description is nearly complete. It covers purpose, usage, parameters, return values, and a key behavioral caveat. It could mention authorization or persistence but is otherwise sufficient.

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, and it does thoroughly. The Args section documents each parameter: names matching with wildcard and match-mode behavior, enabled as the target DRCEnabled value, and match accepting 'name' or 'kind' with defaults and lookup guidance.

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 begins with a specific verb and resource: 'Bulk-toggle the DRC-enabled flag on design rules by name.' It clearly distinguishes this operation from related rule management by explaining that it flips DRCEnabled rather than Enabled. This lets an agent identify the tool without ambiguity.

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

Usage Guidelines4/5

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

It gives clear usage context: 'Useful for focused review passes...' with examples like silencing Silk-to-Silk or re-enabling rules before a release sweep. However, it does not explicitly name when not to use this tool or point to a specific sibling alternative such as pcb_set_rule_properties.

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