Querying GitHub Actions Data with an MCP Server

WarpBuild runs a hosted MCP server at https://mcp.warpbuild.com/mcp that connects an MCP host to the WarpBuild API, so an agent can create runners, create runner images, and query your GitHub Actions runner fleet from the editor you already have open. Point the host at that URL with an Authorization: Bearer <api key> header, using a key that carries the CI scope, and the questions that used to need a dashboard tab plus a spreadsheet become questions you type once.

This guide covers the manual investigation loop the MCP server removes, the exact configuration block, three worked prompts with the shape of the answer that comes back, and a time and cost model you can rerun with your own numbers.

Diagnosis

A runner question almost never lives on one screen. Take the ordinary version of it: the integration job on the main branch used to finish in eight minutes and now takes fourteen, and someone in the platform channel wants to know whether to change the label, change the test split, or leave it alone.

Answering that means visiting three surfaces.

The first is the GitHub Actions run page. Step timings live there, along with the log lines that tell you which step grew. The second is the WarpBuild observability page at app.warpbuild.com/ci/observability, which carries CPU, memory, filesystem, and network utilization for the runner instance, plus system logs and the GitHub Actions logs correlated against them. The third is the runner inventory: which labels exist, which image each runner boots, what pool size it holds, and which instance types sit behind it.

Only the first two have a dashboard. The third lives in the WarpBuild API, and the mapping from a runs-on label in a workflow file to a machine shape and a per-minute rate is the join that nobody has open in a tab.

The manual loop, timed

Here is the loop as most teams run it, with the minutes we use as the modeling assumption. Substitute your own.

Three properties make that loop worse than the 32 minutes suggest.

The join key is a human. Nothing automatically connects the string warp-ubuntu-latest-x64-8x in a workflow file to the 8 vCPU, 32 GB shape it resolves to and the minutes billed against it. An engineer holds that mapping in their head, and it goes stale whenever a label changes.

The asker is rarely the owner. The person who wants the answer is often on a product team, and the person who set the runner labels is on the platform team. The question turns into a handoff, and the handoff adds a day.

Short jobs fall out of the metrics. Observability collects metrics and logs for jobs longer than about one minute, so a fleet of fast jobs has to be understood from log timings and minute counts rather than utilization charts.

What an agent needs instead

An agent can carry the whole loop if three things are true: the platform exposes a machine-readable surface, the agent can authenticate to it, and there is a protocol the host already speaks.

WarpBuild satisfies the first two by design.

The MCP server supplies the third. It exposes that same API behind a Model Context Protocol endpoint, so the host handles discovery and calling conventions, and your attention goes to the question instead of to curl syntax.

Fix

The setup is four steps and takes about ten minutes end to end.

1. Generate an API key at app.warpbuild.com/settings/api-keys, give it a name, and check the CI scope.
2. Add the WarpBuild MCP server block to your host's MCP configuration with the key in an Authorization: Bearer header.
3. Reload the host and confirm the server shows as connected.
4. Ask a read-only question first, so a misconfigured key fails on a listing call rather than on a create call.

Once the host is connected, the loop above collapses into prompts. Three of them cover most of what teams actually ask.

Prompt 1: audit the runner inventory

List every custom runner in the organization with its labels, pool size, image id, and instance types. Then check the workflow files in this repository and flag any runner whose labels never appear in a runs-on.

The answer comes back as one table row per runner, plus a short list of orphans. The agent reads the fleet through the MCP server and reads the workflows from the repository the host already has open, which is the join that costs an engineer four minutes of tab switching.

This one is worth a monthly cadence. The automation docs note that unused custom runners can increase job pick-up times, so an inventory that only grows is a latency problem as well as a tidiness problem.

Prompt 2: create an image and a runner

Create a BYOC runner image from AMI ami-0f1c2d3e4a5b6c7d8 on our EC2 stack, then create a runner named payments-arm-large with pool size 2 and instance types c7g.4xlarge and c7g.8xlarge. Return the label I should put in runs-on.

The agent resolves the stack, posts the runner image, posts the runner, and returns the created runner id along with its labels array. The label it hands back is the one you paste into the workflow. The same sequence by hand is three curl calls with two ids copied between them, and the second id only exists after the first call succeeds.

Two guardrails belong on this prompt. Ask the agent to echo the request body before it posts, and keep deletes out of agent hands during the first weeks, since deleting a runner through the API is irreversible.

Prompt 3: sweep for oversized labels

For every job in .github/workflows, print the runner label, the vCPU and RAM behind it, and the per-minute rate. Sort by weekly minutes and show me the three jobs where the shape looks larger than the work.

The answer shape is a table of job, label, shape, rate, weekly minutes, and a recommendation column. The agent can produce the first five columns entirely from the workflow files plus the runner catalog. The recommendation column is a hypothesis, so confirm it against the observability recommendations view before you merge anything: sustained CPU at or above 80 percent marks a runner as under-provisioned, and consistently low utilization is the signal that a smaller label will hold.

The fleet these prompts describe

The prompts above assume a workflow that fans a build across four platforms. This is the shape they read:

name: build-and-test
on:
  pull_request:
  push:
    branches: [main]

jobs:
  unit:
    runs-on: warp-ubuntu-latest-x64-8x
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci
      - run: npm test

  integration:
    runs-on: warp-ubuntu-latest-arm64-8x
    steps:
      - uses: actions/checkout@v4
      - run: docker compose -f docker-compose.ci.yml up -d
      - run: ./scripts/integration.sh

  ios:
    runs-on: warp-macos-latest-arm64-6x
    steps:
      - uses: actions/checkout@v4
      - run: xcodebuild -scheme App -destination 'platform=iOS Simulator,name=iPhone 16' test

  windows:
    runs-on: warp-windows-latest-x64-8x
    steps:
      - uses: actions/checkout@v4
      - run: .\build.ps1 -Configuration Release

When prompt 3 reports that the unit job peaks at 35 percent CPU on an 8 vCPU shape, the change is one line:

  unit:
    runs-on: warp-ubuntu-latest-x64-4x

Run that on a branch for a few days before merging. Halving vCPU raises wall clock on anything that parallelizes well, and a job that stretches from 12 minutes to 26 has given back the rate difference. The observability view and the minute counts tell you which case you are in.

Configuration

Generate the API key

Go to app.warpbuild.com/settings/api-keys, set a name, and check CI. Keys can be scoped to combinations of WarpBuild products, and the scopes available today are CI, Cache, and Helios. MCP work needs CI. Add Cache if the same key will drive cache endpoints in your automation scripts.

The generated key is displayed only once and starts with the wkey- prefix, so copy it into your secret store at the moment it appears. Name and scope stay editable from the same page afterwards, which is also where you rotate a key that leaked.

Wire the MCP server

The server URL is https://mcp.warpbuild.com/mcp. Configure your MCP client with:

{
  "mcpServers": {
    "warpbuild": {
      "url": "https://mcp.warpbuild.com/mcp",
      "headers": {
        "Authorization": "Bearer wkey-xxxxxxxxxxxxxxxx"
      }
    }
  }
}

Hosts differ in where that JSON lives. The MCP support docs walk through Cursor: open the command palette, search for MCP settings, choose the option that opens MCP settings, click New MCP Server, and paste the warpbuild block into the JSON file that opens. Antigravity and other hosts that accept a remote server by URL take the same block.

If your host expands environment variables inside its MCP configuration, reference the key through a variable rather than pasting it. Either way, keep the file with the raw key out of version control.

Verify the key before you debug the host

When a host reports a red server, it rarely says whether the key or the transport is at fault. Check the key on its own first:

curl -X GET "https://api.warpbuild.com/api/v1/runners?only_custom_runners=true" \
     -H "Accept: application/json" \
     -H "Authorization: Bearer wkey-xxxxxxxxxxxxxxxx"

A JSON array back means the key and its scope are good, and the remaining problem is host configuration. An authorization error means the key is wrong or the CI scope is missing. The API keys docs carry the full request shapes for runners, runner images, and stacks if you want to script any of this outside an agent.

The catalog the agent resolves labels against

Prompt 3 needs a mapping from label to shape to rate. These are the labels that appear most often in the workflows an agent will read:

Rates are per minute in USD, verified on 2026-08-13 against the WarpBuild pricing page.

Where agents stop and Terraform starts

An agent is good at exploration and at one-off creation: audit the fleet, stand up a runner for an experiment, answer a question during an incident. Long-lived fleet definitions want a file in a repository with a review on it.

BYOC runs on AWS, GCP, and Azure. Terraform support exists for BYOC on AWS, so an AWS fleet can live in state files while the MCP server handles the questions and the throwaway runners. A reasonable split is Terraform for anything a second engineer needs to reproduce, and the agent for anything you would otherwise have done in the dashboard.

Access and support

Anyone who can mint a CI-scoped key can create and delete runners in your organization, so key issuance deserves the same review as cloud credentials. SSO is available for a flat $250 per month, whatever the user count, and the pricing page is where that line lives.

Cost or Time Model

Two numbers move when an agent takes over the loop: engineer minutes per investigation, and runner minutes per week once the investigation produces a change. Model them separately.

Engineer time

The manual loop above totals 32 minutes. The agent version is three prompts plus review of the answers, which we model at 6 minutes, since reading a table and sanity-checking a recommendation still takes attention.

Both the cadence and the hourly rate are assumptions you should replace. The structural point survives either number: the loop is dominated by joining data across surfaces, and that join is the part an agent does at no marginal cost.

Runner minutes

Assume a repository that runs 400 Linux jobs a week averaging 12 minutes each, which is 4,800 minutes.

Arithmetic: 400 jobs multiplied by 12 minutes gives 4,800 minutes, and 4,800 multiplied by $0.016 gives $76.80.

The right-sizing row is what prompt 3 pays for. Finding one oversized label on a busy workflow is worth $1,996.80 a year on this fleet, and the agent found it in a prompt rather than in a spreadsheet.

The third row is the baseline the same minutes carry on GitHub-hosted larger runners. Against list prices:

GitHub list prices come from GitHub pricing and the Actions minute multipliers reference, checked on 2026-08-13. The macOS row compares against GitHub's nearest ARM64 macOS shape, which carries one fewer vCPU and 8 GB less RAM than the WarpBuild runner in the same row.

Adding the two halves together for this example fleet: $8,112 of reclaimed engineer time on the assumptions above, plus $1,996.80 a year from the single label change the sweep surfaced.

What the MCP server itself costs

Nothing beyond the runner minutes you already pay for.

If you want the broader picture the prompts feed into, read the GitHub Actions observability guide for how the metrics are collected, reading GitHub Actions runner metrics for interpreting the utilization charts, and reducing GitHub Actions costs for the changes that follow a sweep. When a prompt tells you a job is failing rather than slow, debugging GitHub Actions failures covers getting onto the runner itself.

FAQ

What is the WarpBuild MCP server URL?

The server is at https://mcp.warpbuild.com/mcp. Add it to your MCP host with an Authorization header of Bearer <api key>, using a key generated at app.warpbuild.com/settings/api-keys with the CI scope checked.

What can an agent do through the WarpBuild MCP server?

MCP can be used to interact with the WarpBuild API to create runners, create runner images, and query the API.

Which MCP hosts can connect to it?

Any host that supports a remote MCP server addressed by URL with custom headers. The WarpBuild docs walk through Cursor step by step, and name Antigravity as another host that connects the same way.

Is it safe to hand an agent a WarpBuild API key?

Scope the key to CI only, keep it in your host's secret storage rather than a committed file, and rotate it from the API keys page. A CI-scoped key can create and delete runners, so treat it as a production credential.