mcp-github-enterprise

Get Actions cache usage

get_actions_cache_usage

Read-onlyIdempotent

Report GitHub Actions cache usage org-wide or for a single repository to identify caches near the 10 GB limit and plan a caching strategy for faster pipelines.

Instructions

Report GitHub Actions cache usage — org-wide, or for one repository. Use to spot caches near the 10 GB/repo limit and to size a caching strategy for faster pipelines.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "org": "<org>"
    },
    "name": "get_actions_cache_usage"
  }
}

Input Schema

Name	Required	Description	Default
`org`	Yes	Organization login (must be within GHE_ORG_ALLOWLIST when that is set)
`repo`	No	Optional: a single repo. Omit for org-wide totals.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.1Nov 7, 2026

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorld, so the safety profile is covered structurally. The description adds useful domain context (the 10 GB/repo limit) that helps interpret results. However, with no output schema, it does not describe what the response contains, such as per-repo usage figures or byte totals, which is the remaining behavioral gap.

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?

Two sentences with zero filler. Scope is front-loaded ahead of the interpretive hint about the 10 GB/repo limit, so an agent reads the essential fact first.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter read-only reporting tool whose annotations cover safety, the definition is nearly complete: it says what is reported and at what granularity. The only shortfall is that, without an output schema, it does not indicate the shape of the returned usage data.

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 coverage is 100% and both parameters already carry descriptions, including the allowlist constraint on `org` and the meaning of omitting `repo`. The description's "org-wide, or for one repository" merely restates the schema rather than adding formatting or validation detail. Baseline 3 is appropriate when the schema does the heavy lifting.

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 names a specific verb and resource ("Report GitHub Actions cache usage") and states the granularity (org-wide or single repository). No sibling tool covers cache usage, so an agent can immediately distinguish it from the runner, workflow, and permissions tools in the list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit when-to-use context: spotting caches near the 10 GB/repo limit and sizing a caching strategy. That is clear guidance for an agent. It lacks any exclusion or "not for X" statement, and names no alternative, which keeps it below a 5.

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