eda-agent

Overview Schema Source Related Servers Discussions Admin

proj_close

Closes a PCB project, optionally saving modified documents or discarding unsaved edits, and handles save prompts so the editor bridge does not block.

Instructions

Close a project, saving its documents or discarding their edits.

save=True (default) writes this project's modified documents, then closes it. save=False closes it without saving.

WITHOUT SAVING, TWO LAYERS KEEP THE BRIDGE FROM WEDGING. A close with a modified member raises Altium's save prompt inside the polling loop, where the bridge cannot answer it. MEASURED on AD 26.10.1.6: after an edit IServerDocument.Modified reads False while the tab shows the sheet modified, so nothing gated on that read works.

First, the handler clears the modified flag on every loaded member without reading it. MEASURED on a local scratch project: the close then raised no prompt and the file on disk was byte-identical.

Second, if a prompt appears anyway, this answers it through UI Automation: "Save None", then "OK" once the dialog has retitled to "Confirm Not Saving", which is what shows the decisions changed. Pressing OK before that would save. The sequence was measured by hand; this tool running it has not run live.

ALTIUM CLOSES THE FOCUSED PROJECT. MEASURED: a close naming a project with no loaded document, while another project's board was focused, closed that other project first. So the handler makes the named project focused by showing one of its loaded documents, and refuses, changing nothing, when it cannot. Every attempt compares the open projects before and after: if anything else closed, it stops without retrying and returns those paths as closed_instead, with success false.

IT ANSWERS ONLY FOR THIS PROJECT. It records the project's member paths before closing and reads every path the prompt lists. If any listed document is outside the project it presses nothing and returns them, because answering would discard work in a project nobody named. It also presses nothing when membership cannot be established: no project_path, or a deployed script that reports member file names rather than paths.

A document shared with another open project is a member of both, so its unsaved edits are discarded here too. save=True prompts are never answered for you.

IF A PROMPT IS LEFT OPEN, answer it with app_invoke_element (Save None, then OK) or app_press_dialog_button. Both work while the bridge is blocked, because they go through Win32 rather than through the loop.

Args: project_path: project to close. Omit for the focused project; save=False then leaves any prompt for a human. save: write modified documents first (True), or discard their unsaved edits (False).

Returns: success and closed, checked by looking the project up again, and project_path. When a prompt was answered, prompts_answered and discarded, the paths it listed. When one was left, prompt and reason: the bridge stays blocked until it is answered. Without a prompt, discarded lists the loaded members closed without saving and attempts how many closes it took. The modified flag cannot be read reliably, so a path in discarded is not proof that document had edits.

Input Schema

Name	Required	Description	Default
`save`	No
`project_path`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.6.1Oct 29, 2026

TDQS

A4.6/5.0

Behavior5/5

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

No annotations exist, so the description carries the full burden and does so: it discloses that a modified member raises a save prompt inside the polling loop, the measured failure of IServerDocument.Modified, that the focused project is what actually closes, that non-member documents are refused, that shared documents lose their edits here, and that save=True prompts are never auto-answered. These are exactly the side effects and safety limits an agent cannot infer from the schema.

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 core behavior is front-loaded, but the body runs long with repeated ALL-CAPS headers, version strings, and several 'MEASURED on ...' anecdotes that could be compressed. Much of it earns its place, yet the density and formatting make it slower to scan than necessary.

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?

Even though an output schema exists, the description ties return fields (success, closed, closed_instead, prompts_answered, discarded, prompt, attempts) to the behaviors that produce them, including the caveat that a path in discarded is not proof of edits. For a destructive, prompt-prone operation, nothing an agent needs to call it safely is missing.

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 coverage is 0% and the schema shows only a bare boolean and nullable string, so the description must supply all meaning — and the Args block does: save writes modified documents or discards unsaved edits, project_path omits to focused and interacts with save=False to leave the prompt for a human. Both parameters are fully disambiguated.

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 opening sentence names a specific verb and resource ('Close a project') and immediately splits the two modes (save vs. discard edits). It is unmistakable against siblings like app_close_document or proj_save, and the later discussion of focusing/refusal semantics confirms the exact scope of the operation.

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 tells the agent when save=True applies, that omitting project_path targets the focused project (and that save=False then leaves the prompt for a human), and names concrete fallbacks (app_invoke_element, app_press_dialog_button) when a prompt is left open. What it lacks is an explicit contrast with the nearest alternative, app_close_document, which shares the 'close something' surface.

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

Deploy Server