github-pr-ci-status

name	github-pr-ci-status
description	Use when checking whether GitHub Actions CI has run or passed on a pull request via the GitHub MCP tools (`mcp__github__pull_request_read`) — before claiming CI is green, red, or hasn't run yet.

Checking PR CI status: get_status vs get_check_runs

Symptom

mcp__github__pull_request_read with method: "get_status" returns "total_count": 0 on a PR that has GitHub Actions workflows configured and has visibly run them (confirmed separately via mcp__github__actions_list or the Actions UI). This reads as "no CI has run against this commit," and is wrong.

Root cause

get_status calls GitHub's legacy Combined Commit Status API (GET /commits/{sha}/status) — the API older third-party CI integrations (Travis, CircleCI, pre-Checks-API Jenkins) use to post a status directly onto a commit. GitHub Actions does not use this API. It reports through the separate Checks API instead. A repository whose only CI is GitHub Actions will always return total_count: 0 from get_status, regardless of whether any workflow has run, is running, or failed — the field is simply not populated by that integration path.

Fix

Use method: "get_check_runs" instead — it calls the Checks API and returns the actual GitHub Actions job list (name, status, conclusion) for the PR's head commit. This is the only one of the two methods that reflects Actions results.

If you need run-level detail (timestamps, the workflow run/job URLs, commit message per run), use mcp__github__actions_list (method: "list_workflow_runs") instead or in addition.

Don't be misled

get_status's zero is not "pending" or "no data yet" in the way a fresh/uncompleted run would show under get_check_runs (there you'd see "status": "in_progress" or "queued" entries, not an empty list). A get_status zero tells you nothing about Actions; treat it as answering a different question ("are there any legacy commit statuses"), not "has CI run."