Skip to main content
Glama

pcb_apply_dnp_paste_exclusion

Suppress stencil paste on Not-Fitted (DNP) components by collapsing surface pad apertures, preventing paste deposits on empty pads and bridging rework.

Instructions

Suppress stencil paste on Not-Fitted (DNP) components.

The remediation half of audit_variant_not_fitted. A Not-Fitted component is on the BOM as a placeholder and must NOT receive paste: the SMT line would otherwise deposit paste on empty pads, and the bridging that follows shows up as rework.

With no designators this asks audit_variant_not_fitted for the components Not Fitted in the project's CURRENT variant, so the selection follows the variant you actually have open. Pass an explicit list to override that.

Mechanism: each surface pad gets a manual PasteMaskExpansion of minus its larger dimension, which collapses the stencil aperture whatever the pad shape. Through-hole pads are left alone and counted separately, since they have no aperture to suppress.

Reversible: restore=True discards the manual override so Altium recomputes the expansion from the design rules.

RESTORE THE SAME LIST YOU APPLIED. restore will NOT guess: called without designators it refuses and tells you what to pass. That is deliberate. Resolving a restore from the current variant means excluding under one variant, switching, then restoring, and leaving any component that was excluded but is fitted in the new variant with its aperture still suppressed. Nothing would report it: the call succeeds, the pad looks ordinary in the editor, and the part comes back from assembly unsoldered.

The apply reply lists every component it touched in items. Pass those designators back to restore. If you really do want the current variant's Not-Fitted list, ask for it with use_current_variant=True and you own the choice.

Apply is unaffected: with no designators it uses the current variant's Not-Fitted list, which is the whole point of applying.

Mismatch is visible either way. components_requested versus components_matched in the reply reports how many of the names you passed were actually found on this board.

Args: designators: Components to treat. Omit on an apply to use the current variant's Not-Fitted list. Required on a restore unless use_current_variant is set. restore: Undo a previous exclusion instead of applying one. dry_run: Report which components WOULD be treated and change nothing. Worth using first: this edits the board, and a wrong variant selection would strip paste off parts that are meant to be fitted. use_current_variant: Allow a restore with no designators to resolve from the variant open right now. Off by default because that is the failure above.

Returns: Dict with restored, components_requested, components_matched, pads_changed, pads_skipped_through_hole and per-component items. In dry-run mode: dry_run, designators and source. On a refused restore: {"ok": False, "reason": ...} and nothing is read from or written to the board.

Input Schema

NameRequiredDescriptionDefault
dry_runNo
restoreNo
designatorsNo
use_current_variantNo

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 the paste-mask mechanism, that through-hole pads are skipped, that the action is reversible via `restore=True`, that refused restores do not touch the board, and the risk of stripping paste from fitted parts under the wrong variant. It also describes the apply reply and dry-run reply shapes, which is unusually complete 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 with a front-loaded purpose, mechanism, usage rules, Args, and Returns. It is longer than strictly necessary and repeats some apply-versus-restore warnings, but the length is mostly justified by the safety-critical restore behavior and the lack of schema descriptions.

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 high complexity, absence of annotations, zero schema description coverage, and four parameters, the description is complete enough for correct invocation. It covers mechanism, variant sourcing, restoration risk, dry-run behavior, return fields, refusal behavior, and mismatch reporting; the output schema exists but the description still adds useful return-value context.

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 for all four parameters, and it does: `designators`, `restore`, `dry_run`, and `use_current_variant` each get semantic explanations including defaults, required combinations, and consequences. This is substantially more than the bare schema provides.

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 first sentence names a specific verb and resource: suppressing stencil paste on Not-Fitted components. It also distinguishes itself from the related `audit_variant_not_fitted` tool by calling itself the remediation half, so an agent can tell its role apart from the audit sibling.

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 gives explicit operating guidance: omit `designators` to use the current variant's Not-Fitted list, pass a list to override, use `dry_run` first, and restore only with the same list that was applied. It also names `audit_variant_not_fitted` as the source for the default selection and explains why a restore without designators is refused.

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