eda-agent

Overview Schema Source Related Servers Discussions Admin

app_list_open_dialogs

Identify why the editor bridge is silent by listing open dialogs and checking whether the main window is blocked; returns dialog captions, messages, buttons, and human-action flags.

Instructions

What Altium has on screen, what it says, and if it is stuck.

THE TOOL TO REACH FOR WHEN THE BRIDGE GOES QUIET. A silent bridge looks identical whether Altium is showing a modal, busy compiling, or dead. This answers it directly: blocked is read from the main window being disabled, which is what Windows does while a modal is up, and it works precisely when no other tool can because it does not use the bridge at all. It reads the Win32 process, so a blocked Altium answers it normally.

blocked: false ONLY MEANS THE MAIN WINDOW IS NOT DISABLED. It does not mean the UI is alive. After Altium's UI crashed with the process still running, this was reported reading a live pid, blocked false and no dialogs. When the bridge is silent and this says not blocked, look at the screen before calling it a livelock.

FOR EACH DIALOG you get the caption, the message text, every button with its enabled state, and a kind:

error / warning / confirm -- something went wrong or a decision is being asked. These set needs_a_human.
nothing_to_do -- the operation completed with no work, for instance "Comparator Results (No Differences)" when the schematic and board already agree. A success, not a failure.
engineering_change_order -- an ECO awaiting Validate and Execute.
wizard / progress / unknown.

WHAT IT STILL CANNOT READ. Grids and owner-drawn lists hold their content internally and expose no window text, so an ECO's pending-change list is not readable. That is reported per dialog as has_unreadable_content rather than being passed off as a dialog with nothing in it. Read the Messages panel for the change list.

Reads only. Presses nothing.

Returns: Dict with blocked, dialog_count, dialogs, needs_a_human, and a one-sentence summary.

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.6.1Oct 29, 2026

TDQS

A4.8/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 burden and does so: it discloses that the tool reads the Win32 process rather than the bridge, explains how blocked is derived, and warns that blocked:false does not prove the UI is alive, citing a real failure mode. "Reads only. Presses nothing." gives a clear safety profile, and the has_unreadable_content caveat prevents a false negative interpretation.

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 critical routing sentence is front-loaded, and the dialog kind taxonomy is structured as a scannable list. It is longer than strictly necessary for a no-argument tool, with some repetition around the blocked semantics, but nearly every sentence carries actionable information.

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?

For a diagnostic tool with an output schema, the description covers everything an agent needs: when to call it, how to interpret blocked, what each dialog kind means, what data is missing by design, and what the call does not do. Nothing necessary for correct invocation or interpretation is absent.

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?

Zero parameters, so baseline is 4; nothing in the schema needs interpretation. The description does not need to say more because calling it requires no arguments.

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?

Opens with a concrete verb+resource framing ("What Altium has on screen, what it says, and if it is stuck") and the tool name is immediately grounded in listing open dialogs. It is clearly separable from read-only UI siblings like app_read_window or app_ui_snapshot because it states it bypasses the bridge entirely.

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 TOOL TO REACH FOR WHEN THE BRIDGE GOES QUIET" is an explicit selection rule, and the description explains why other tools cannot serve that case. It also names an alternative path ("Read the Messages panel for the change list") when grid content is unreadable, so the agent knows where to go next.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server