depot-mcp

Overview Schema Source Related Servers Discussions Admin

Audit Depot OIDC trust policies across projects

depot_audit_trust_policies

Read-onlyIdempotent

Audit OIDC trust policies across Depot projects to reveal which external CI identities can push builds. Use for access reviews, spotting stale trusts, or detecting out-of-organization trust.

Instructions

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 outside our organization". A project with no trust policies is common and fine; its builds authenticate with a token instead.

Pass projectId to audit one project; otherwise the first 50 projects are checked with one ListTrustPolicies call each. Read-only: adding or removing a trust policy is not offered by this server. Organization token only.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`projectId`	No	Limit the audit to one project. Without it, up to 50 projects are audited.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`notes`	Yes
`projects`	Yes
`identities`	Yes
`policyCount`	Yes
`projectCapHit`	Yes
`projectsFailed`	Yes
`projectsAudited`	Yes
`projectsWithPolicies`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.2.1Sep 8, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the readOnlyHint annotation, the description explicitly states it is read-only, that adding/removing trust policies is not offered, that an organization token is required, and that projects without trust policies are normal rather than errors.

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?

Well structured in three focused paragraphs: purpose, use cases, and parameter/behavior notes. No irrelevant details or redundant filler beyond what helps the agent.

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?

Complete for an audit-style tool. It explains default scope, per-project behavior, authentication requirements, read-only nature, and an important edge case (projects with no trust policies). The output schema is present, so return values do not need to be described.

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

Parameters4/5

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

The schema already covers projectId well with 100% coverage. The description adds useful nuance about auditing the first 50 projects by default and making one ListTrustPolicies call per project, giving the agent a clearer mental model.

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?

Clearly states a specific action: listing every OIDC trust policy across Depot projects and summarizing which external CI identities can build into which project. This is distinct from sibling tools that focus on builds, runs, logs, or tokens.

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 use cases for access reviews, such as 'who can push builds without a token' and 'is a repository we archived still trusted'. It also explains how the optional projectId parameter changes scope and what happens by default.

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