Mushi-Mushi

CI cost and speed

get_ci_costs

Read-onlyIdempotent

Compare CI costs and run speed between GitHub-hosted and self-hosted runners; get per-repo, per-runner-class cost and timing estimates, billing breakdowns, and what-if savings scenarios.

Instructions

Return what this project's CI costs and how fast it runs on GitHub-hosted runners versus your own machines (Plan 022, ADR 0037). Rows per repo × runner class [{ repo, runnerClass (github_hosted | self_hosted | unknown = never picked up), os, labels, runner, machine, jobs, expired, queueP50s, queueP95s, runP50s, runP95s, prPassRate (pull-request jobs only), infraRate, rawMinutes, billedMinutes (each job rounded up to a whole minute), rerunJobs, tinyJobs, monthCost, costBasis (github_list | github_public_free | github_larger_unpriced | self_hosted | unknown), currency }]; repos with visibility (public repos run GitHub-hosted minutes free); accounts per GitHub owner (plan, includedMinutes, monthMinutes, monthListCost, monthCost after included minutes); machines (busyHours as the union of job intervals, busyShare, monthEnergyCost and monthWearCost from the organization's own figures); speed factors (only passed jobs that ran on both classes, at least 5 each, with sample sizes); whatIfs for moving a workflow (minutes moved, jobs that stay and why, speed, cost delta, target wait and busy share, warnings); explain (re-runs, tiny jobs, expired jobs, pinned-to-GitHub jobs with their YAML reason, main and Dependabot runs that always use GitHub); advice with evidence; fields says which numbers are measured and which estimated; rates gives GitHub's list prices and the date they were read. Optional projectId (default: the configured project; an account-level key with none reads every project) and days (1-30, default 30). lowConfidence is true under 7 days of data. Returns { window, dataDays, lowConfidence, source, sourceNote, rates, fields, settings, repos, rows, accounts, machines, speed, whatIfs, explain, advice }. Read-only: it changes nothing on GitHub. Every money figure is an estimate.

Input Schema

Name	Required	Description	Default
`days`	No	Window in days (default 30)
`projectId`	No	Project 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

Name	Required	Description
`rows`	No	Per repo × runner class: wait, run time, pass rate, minutes, cost
`rates`	No	GitHub list prices and the date they were read
`repos`	No
`speed`	No
`advice`	No
`fields`	No	measured \| estimated per field
`source`	No
`window`	No
`explain`	No
`whatIfs`	No
`accounts`	No	Included minutes per GitHub owner
`dataDays`	No
`machines`	No
`settings`	No
`sourceNote`	No
`lowConfidence`	No	Under 7 days of data

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.1.17Oct 23, 2026

TDQS

A3.5/5.0

Behavior4/5

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

The description adds useful behavioral context beyond the annotations: lowConfidence is true under 7 days of data, every money figure is an estimate, costBasis and raw versus billed minutes are explained, and account-level-key behavior is mentioned. It also confirms read-only behavior, consistent with the annotations. It stops short of discussing permissions or rate limits.

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

Conciseness2/5

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

The purpose is front-loaded, but the description is a very long run-on sentence with an exhaustive bracketed field list. Much of that field enumeration duplicates the output schema and makes the definition harder to scan than necessary.

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 complex cost/speed tool with an output schema and read-only annotations, the description is largely complete: it explains estimates, low-confidence windows, cost basis, and account scoping. The main gap is sibling differentiation, especially from get_ci_overview.

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 two parameters are already well documented. The description restates days (1-30, default 30) and projectId defaults/account-level behavior, but adds little semantic meaning beyond the schema itself. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource: return the project's CI costs and speed, comparing GitHub-hosted runners against self-hosted machines. It is clear enough to separate this from a generic CI overview, but it never names or distinguishes itself from siblings like get_ci_overview or request_ci_placement_change.

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

Usage Guidelines3/5

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

Usage is implied by the cost-and-speed framing, and the optional projectId/days behavior is noted. However, there is no explicit guidance on when to choose this tool over get_ci_overview or related sibling tools, and no exclusions or prerequisites are stated.

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

Deploy Server