Skip to main content
Glama

proj_run_outjob_all

Runs every OutJob container in order and reports its output. It flags files newly produced during each run so callers can tell which container wrote them.

Instructions

Run every container in an OutJob and report what each produced.

Lists containers via proj_list_outjob_containers, then runs each through proj_run_outjob in order. For each run, scans the OutJob's resolved output_dir afterwards and flags files whose mtime is later than the run started (newly_produced) so the caller can tell which files this particular container wrote.

Args: outjob_path: Path to the .OutJob. Omit to use the first one in the focused project. include_files: When True (default) the response includes a per-container file listing with sizes / mtimes / a newly_produced flag. fresh_window_seconds: Files modified within this many seconds before the container started are still considered "newly produced" (some output processes touch existing files instead of rewriting). Default 5s.

Returns: Dict with ok, outjob_path, containers_run (list of container names), results (per-container dicts each with container, container_type, output_dir, ok, files).

Input Schema

NameRequiredDescriptionDefault
outjob_pathNo
include_filesNo
fresh_window_secondsNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.1

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden and does well: it discloses ordering, output directory scanning, mtime-based `newly_produced` detection, and the `fresh_window_seconds` rationale. It does not describe failure handling (e.g., whether later containers still run after one fails) or permission/side-effect implications of running output jobs.

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 behavior and then structured into Args and Returns. It is somewhat long and repeats return-value details already available in the output schema, but every section still adds practical meaning for invocation.

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?

Given a multi-step tool with three parameters and an output schema, the description covers purpose, sequencing, parameter semantics, and return structure. The main remaining gap is failure/partial-success behavior, which matters for a batch execution tool but is not addressed.

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%, so the description must compensate fully, and it does: it explains `outjob_path` including the omit-to-use-focused-project behavior, `include_files` and its default, and the precise meaning of `fresh_window_seconds` with its default and rationale.

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: runs every container in an OutJob and reports each container's output. It also names the sibling orchestration tools (`proj_list_outjob_containers`, `proj_run_outjob`) and distinguishes the batch behavior from single-container runs.

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?

Clearly explains that this tool runs all containers and that it first lists containers then delegates each run. The alternative single-container tool is named, but the description does not explicitly state when to choose this batch tool versus `proj_run_outjob` or when not to use it.

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