Can an AI Agent Query My GitHub Actions Metrics?

Answer

Yes. WarpBuild hosts a Model Context Protocol server at https://mcp.warpbuild.com/mcp that exposes the WarpBuild API to an MCP host such as an editor assistant, so questions about job duration, queue time, runner utilization, and cost get answered where you type instead of across three dashboard tabs (MCP support). Setup is two steps: generate an API key with the CI scope, then add the server URL and an Authorization: Bearer header to the host's MCP configuration.

The reason the question comes up at all is that GitHub Actions on its own reports run duration, queue time, job counts, and conclusion (GitHub Actions metrics). Anything about the machine underneath comes from an agent on the runner. WarpBuild records both sides and exposes them through the API, and CI observability is one part of the product surface alongside snapshot runners, remote Docker builders, an MCP server, and the Action Debugger.

Here is what an assistant can pull, and which surface each field comes from.

Detail

The two setup steps

Generate the key at app.warpbuild.com/settings/api-keys, set a name, and check CI. The key is displayed once, so copy it into your secret store at the moment it appears; the name and the scopes stay editable from the same page afterwards.

Then register the server with your host:

{
  "mcpServers": {
    "warpbuild": {
      "url": "https://mcp.warpbuild.com/mcp",
      "headers": {
        "Authorization": "Bearer <api key with the CI scope>"
      }
    }
  }
}

The MCP support documentation walks through Cursor and names Antigravity as another host that connects the same way. Any host that accepts a remote MCP server by URL with custom headers takes the same block. After a reload, ask a listing question first, so a wrong key fails on a read rather than partway through a write.

A worked question

Take a real one: integration in acme/api used to finish in nine minutes and now finishes in thirteen, and someone wants to know whether that is a code change, a capacity problem, or an undersized runner, and what the extra minutes are costing.

The assistant reads three things to answer it. Duration P75 and P90 for that repository, workflow, and job name over the two periods, which separates a slower job from a noisier one. Queue time P75 and P90 for the label, which separates waiting from running. CPU and memory percentiles for the same job, which say whether the machine is saturated. The answer that comes back looks like this, on warp-ubuntu-latest-x64-8x at $0.016 per minute with 1,200 runs per month.

Queue time held, so capacity is not the story. CPU P90 crossed the threshold WarpBuild uses to mark an instance as under provisioned, which is 80 percent for max sustained CPU, max memory utilization, or max filesystem utilization. The bill moved $76.80 per month. Rates below come from the pricing page, checked on 2026-08-13, and they are what the assistant multiplies against.

Moving to warp-ubuntu-latest-x64-16x doubles the rate and only pays back if the job actually halves. That is a measurement, so run it on a branch and compare the same percentiles.

The API surface behind the answer

The inventory endpoints are documented directly: GET /api/v1/stacks, GET /api/v1/runner-images, GET /api/v1/runners with only_custom_runners and image filters, and GET /api/v1/runners/<runner-id>. Calls carry Authorization: Bearer wkey-..., the same header the MCP block sets.

Two practical notes. The host lists the server's tools when it connects, so read that list rather than guessing at names. And every report tab exports CSV with all rows matching the current filters, which is the fallback when you want the raw table in a spreadsheet next to the assistant's summary.

The permission boundary

The key is the boundary. API keys are scoped to combinations of WarpBuild products, and the scopes available today are CI, Cache, and Helios. A CI scoped key reaches CI runners, images, and stacks for your organization; a key without the Cache scope cannot touch cache endpoints. Nothing in the key grants repository access, so what the assistant knows about your workflow files is whatever the host already had open.

Write access travels with read access on the same scope. A CI scoped key can create runners and delete them, and the documentation states that deleting a runner is irreversible, so keep deletes out of assistant hands during the first weeks and ask it to echo any request body before it posts. Rotate from the same API keys page.

What asking costs

The same reports cover all four. Full rates are on the pricing page, and the fleet wide picture is GitHub Actions observability.

Related Questions

Which GitHub Actions metrics can an assistant read through the MCP server?

The ones WarpBuild records: run count, success rate, duration P75 and P90, queue time P75 and P90, and CPU and memory P75 and P90 per unique repository, workflow, and job name; per job cost rows from the Billing report; and per instance CPU, memory, filesystem, disk I/O, and network utilization from observability. The field lists are in the reports reference, and the MCP server guide has the worked prompts.

Does an API key give the assistant my source code or my secrets?

No. The key carries WarpBuild product scopes, and the scopes available today are CI, Cache, and Helios, so it reaches the WarpBuild API for your organization and nothing else. Repository contents reach the assistant only through the repository access the host already has. A CI scoped key can create and delete runners and a delete is irreversible, so treat it as a production credential and keep it in the host's secret storage. The scope list is on the API keys page, and running AI coding agents on GitHub Actions covers the wider credential question.

Can an assistant answer questions about jobs shorter than a minute?

Partly. Run count, success rate, duration, queue time, and cost are recorded for every job, so those questions answer normally. Observability collects metrics and logs only for jobs longer than about 1 minute, so CPU and memory render as a dash in the Jobs report for short jobs and the assistant has no utilization series to reason over. The collection rules are in the observability reference, and the protocol itself is defined in MCP server.