Skip to main content
Glama

proj_run_outjob

Execute a named container from an OutJob file to generate fabrication, BOM, or PDF outputs and verify that files were written.

Instructions

Execute a specific output container from an OutJob file.

First use proj_list_outjob_containers to list available containers, then run the desired one by name. Supports both GeneratedFiles (Gerber, drill, BOM, etc.) and Publish (PDF) container types.

SUCCESS MEANS A FILE WAS WRITTEN. Running a container proves only that Altium was asked to. One bound to a managed release, or with its outputs switched off, runs cleanly and writes nothing, and this used to report success: true with an output_dir that had never been created. output_dir is now checked afterwards, and success is true only when a file under it was written or changed after the run started.

That check covers output_dir and nothing else. A container that writes somewhere else reads as success: false, and reason says what was examined, so a caller who knows where the output really goes can look there.

Args: container_name: Name of the output container to execute outjob_path: Path to the .OutJob file. If omitted, uses the first OutJob found in the focused project. fresh_window_seconds: files modified up to this many seconds before the run started still count as written, for file systems with coarse timestamps. Default 5s.

Returns: success, container_name, container_type, output_dir, output_dir_exists, files_written (a count), written (up to 50 paths), and reason when nothing was written.

Input Schema

NameRequiredDescriptionDefault
outjob_pathNo
container_nameYes
fresh_window_secondsNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.1

TDQS

A4.5/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 it does so unusually well: it states that success means a file was written, explains that Altium being asked to run proves nothing, and describes the output_dir existence/freshness check. It also discloses the check's exact limitation, namely that containers writing outside output_dir report success=false, and it names the reason field that explains what was examined.

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 most important point, that success means a file was written, is front-loaded right after the workflow line, and the Args/Returns blocks are scannable. The bug-history digression about a past false success is a touch indulgent and could be one sentence shorter, but it earns its place by justifying the success contract.

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 three-parameter execution tool with no annotations and an output schema, this covers everything an agent needs: the prerequisite listing call, the parameter meanings and defaults, and the exact interpretation of success, output_dir, and files_written. The return fields are enumerated, so the agent can reason about partial or negative results.

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 Args block is doing all the work, and it delivers for all three parameters. outjob_path gets a real default behavior (first OutJob in the focused project), and fresh_window_seconds gets both a default and a rationale (coarse file-system timestamps). container_name is the only thin entry, but its link to the listing tool compensates.

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?

The first sentence names a specific verb and resource: execute an output container from an OutJob file. It also clarifies scope by naming the two container types supported (GeneratedFiles and Publish). It does not explicitly distinguish itself from the closely named siblings proj_run_output and proj_run_outjob_all, leaving that inference to the reader.

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 gives an explicit prerequisite workflow: call proj_list_outjob_containers first, then run a container by name. The long paragraph on success semantics also implicitly tells callers when interpreting a result is risky. There is no explicit 'do not use this when...' guidance, and the 'run all containers' alternative (proj_run_outjob_all) is never mentioned.

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