Skip to main content
Glama

Summarise a Depot project cache

depot_get_cache_summary
Read-onlyIdempotent

Diagnose why builds miss cache or layers may be evicted: summarizes retention policy vs current size, recent hit ratio, time saved, and plain-language observations.

Instructions

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 to evict layers". It combines depot_get_project (policy), depot_list_project_usage (current size), depot_list_builds (per-build cache counters) and depot_get_usage (minutes billed and saved) so you do not have to.

What it cannot do: Depot's API does not list individual cache entries, so there is no per-layer view, and this server never resets a project's cache. Requires a projectId or DEPOT_PROJECT_ID, and an Organization token.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
projectIdNoThe project to summarise. Falls back to DEPOT_PROJECT_ID; depot_list_projects lists the options.
windowDaysNoUsage window in days, ending now, for cache size and minutes saved. Maximum 90.
buildSampleNoHow many of the most recent builds to aggregate the hit ratio over. Maximum 100.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
cacheYes
notesYes
policyYes
sampleYes
windowYes
billingNo
projectIdYes
limitationsYes
projectNameNo
observationsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.1

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds useful context by mentioning it never resets the cache, requires an Organization token, and has no per-layer visibility, going beyond the annotation baseline.

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 compact and well-structured into three short paragraphs covering purpose, usage, and limitations. Every sentence contributes meaningful guidance without redundancy or filler.

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?

Given that an output schema exists, return-value details are not required. The description provides sufficient context for invocation, including input fallback, aggregation logic, authentication need, and explicit non-capabilities, making it complete for an agent to decide and call.

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 fully describes all three parameters with types, defaults, and bounds. The description adds valuable semantics: projectId falls back to DEPOT_PROJECT_ID, windowDays is an ending-now usage window, and buildSample aggregates the most recent builds.

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?

States a specific verb ('Report') and a clear resource ('Depot project's layer cache'), with a precise summary of the metrics covered. The intended use cases ('is our cache working', etc.) and the fact that it aggregates multiple underlying tools make its purpose unambiguous.

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?

Explicitly lists when to use the tool with concrete user questions and clearly states what it cannot do (no per-layer view, never resets cache). It also explains that it combines several other endpoints, giving an agent clear situational guidance.

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