Depot (depot.dev) MCP server

Read from the package source without running it. The installed server may list more.

• depot_audit_trust_policies

  List every OIDC trust policy across your Depot container build projects and summarise which external CI identities (a GitHub repository, a Buildkite pipeline, a CircleCI project, a GitLab project) can build into which project. Use this for access reviews: "who can push builds into our projects without a token", "is a repository we archived still trusted", "does any project trust a repository outsi

• depot_cancel_ci_jobwrite action

  Cancel a single queued or running Depot CI job (CancelJob), leaving the rest of its workflow and run untouched. Use this for one stuck or pointless job, for example a matrix entry that is hanging, when the rest of the run should finish. To stop everything, use depot_cancel_ci_run instead. Cancelling is idempotent but not reversible. Refuses a job that is already finished, failed, cancelled, or ski

• depot_cancel_ci_runwrite action

  Cancel a queued or running Depot CI run (CancelRun) and every unfinished workflow and job under it, or, when workflowId is given, cancel just that workflow (CancelWorkflow) and its jobs. Use this when a run is known to be wasted: a superseded commit, a job stuck waiting, a workflow started by mistake. Cancelling is idempotent but not reversible; finished work is kept, unfinished jobs stop and repo

• depot_create_projectwrite action

  Create a Depot container build project (ProjectService/CreateProject): a name, a region, optional runner hardware, and an optional layer cache policy. The API form of `depot projects create`. dryRun (the default) lists the organization's existing projects, resolves every default (region us-east-1, hardware 16x32, cache 50 GB for 14 days), and says whether a project with this name already exists. D

• depot_delete_ci_variablewrite action

  Delete one variant of a Depot CI variable (DeleteVariableVariant), or with allVariants: true the whole variable and every variant (DeleteVariable). The API form of `depot ci vars remove`. Select the variant by variantName and/or by scoping attributes (repository, environment, branch, workflow); the selector must match exactly one variant. dryRun (the default) lists the variable's variants with the

• depot_delete_projectwrite action

  Delete a Depot container build project (ProjectService/DeleteProject), and with it its layer cache, build history, registry images, trust policies, and project tokens. Nothing brings any of that back. The API form of deleting the project in the Depot dashboard. dryRun (the default) reads the project with GetProject and its builds with ListBuilds, then shows what would be destroyed: the project's n

• depot_diagnose_build

  Explain why a Depot container build failed: locate the step that broke and return its error and the tail of its logs, alongside cache effectiveness for the build. Use this for "why did my docker build fail". Unlike Depot CI, container builds have no server-side AI diagnosis, so this tool does the legwork an agent would otherwise do by hand: read the build, page through its steps, pick the step tha

• depot_dispatch_ci_workflow

  Start a new Depot CI run of one workflow file on a branch, tag, or commit (DispatchWorkflow), with optional workflow_dispatch inputs. The API form of `depot ci dispatch`. Use this when a workflow needs to run now without a push: a manual deploy, a nightly job on demand, a release workflow on a tag. The workflow must declare an on.workflow_dispatch trigger and the repository must be connected to De

• depot_get_build

  Show one Depot container build: its status, when it was created, started and finished, how long it ran, and how much of it the cache served. Use this to check on a specific build by id: "did build X succeed", "is it still running", "how well did the cache do". It is one request and returns quickly, so it is the right way to poll a build that is in progress; call it again after a pause rather than

• depot_get_cache_summary

  Report the health of one Depot project's layer cache: the retention policy against the current cache size, the cache hit ratio over recent builds, the time the cache saved, and plain-language observations (cache near its size limit, low hit ratio, builds arriving less often than the retention keeps layers). Use this for "is our cache working", "why are builds not hitting cache", and "are we about

• depot_get_ci_artifact_url

  Mint a short-lived signed download URL for one Depot CI artifact, by artifact id. Use this when you already know which artifact you want (from depot_list_ci_artifacts) and need to fetch it: a JUnit report to read the failing test names, a screenshot from a browser test, a built binary. Download it with curl or fetch as soon as you have the URL, since Depot signs it for minutes, not hours. The URL

• depot_get_ci_attempt

  Show one attempt of a Depot CI job: its status, conclusion, recorded error, sandbox and session ids, timing, and whether it is the job's current attempt, with the parent job, workflow, and run for context. Use this when you hold an attemptId (from depot_get_ci_run, depot_get_ci_job, or a diagnosis) and need that attempt's own record, for example to confirm which sandbox a retry ran in or how long

• depot_get_ci_job

  Show one Depot CI job: its status, conclusion, recorded error, runner labels, timing, and every attempt with the attempt and sandbox ids needed to drill in. Use this when you already have a jobId (from depot_get_ci_run or a diagnosis) and want to know what happened to that job across retries: which attempt is current, whether earlier attempts failed the same way, how long each took, and where each

• depot_get_ci_job_summary

  Read the step summary a Depot CI job authored for itself — the equivalent of GitHub Actions' $GITHUB_STEP_SUMMARY. This is markdown the job's own steps chose to publish: test result tables, coverage deltas, lint counts, deployment URLs. When a job writes one, it is usually a far better explanation of what happened than its logs, because a human decided what mattered. Most jobs write nothing here,

• depot_get_ci_logs

  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

• depot_get_ci_metrics

  Read CPU and memory metrics for a Depot CI run, job, or job attempt. Use this when a job died without a useful error, was killed abruptly, hit an exit code like 137, or is simply slow — the shapes to look for are memory sitting at its limit (an OOM kill) or CPU pinned at 100% for the whole job (under-provisioned runner). "id" accepts a run, job, or attempt id and the level is inferred; set "level"

• depot_get_ci_runwrite action

  Show one Depot CI run as its workflow -> job -> attempt tree, with the status of every node and the ids needed to drill in. Use this to see the shape of a run: which jobs exist, which failed, and which attempt ids to pass to depot_get_ci_logs or depot_get_ci_metrics. Set failedOnly=true to cut a large matrix down to just the broken jobs. This does not explain failures — it only reports structure a

• depot_get_ci_workflow

  Show one Depot CI workflow: its status and timing, its parent run, its execution history (every rerun or retry, oldest first), and its job -> attempt tree with the ids needed to drill in. Use this when you have a workflowId (from depot_list_ci_workflows, depot_get_ci_run, or a diagnosis) and want to see how the workflow has been rerun and which of its jobs and attempts failed. It is the workflow-l

• depot_get_project

  Show one Depot container build project's full configuration together with its OIDC trust policies. Use this to check build capacity and cache retention for a specific project, and to audit which external CI systems are allowed to exchange an OIDC token for Depot credentials — trust policies are the answer to "how does our GitHub Actions workflow authenticate to Depot without a stored token". Trust

• depot_get_registry_image

  Show one image in the organization's Depot registry, by repository plus tag or digest: its digest, media type, size, tags, push time, and a summary of its manifest (the platforms of a multi-platform index, or the layer count and config digest of a single-platform image). Use this to confirm what a tag points at before a deploy, to check which platforms an image was built for, or to compare the dig

• depot_get_sandbox

  Show one Depot sandbox: its lifecycle state, runtime image, provisioned resources, creation, start, stop and expiry times, exit code, error message, metered CPU time and network bytes (available once the sandbox has ended), and the names of its environment variables. Use this after depot_list_sandboxes to inspect a sandbox that failed or is still running, or to check when a running sandbox will ex

• depot_get_usage

  Report Depot usage for a period: container build minutes and minutes saved by caching, GitHub Actions runner minutes by repository and workflow, storage, and agent sandbox minutes. Use this for cost questions — "what is burning our Depot minutes", "which repo dominates our runner bill", "is the cache actually paying for itself". minutesSaved against minutesBilled is the cache's return on investmen

• depot_kill_sandboxwrite action

  Terminate a Depot sandbox immediately (KillSandbox), without giving it the chance to finish what it is doing. The sandbox lands in the cancelled state; unflushed work inside it is lost. Use this for a sandbox that is stuck, runaway, or must stop now: a command that will not return, a process burning compute, something that should not keep running. Prefer depot_stop_sandbox when a clean shutdown is

• depot_list_builds

  List recent container builds for a Depot project, with duration and cache effectiveness for each. Use this to find a build to diagnose, or to answer "are our builds getting slower" — every row carries cachedSteps, totalSteps and secondsSaved, so a run of builds with a low cache hit ratio is visible immediately without opening the dashboard. Requires a projectId; DEPOT_PROJECT_ID is used when set,

• depot_list_ci_artifacts

  List the artifacts a Depot CI run, workflow, job, or attempt uploaded, optionally with signed download URLs. Use this to find out what a run produced — test reports, JUnit XML, coverage output, built binaries, screenshots from a failed browser test. Filter to one job or attempt by passing its id alongside runId. Set withDownloadUrl=true to also fetch signed HTTPS URLs, which are minted one request

• depot_list_ci_runs

  List recent Depot CI runs, newest first, optionally filtered by status, repository, commit, trigger, or pull request. Use this to find the run someone is talking about — "my last failed build", "did main go green", "what ran for PR 412" — and then pass the returned runId to depot_diagnose_ci_failure or depot_get_ci_run. The fastest path to diagnosing a recent breakage is status=["failed"] with lim

• depot_list_ci_secrets

  List the names and scoping of Depot CI secrets. Values are never returned — Depot's API does not expose them at all, by design. Use this to answer "why can't my job see $FOO". Depot models a secret as one name with several variants, each scoped by repository, environment, branch, and workflow attributes; a job that cannot see a secret usually means no variant matches that job's scope. Compare what

• depot_list_ci_variables

  List Depot CI variables, their values, and their scoping. Use this for the same "why can't my job see $FOO" question as depot_list_ci_secrets, and to check that a variable holds what you expect for a given branch or environment. Depot models a variable as one name with several variants, each scoped by repository, environment, branch, and workflow. Unlike secrets, Depot does return variable values.

• depot_list_ci_workflows

  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

• depot_list_images

  List the container images stored in a Depot project's registry, with tag, digest, push time, and size. Use this to check whether a build actually pushed what you expected, to find the digest behind a tag before a deploy, or to see when an image was last refreshed. Requires a projectId; DEPOT_PROJECT_ID is used when set, and depot_list_projects lists the options. Read-only: this cannot delete tags

• depot_list_project_tokens

  List the project tokens that exist for one Depot container build project: token id, description, and timestamps when Depot provides them. Never the token secret, which Depot only reveals once, at creation, and this server never creates one. Use this for credential inventory and access reviews: "which tokens exist for this project", "is there a token nobody remembers creating". Pair it with depot_a

• depot_list_project_usage

  List every Depot container build project's build count, total build time, and layer cache size for a period, in one call. Use this for "which project holds the most cache", "which projects are actually building", and "where is our storage going". Rows are sorted by layer cache size, largest first, and carry the project name when depot_list_projects can supply it. For minutes billed and minutes sav

• depot_list_projects

  List Depot container build projects with their region, runner hardware, and cache policy. Use this to find a projectId for depot_list_builds, depot_diagnose_build, or depot_list_images, and to check configuration that affects build speed: which region a project builds in, how large its runners are, and how much layer cache it retains before eviction. These are container build projects. Depot CI ru

• depot_list_registry_repositories

  List the repositories in the organization's Depot registry, with tag count, total size, last push time, and each repository's retention policy. Use this to see what the organization publishes to the Depot registry, to find a repository name for depot_get_registry_image, or to audit which repositories have a retention policy (and so will have old images pruned) and which do not. depot_list_images l

• depot_list_sandboxes

  List the organization's Depot sandboxes (Depot's on-demand VMs for agents), most recent first, with state, runtime image, resources, timing, and exit code. Use this to see which sandboxes are running or recently finished, to find a sandboxId for depot_get_sandbox, or to check whether a failed sandbox left an error message. Filter by state (for example ["running"]) or by creation time. … Read-only:

• depot_rerun_ci_workflow

  Rerun every job of a finished Depot CI workflow (RerunWorkflow), successful ones included. Depot resets each terminal job and starts a new execution, so this costs the workflow's full compute again. Prefer depot_retry_ci_failed_jobs, which reruns only what failed; this tool is for cases where the passing jobs must run again too (a changed secret or variable, a suspected bad cache, a green workflow

• depot_retry_ci_failed_jobs

  Retry only the failed and cancelled jobs of a finished Depot CI workflow (RetryFailedJobs). Successful jobs are kept; each retried job gets a new attempt, so this costs compute for the failed subset only. This is the right tool for "try CI again" after a flaky failure. It is cheaper than depot_rerun_ci_workflow, which reruns every job. Pass workflowId, or runId when the run has exactly one workflo

• depot_retry_ci_job

  Retry a single failed or cancelled Depot CI job (RetryJob), creating a new attempt of that job only. Nothing else in the workflow runs again. This is the narrowest retry: use it when exactly one job is known to be flaky. For every failed job in a workflow, use depot_retry_ci_failed_jobs; for the whole workflow, depot_rerun_ci_workflow. Each call creates a new attempt, so it is not idempotent. Refu

• depot_set_ci_variablewrite action

  Create or overwrite one variant of a Depot CI variable (SetVariableVariant), the API form of `depot ci vars set`. A variable is a name with variants; each variant carries a value and optional scoping (repository, environment, branch, workflow). Without variantName this writes the "default" variant, exactly as the CLI does, and the scoping given here replaces that variant's scoping. dryRun (the def

• depot_stop_sandbox

  Ask a running Depot sandbox to shut down cleanly (StopSandbox). The sandbox gets the chance to flush and exit, and lands in the finished state; its exit code, CPU time, and network usage stay readable through depot_get_sandbox. Use this when an agent's sandbox is no longer needed and should stop spending compute: work is done, the session is over, or it was left running by mistake. Stopping is ide

• depot_update_projectwrite action

  Change a Depot container build project's name, builder hardware, or layer cache policy (ProjectService/UpdateProject). The API form of editing the project in the Depot dashboard. dryRun (the default) reads the project with GetProject and shows each field that would change, from the current value to the requested one. A smaller cache size or shorter retention comes with a warning, because Depot evi

• depot_wait_for_ci_runwrite action

  Wait, for a bounded time, until a Depot CI run, one workflow in it, or one job reaches a terminal state, then report the outcome and which nodes changed state while waiting. Use this after a push or a rerun when the next step depends on the result: "wait for the run to finish, then diagnose it if it failed". Pass runId to watch a whole run. Pass workflowId to watch one workflow: this is what to do

• depot_whoami

  Verify the configured Depot token and report which organizations and projects it can actually see. Call this first whenever another Depot tool returns an empty list or a permission error. Depot's most common confusing failure is a token that spans several organizations with none selected: requests then resolve against the wrong organization and return empty results rather than an error. This tool

• Code scan115 source files scanned25/25
• –Live reliabilityno gateway calls yet and no remote to proben/a
• –Tool poisoningtools not inspected (local package is not executed); not countedn/a
• Auth qualitystatic API keys via environment variables6/15
• Maintenancelast push 1 days ago15/15
• Maintainer identityregistry namespace matches repository owner; GitHub account older than a year8/10

Depot (depot.dev): common questions

Is Depot (depot.dev) MCP server safe?

Mostly: it is graded B (83/100). Read the Depot (depot.dev) safety report

How do I install Depot (depot.dev)?

It runs on your machine. Copy the Claude Code, Claude Desktop or Cursor config from the install section.

Does Depot (depot.dev) need an API key?

Yes. The registry entry asks for DEPOT_TOKEN.

Is Depot (depot.dev) maintained?

The last commit was in the last day (2026-09-19). The latest release is v0.2.1.

What can I use instead of Depot (depot.dev)?

Servers from other publishers that do the same job: Radar Kubernetes MCP Server, Yaver MCP server and devcontainer-mcp server. Compare all Depot (depot.dev) alternatives.