depot-mcp

Overview Schema Source Related Servers Discussions Admin

List Depot CI workflows

depot_list_ci_workflows

Read-onlyIdempotent

List recent Depot CI workflows with status and job counts, filtered by name, status, repository, commit, trigger, or pull request, to identify failing or successful workflows.

Instructions

List recent Depot CI workflows, newest first, with each one's status and job counts, optionally filtered by workflow name, status, repository, commit, trigger, or pull request.

Use this when the question is about a named workflow rather than a whole run: "is the deploy workflow green", "which CI workflows failed today", "how many jobs failed in the release workflow". A run groups every workflow a push triggered; this lists the workflows themselves, each with its parent runId.

Returns identity, status, and counts only. It does not return jobs or failure detail: pass a workflowId to depot_get_ci_workflow for its jobs and rerun history, or to depot_diagnose_ci_failure with targetType "workflow" for root cause.

Input Schema

TableJSON Schema

Name	Required	Description
`pr`	No	Pull request number. Depot requires repo to be set alongside this.
`sha`	No	Filter to workflows for one commit SHA.
`name`	No	Keep only workflows with this name, as written in the workflow YAML "name:" field.
`repo`	No	Repository in "owner/name" form. Required when filtering by pr.
`limit`	No	Maximum workflows to return in one call.
`status`	No	Keep only workflows in these states. "finished" means completed successfully; a failed workflow reports "failed". Omit for every state.
`trigger`	No	Filter by what started the workflow, for example "push" or "workflow_dispatch".
`pageToken`	No	nextPageToken from a previous call, to fetch the following page.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`returned`	Yes
`workflows`	Yes
`nextPageToken`	No

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.2.1Sep 8, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already mark it read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds behavioral substance beyond that: results are newest-first, each workflow carries its parent runId, and only identity/status/counts are returned rather than jobs or failure detail.

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 organized into summary, usage, and limitation/routing sections; the key fact is front-loaded and each sentence carries information. It is longer than a single line but justified by the need to disambiguate from run-level siblings.

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?

With an output schema present and annotations covering safety, the description supplies the remaining decision context: when to choose this tool, what it omits, and where to go for jobs or root cause. There is no obvious missing information an agent needs to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the input schema already documents all eight optional filters and their constraints. The description only lists the filter dimensions (name, status, repo, commit, trigger, PR) without adding syntax or format details, matching the baseline for high coverage.

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 sentence names a specific verb ('List'), a resource ('Depot CI workflows'), an ordering ('newest first'), and the returned fields ('status and job counts'). The second paragraph explicitly distinguishes it from run-level tools by explaining that a run groups workflows while this returns the workflows themselves, so it stands apart from depot_list_ci_runs and siblings.

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 an explicit 'Use this when...' condition with concrete example questions about named workflows. It also states what it does not do and routes to alternatives: depot_get_ci_workflow for jobs and rerun history, and depot_diagnose_ci_failure with targetType 'workflow' for root cause.

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