depot-mcp

Overview Schema Source Related Servers Discussions Admin

List Depot CI variables and their scoping

depot_list_ci_variables

Read-onlyIdempotent

List Depot CI variables with values and scopes to diagnose why a job can't see an expected variable. Values that look like secrets are redacted, but existence and scope remain visible.

Instructions

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. Because variables are routinely misused to hold credentials, this server redacts any value whose name or content looks like a secret and reports which rule fired, so a redacted value still tells you the variable exists.

Filtering happens in this server. depot.ci.v3beta2 is a beta API and the most likely of Depot's surfaces to change.

Input Schema

TableJSON Schema

Name	Required	Description
`query`	No	Case-insensitive substring match on the name.
`branch`	No	Keep variants scoped to this branch.
`workflow`	No	Keep variants scoped to this workflow.
`repository`	No	Keep variants scoped to this repository, plus unscoped ones.
`environment`	No	Keep variants scoped to this environment.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`returned`	Yes
`variables`	Yes
`redactedCount`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.2.1Sep 8, 2026
- addedOutput schema / properties / variables / items / properties / id
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / variables / items / properties / variants / items / properties / id
```
Added value: +{
+  "type": "string"
+}
```
First observedv0.1.0Sep 5, 2026

TDQS

A4.7/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 meaningful behavior: values are returned, secret-looking values are redacted with the firing rule reported, filtering happens server-side, and the API is beta and subject to change. This is substantial extra context that helps an agent know what to expect.

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 front-loaded with the core purpose and then layers usage, scoping model, redaction behavior, and beta warning in a logical order. Each sentence earns its place; nothing is redundant.

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 a full input schema, an output schema, and annotations, the description still adds the missing context an agent needs: valuation behavior, redaction rules, scoping semantics, and API stability. It is complete for both selection and correct invocation.

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 baseline is 3. The description adds useful conceptual background about scoping variants and server-side filtering, but it does not add per-parameter semantics beyond what the schema already provides.

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 opens with a specific verb and resource: 'List Depot CI variables, their values, and their scoping.' It also differentiates itself from the closely related depot_list_ci_secrets tool by explicitly noting that Depot returns variable values here, unlike secrets.

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 a concrete use case: answering the 'why can't my job see $FOO' question, and explicitly names depot_list_ci_secrets as the related alternative. The 'Unlike secrets' sentence clarifies the key distinction and helps the agent choose the correct tool.

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