eda-agent

Overview Schema Source Related Servers Discussions Admin

app_ping

Verifies that the eda-agent Altium Designer API script is responding, reports script and server versions, and flags stale cached scripts or units that need recompiling.

Instructions

Test if the Altium script is responding and report script version.

Verifies that:

Altium Designer is running
The Altium_API.PrjScr script is running (StartMCPServer)
File-based communication is working

Also reads SCRIPT_VERSION from the .pas that Altium has compiled and compares it to the version in the bundled on-disk Main.pas. A mismatch means Altium is running a stale cached script: close the script project in the Projects panel and reopen it to recompile. Re-running StartMCPServer does not recompile, and a restart of Altium alone has not always been enough.

SCRIPT_VERSION only speaks for Main.pas. Each unit also reports a stamp that install-scripts writes from its content, and stale_units names any unit whose running compile differs from the files Altium loaded.

Returns: Dictionary with: - success: True if Altium responded - mcp_server_version: version of this eda-agent Python package (from eda_agent.__version__), identifies the MCP server process currently handling tool calls - altium_script_version: version the running script reports (empty string if the script is too old to report it) - bundled_script_version: version of the on-disk Main.pas - version_match: True if Altium matches bundled script version - altium_version: the Altium build itself, as Altium reports it. Reported, never acted on: nothing here refuses to run on an old build, because most of the toolset works on one. It is here because a bug report without it costs a round trip, and twice the answer changed the diagnosis. - message: human-readable status (flags stale cache if detected) - bundled_script_path: the Main.pas that bundled_script_version was read from, so a mismatch can be traced to a file - script_projects_open: the Altium_API.PrjScr paths Altium has open, as the running script reports them (None when it is too old to report them) - script_location_match: True when one of those is in the bundled or the install-scripts folder, False when none is (version_match then describes a file Altium did not load), None when unknown - unit_stamps: each unit's stamp as the running script reports it (None for a script too old to report them) - stale_units: units whose running compile differs from the files in stamps_compared_with; unstamped_units run from copies install-scripts did not stamp - other_servers: other eda-agent servers on this workspace, each with pid and start time - warnings: anything above worth acting on. Warnings only: nothing here refuses or stops anything.

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

A3.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 burden and does so well: it explains that nothing here refuses or stops anything, that warnings are advisory only, that version_match can describe a file Altium did not load, and it names the exact remedy sequence (close/reopen the script project, note that re-running StartMCPServer or restarting Altium may not suffice). It also discloses the known limitation that SCRIPT_VERSION only speaks for Main.pas.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and stale-cache guidance are front-loaded and earn their place, but the bulk of the text is a per-field enumeration of return values that duplicates an existing output schema. The SCRIPT_VERSION/unit-stamp digression is useful but could be compressed.

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?

For a diagnostic tool, the description covers failure modes, cache staleness, and the meaning of ambiguous fields such as script_location_match and stale_units. It is complete on return-value semantics; the only gap is routing guidance relative to sibling diagnostics.

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 the baseline of 4 applies; the schema has nothing that needs semantic elaboration.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific action (test whether the Altium script is responding) and the resource it inspects (Altium Designer, the Altium_API.PrjScr script, file-based comms), plus the version stamp. It does not distinguish itself from nearby siblings like app_get_status, app_get_version, or app_diag_workspace, so the agent must infer which diagnostic to pick.

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

Usage Guidelines3/5

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

The three numbered verifications and the stale-cache advice imply this is the first-line health/diagnosis call, but the description never says 'use this before X' or 'prefer app_get_version for Y'. No alternative is named despite several plausible siblings.

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

Deploy Server