Skip to main content
Glama

app_press_dialog_button

Press a named button in an open Altium dialog by caption, even when the scripting engine is blocked, with irreversible actions gated unless explicitly allowed.

Instructions

Press ONE named button in an open Altium dialog.

The missing primitive. Dialogs could be listed, read and their checkboxes set, but the only code that pressed anything was buried inside a single task-specific driver, so answering an arbitrary dialog meant writing a script.

BY CAPTION, not position. Accelerator ampersands and a trailing ellipsis are ignored, so "Report Changes" finds "&Report Changes...".

IT WORKS WHILE ALTIUM IS BLOCKED, because it addresses the button's window handle over Win32 and never touches the bridge. That is the whole point: when a modal has the scripting engine stuck, this is what gets it unstuck.

IRREVERSIBLE PRESSES ARE GATED. A caption that commits a change order or applies a wizard is refused unless allow_irreversible is set, so a driver walking an unfamiliar dialog cannot execute one by reflex.

For a whole sequence rather than one press, use app_drive_dialogs, which decides each step from what is on screen instead of from a script.

Args: button_caption: the visible caption. dialog_title: substring picking one dialog when several are open. Empty uses the first. allow_irreversible: permit a committing press.

Returns: ok, the dialog and button actually matched, and whether the dialog closed afterwards.

Input Schema

NameRequiredDescriptionDefault
dialog_titleNo
button_captionYes
allow_irreversibleNo

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: it discloses Win32 window-handle addressing, operation while Altium is blocked, caption normalization (ampersands/ellipsis), and the safety gate that refuses committing presses unless allow_irreversible is set.

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 core action and well-structured with Args/Returns sections. Some backstory ('The missing primitive... buried inside a single task-specific driver') and emphasis ('That is the whole point') are less essential, but most text earns its place.

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?

Complete for a three-parameter UI action with an output schema: parameters, matching rules, blocking behavior, irreversible-press policy, and return contents are all covered. An agent has everything needed to call it correctly.

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%, yet the description documents all three parameters: button_caption as the visible caption, dialog_title as a substring selector with an empty-string default, and allow_irreversible as the gate for committing presses. This fully compensates for the absent schema descriptions.

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: 'Press ONE named button in an open Altium dialog.' The contrast with app_set_dialog_control (checkboxes) and app_drive_dialogs (sequences) makes the scope unambiguous even among many UI 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?

Explicitly says to use app_drive_dialogs for a whole sequence rather than one press, and explains that this tool is for the blocked-modal case where the scripting bridge is unavailable. It also states the caption-matching rule and irreversible-press gating, leaving little to infer.

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