Skip to main content
Glama

Real GitHub Actions bill

get_ci_bill
Read-onlyIdempotent

Retrieve the actual amount GitHub charged for Actions over a chosen window, with measured USD totals, discounts, and breakdowns by repository, SKU, and day.

Instructions

Return what GitHub actually charged for Actions, read from GitHub's billing usage API by the CI collector once a day (or pushed with mushi runner bill --push). Unlike get_ci_costs, these money figures are measured, not estimated. Returns { window, previousWindow, provenance: "measured", currency: "USD", available, repoScoped (true when you are not a member of the organization: only your projects' repos are shown), unavailableReason (why there is no bill and how to connect one), owners [{ owner, ownerType, lastOkAt, lastAttemptAt, lastError, lastSource (api | cli), coveredFrom }], month { label, grossUsd, discountUsd, netUsd } (this calendar month so far), totals { grossUsd, discountUsd, netUsd, minutes }, previousTotals and change { netUsd, netPct } (null unless Mushi holds the whole previous period), windowComplete, byRepo [{ repo, netUsd, grossUsd, discountUsd, minutes }], bySku, byDay (every day of the window), dataThrough, agentShare { share, billedMinutes, agentBilledMinutes, branches, provenance: "estimated" } (paid GitHub-hosted minutes on Mushi agent branches, from the jobs Mushi recorded) }. Net is what was charged; public repos and included minutes show as discount. Optional projectId (default: the configured project; an account-level key with none reads every project) and days (1-90, default 30). Read-only.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_ci_bill"
  }
}

Input Schema

NameRequiredDescriptionDefault
daysNoWindow in days (default 30)
projectIdNoProject UUID — defaults to the server-configured project; omitted with an account-level key, every project you can read (`project_id` is accepted too.)

Output Schema

NameRequiredDescriptionDefault
byDayNo
bySkuNo
monthNoThis calendar month so far: grossUsd, discountUsd, netUsd
byRepoNo
changeNo
ownersNo
totalsNo
windowNo
currencyNo
availableNo
agentShareNoPaid minutes on Mushi agent branches (estimated)
provenanceNomeasured: from GitHub's bill
repoScopedNoOnly your projects' repos: you are not a member of the organization
dataThroughNo
previousTotalsNo
previousWindowNo
windowCompleteNo
unavailableReasonNoWhy there is no bill, and how to connect one

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.19

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the read-only and idempotent annotations, the description discloses the data source, refresh cadence, measured provenance, repo scoping behavior, availability caveats, and reasons a bill may be unavailable. This is rich behavioral context that materially helps an agent understand freshness, completeness, and limitations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The key distinction from get_ci_costs is front-loaded, which is good. However, the description then enumerates an extensive return object despite an output schema being present, making it longer than necessary for an agent-facing tool definition.

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 the tool's complexity, annotations, and output schema, the description provides sufficient context about source, refresh behavior, scoping, availability, and data provenance. An agent has enough information to call it correctly and interpret its limitations.

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 schema already documents both optional parameters. The description restates the defaults and account-level key behavior for projectId and the days range, adding little beyond the schema baseline.

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 states precisely what the tool returns: measured GitHub Actions billing from GitHub's billing usage API. It explicitly distinguishes itself from the sibling get_ci_costs by noting that these figures are measured rather than estimated, so an agent can select it confidently.

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?

The description names the key alternative, get_ci_costs, and explains the selection condition: use this for actual charged amounts, not estimates. It does not spell out explicit when-not scenarios beyond that distinction, but the routing guidance is clear and actionable.

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

Deploy Server

Other Tools