depot-mcp

Overview Schema Source Related Servers Discussions Admin

Compare two Depot CI runs

depot_compare_ci_runs

Read-onlyIdempotent

Compare two CI runs side-by-side to reveal regressions, new failures, and performance changes between commits. Pinpoint status shifts, slower jobs, memory changes, and which failures are new or fixed.

Instructions

Compare two Depot CI runs side by side: which jobs changed status, got slower or faster, used more memory, appeared or disappeared, and which failures are new in the second run versus fixed since the first.

Use this when the question is about the difference between two runs rather than one run on its own: "what regressed between these two commits", "is this failure new or was it already broken on main", "did the retry fail the same way" (a flaky failure produces a different error message across runs; a deterministic one repeats), or "why is this run slower than the last one".

runA is the baseline (older, or known-good) and runB is the run under question; deltas read B minus A. Jobs are matched by their job key, so both runs should come from the same workflow or the matrix will be mostly "only in A" and "only in B". Failure fingerprints come from Depot's failure analysis and are only fetched for the sides that actually failed.

For a single run, use depot_diagnose_ci_failure instead: it explains the failure with diagnosis, suggested fix, and evidence lines, none of which this tool returns.

Input Schema

TableJSON Schema

Name	Required	Description
`runA`	Yes	Baseline run id (the older or known-good run), as returned by depot_list_ci_runs.
`runB`	Yes	Run id to compare against the baseline (the newer or suspect run). Deltas are B minus A.
`maxJobs`	No	Cap on job matrix rows. Rows that changed (status or presence) are kept first.
`includeDiagnosis`	No	Fetch Depot failure analysis for each failed side to list failures new in B and resolved in B. Set false to compare only status, timing, and memory.

Output Schema

TableJSON Schema

Name	Required	Description
`jobs`	Yes
`runA`	Yes
`runB`	Yes
`notes`	Yes
`metrics`	Yes	Whether GetRunMetrics answered for each side.
`onlyInA`	Yes
`onlyInB`	Yes
`failures`	Yes
`diagnosis`	Yes	Whether a failure diagnosis was fetched for each side.
`truncated`	Yes
`jobsOmitted`	Yes	Rows dropped by maxJobs; changed rows are kept first.
`jobsReturned`	Yes
`statusChanges`	Yes
`contentWarning`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.2.1Sep 8, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description discloses key behavioral details: deltas are read as B minus A, jobs are matched by job key, mismatched workflows yield mostly 'only in A'/'only in B' rows, and failure fingerprints are fetched only for sides that actually failed. It also states the tool returns no diagnosis, suggested fix, or evidence lines, which is important behavioral context.

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

Conciseness5/5

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

The description is longer than average, but every sentence earns its place: a front-loaded summary, usage examples, parameter/direction semantics, a matching caveat, and an explicit sibling alternative. It is well-structured into four focused paragraphs with no fluff or repetition of schema boilerplate.

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?

Given the tool's moderate complexity and the presence of a rich output schema plus full parameter descriptions, the description covers all necessary operational context: when to use it, how runs are matched, direction of deltas, failure-fingerprint behavior, and how it differs from the diagnostic sibling. Nothing essential is missing for an agent to select and call it correctly.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful semantics beyond the schema: it explains that jobs are matched by job key, warns that both runs should come from the same workflow or the matrix will be mostly 'only in A'/'only in B', and clarifies the runA/runB direction with 'deltas read B minus A'. This materially helps an agent invoke the parameters correctly.

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 description uses a specific verb ('Compare'), names the resource ('two Depot CI runs'), and enumerates the exact dimensions compared (status, timing, memory, presence, failures). It also explicitly distinguishes itself from the sibling depot_diagnose_ci_failure by stating what this tool does not return, making selection unambiguous.

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?

It gives explicit when-to-use guidance with concrete example questions ('what regressed between these two commits', 'is this failure new or was it already broken on main') and an explicit when-not-to-use statement pointing to depot_diagnose_ci_failure for single-run diagnosis. This leaves no ambiguity about tool selection.

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