Mushi-Mushi

CI runners and why fixes wait

get_ci_overview

Read-onlyIdempotent

Shows where a project's tests run and why fixes are slow to land by summarizing CI runners, job verdicts, queue and duration stats, and infrastructure-failure advice.

Instructions

Return where this project's tests run and why a fix is slow to land (ADR 0033): the machines that send a runner heartbeat (hostname, platform, memory, swap, load, free disk, and per runner service its memory use, memory limit and out-of-memory kills), the GitHub runners seen (online | offline, busy, labels), repos, the latest jobs with their verdict (passed, running, queued, waiting_for_runner, runner_lost, queue_expired, cancelled, code_failure; waiting_for_runner, runner_lost and queue_expired are infra: the test machine stopped and the fix was not tested, which is not a code failure), and stats { queueP50s, queueP95s, durationP50s, durationP95s, passRate, infraFailures, codeFailures, byRunner, byWorkflow, slowSteps }, plus advice [{ id, severity (high | medium | low), title, detail, evidence, fix }] with the evidence for each rule. Optional projectId (default: the configured project; with an account-level key and no project, every project you can read), days (1-30, default 7) and refresh (true reads GitHub first instead of the last 10-minute sync, at most once a minute per project). permissions { jobs, runners } is ok | missing | unknown: jobs need Actions: read on GitHub, the runner list needs Administration: read (without it runners come from jobs only). Repo, workflow, job, step and runner names come from the repos. Returns { generatedAt, refreshedAt, window, permissions, hosts, runners, repos, jobs, stats, advice }. Read-only. When a fix's CI failed with an infra verdict, re-run the tests instead of changing code.

Input Schema

Name	Required	Description
`days`	No	Window in days (default 7)
`refresh`	No	Read GitHub first instead of the last 10-minute sync (at most once a minute per project)
`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
`jobs`	No	Latest jobs with their infra or code verdict
`hosts`	No	Machines that send a runner heartbeat
`repos`	No
`stats`	No
`advice`	No	Rule-based advice with evidence, most severe first
`window`	No
`runners`	No	GitHub runners seen, with status
`generatedAt`	No
`permissions`	No
`refreshedAt`	No

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.1.17Oct 23, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Goes well past the readOnly/idempotent annotations: explains the 10-minute sync vs refresh behaviour with the 'at most once a minute per project' rate limit, the permission requirements (Actions: read for jobs, Administration: read for runners) and the degraded fallback when runners permission is missing. It also defines the semantic difference between infra failures and code failures.

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?

Purpose is front-loaded, but the body is a single dense run-on sentence that enumerates every return field and stats key. Since an output schema exists, much of that enumeration is redundant and hurts scannability, though the verdict-semantics gloss carries genuine value.

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?

An output schema exists, yet the description still supplies meaningful context on verdicts, permissions fallbacks and the refresh window. Nothing an agent needs to call it correctly or interpret results is missing.

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?

Schema coverage is 100%, so the baseline is 3; the description adds real depth by explaining what refresh actually changes (reads GitHub first instead of the sync) and the default-project/account-key behaviour of projectId. The days window constraint is only restated from the schema.

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?

Specific verb and resource: 'Return where this project's tests run and why a fix is slow to land', with the ADR reference to anchor it. It clearly distinguishes itself from sibling tools like get_ci_costs, refresh_ci and get_fix_verification.

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 frames the use case (diagnosing slow-to-land fixes and infra verdicts) and gives an explicit action rule: 'When a fix's CI failed with an infra verdict, re-run the tests instead of changing code.' It doesn't name sibling alternatives such as refresh_ci or get_ci_costs, so routing is implied rather than explicit.

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

Deploy Server