Skip to main content
Glama

Get Depot CI job logs

depot_get_ci_logs
Read-onlyIdempotent

Fetch a bounded slice of persisted logs for any Depot CI job attempt, using filters like step, stream, or substring, plus page tokens to tail or walk forward through output.

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
NameRequiredDescriptionDefault
idYesAn attempt id, job id, or run id. Attempt ids give the most precise result.
grepNoCase-insensitive substring filter applied to line bodies by this server after fetching. Not a regular expression.
streamNoKeep only one output stream. stderr alone is often enough to spot a failure.
stepKeyNoKeep only lines from this step, as reported in a line's stepKey.
pageTokenNoContinue 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.
tailLinesNoMaximum log lines per call: the last N of what was read without a pageToken, the next N forward with one.
targetTypeNoWhat "id" refers to. Omit to let the server work it out.
includeTimestampsNoPrefix each rendered line with its ISO timestamp. Costs context; usually not needed.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
linesYes
notesYes
targetYes
truncatedYes
pageCapHitYes
linesMatchedYes
pagesFetchedYes
linesReturnedYes
nextPageTokenNo

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv0.1.0

TDQS

A5/5.0
Behavior5/5

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

The description massively exceeds what the annotations (readOnlyHint, idempotentHint, destructiveHint) already provide: it discloses that grep is applied server-side after page fetches so it reduces received data but not read data, warns that grep walks up to DEPOT_MCP_MAX_LOG_PAGES pages and is the most expensive mode, documents the paging contract in full (tail vs forward, page-cap early stop, exact-line resumption), requires tokens to be passed back verbatim, and caps line bodies at 2000 chars with a bodyTruncated marker. This is deep behavioral disclosure with no contradiction against the annotations.

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 paragraph earns its place: purpose, sibling routing, filtering-cost model, id polymorphism, and the paging contract are all dense operational content rather than filler. It is front-loaded with purpose and the 'try depot_diagnose_ci_failure first' guidance, and the paging contract is given as a structured bulleted list, making it easy for an agent to parse.

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?

The tool has 8 parameters, a two-mode paging contract, polymorphic id handling, and an output schema; the description covers all of it, including defaults, the page cap, truncation markers, and even the cross-turn polling pattern ('following nextPageToken until it is absent yields every line exactly once'). With the output schema already present, no crucial invocation detail 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?

Even though schema description coverage is 100% and the baseline is therefore 3, the description adds essential meaning beyond every parameter: id's polymorphic behavior (run id picks the failed or last job and reads the latest attempt), the cost differential between grep versus stepKey/stream, the paging semantics that give pageToken and tailLines their meaning, and the context-cost warning on includeTimestamps ('Costs context; usually not needed'). These semantics are required to invoke the tool correctly and reside only in the description.

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 line 'Fetch a bounded slice of the persisted logs for a Depot CI job attempt' names a precise verb, resource, and scope, and the 'bounded slice' qualifier distinguishes this from a generic 'get all logs' tool. It also explicitly names depot_diagnose_ci_failure as the sibling it is not, so an agent can route correctly without opening the schema.

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?

The description states unambiguously when to prefer the alternative ('Try depot_diagnose_ci_failure first') with concrete reasons why it is cheaper and what it contains, then gives exact conditions for using 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'). This is fully explicit when/to-when-not guidance with a named alternative.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/akshayjain3450/depot-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server