depot-mcp

Overview Schema Source Related Servers Discussions Admin

Get Depot CI job logs

depot_get_ci_logs

Read-onlyIdempotent

Fetch a bounded slice of persisted Depot CI job logs for full tracebacks, step output, or specific patterns. Filter by step, stream, or substring, and page forward to follow a running job.

Instructions

Fetch a bounded slice of the persisted logs for a Depot CI job attempt.

Try depot_diagnose_ci_failure first. It is cheaper, it already contains the relevant log lines with a diagnosis attached, and it identifies which job actually broke. Use this tool when you need detail the diagnosis did not include: the full traceback, output from a step that did not fail, or a specific pattern.

Defaults to the last 200 matching lines, because failures land at the end of a log. "grep" (case-insensitive substring, not a regex), "stepKey" and "stream" are applied by this server after it fetches pages from Depot, so they reduce what you receive but not what is read: a grep still walks the log page by page, up to DEPOT_MCP_MAX_LOG_PAGES pages (default 20), and is the most expensive way to use this tool. Prefer stepKey or stream, which at least keep the returned window small.

"id" accepts an attempt id, a job id, or a run id. Given a run id this picks that run's failed job (or its last job) and reads the latest attempt, mirroring what "depot ci logs" does.

Paging contract:

Without a pageToken you get the tail: the last "tailLines" matching lines of what was read. If the page cap stops the walk first, the result says so, the lines are the end of what was read rather than the end of the log, and nextPageToken continues forward from there.
With a pageToken you get the next window forward: up to "tailLines" lines in order from that point, and a new nextPageToken if more remain. Nothing in a forward window is ever dropped for the character budget; the window just closes early and the token resumes at the exact next line, so following nextPageToken until it is absent yields every line exactly once. That is how to follow a running job's output across turns.
Pass tokens back verbatim. Some are issued by this server rather than Depot; both are opaque.
Each line body is capped at 2000 characters ("bodyTruncated" marks the ones that were cut).

Input Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	An attempt id, job id, or run id. Attempt ids give the most precise result.
`grep`	No	Case-insensitive substring filter applied to line bodies by this server after fetching. Not a regular expression.
`stream`	No	Keep only one output stream. stderr alone is often enough to spot a failure.
`stepKey`	No	Keep only lines from this step, as reported in a line's stepKey.
`pageToken`	No	Continue forward from a previous nextPageToken instead of returning the tail. Use this to poll a running job or to read a log from the start.
`tailLines`	No	Maximum log lines per call: the last N of what was read without a pageToken, the next N forward with one.
`targetType`	No	What "id" refers to. Omit to let the server work it out.
`includeTimestamps`	No	Prefix each rendered line with its ISO timestamp. Costs context; usually not needed.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`lines`	Yes
`notes`	Yes
`target`	Yes
`truncated`	Yes
`pageCapHit`	Yes
`linesMatched`	Yes
`pagesFetched`	Yes
`linesReturned`	Yes
`nextPageToken`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.2.1Sep 8, 2026
- addedOutput schema / properties / lines / items / properties / stepName
```
Added value: +{
+  "type": "string"
+}
```
First observedv0.1.0Sep 5, 2026

TDQS

A5/5.0

Behavior5/5

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

The annotations already declare readOnlyHint and idempotentHint, but the description adds substantial behavioral context beyond that: the paging contract, tail vs forward window semantics, page cap behavior, server-side filtering versus what is actually read, body truncation at 2000 characters, and opaque token handling. This fully discloses how the tool behaves at the edges.

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 long but every section earns its place: purpose, routing to a cheaper alternative, filter semantics, ID polymorphism, and a detailed paging contract. It is front-loaded with the most important guidance and organized so an agent can quickly extract the key constraints without parsing fluff.

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 tool with 8 parameters, a paging contract, and ambiguous ID types, the description covers everything needed to call it correctly: default behavior, page limits, continuation tokens, line truncation, and cost guidance. Since an output schema exists, the description is not required to document return values, and nothing essential 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?

Although schema coverage is 100%, the description adds meaning the schema alone does not convey: id accepts attempt, job, or run IDs with a defined fallback; grep is a case-insensitive substring, not a regex; pageToken continuation semantics; and the cost implications of grep versus stepKey or stream. This is exactly the kind of parameter knowledge an agent needs to invoke the tool 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?

States a specific verb and resource ('Fetch a bounded slice of the persisted logs for a Depot CI job attempt'), and immediately distinguishes itself from depot_diagnose_ci_failure by naming the sibling and explaining when that tool should be used instead. This makes the tool's scope unmistakable.

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?

Provides explicit when-to-use and when-not-to-use guidance: 'Try depot_diagnose_ci_failure first' and 'Use this tool when you need detail the diagnosis did not include.' It also advises preferring stepKey or stream over grep for cost reasons, giving the agent a clear decision procedure.

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