github-fetcher

GitHub workflow runs

github_workflow_runs

Read-onlyIdempotent

Lists GitHub Actions workflow runs for a repository or specific workflow, with optional filters for branch, status, and event so you can inspect CI results by page.

Instructions

List workflow runs for a repository or one workflow, optionally filtered by branch, status, and event.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "repo": "<repo>"
    },
    "name": "github_workflow_runs"
  }
}

Input Schema

Name	Required	Description
`page`	No	Page number, starting at 1
`repo`	Yes	Repository in owner/name form
`event`	No	Event filter, such as push or pull_request
`fresh`	No	Bypass the local cache
`branch`	No	Branch filter
`status`	No	Run status, conclusion, or both, as accepted by GitHub
`per_page`	No	Items per page, default 20
`workflow_id`	No	Workflow id or numeric workflow file id

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 1, 2026

TDQS

A4/5.0

Behavior2/5

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

The description primarily summarizes the API's filtering capabilities, which are already hinted at by the comprehensive annotations (readOnlyHint: true, destructiveHint: false) and the schema. It adds little context regarding execution behavior beyond being a list/read operation.

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

Conciseness5/5

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

The description is a single, efficient sentence. Every word contributes to defining the scope and functionality without unnecessary jargon or padding.

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?

Given the rich set of annotations and a complete parameter schema, the high-level summary is sufficient to guide an agent in selecting and appropriately scoping the tool for execution. No critical missing information is present.

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?

While the schema is complete (100% coverage), the description provides semantic meaning by calling out the purpose of several key parameters (e.g., 'filtered by branch, status, and event'). This reinforces the functional use of those specific inputs.

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?

The description is highly specific, stating it lists workflow runs for either a repository or a single workflow. This clearly defines the resource and scope of the operation, successfully distinguishing it from search or commit/issue tools in the siblings list.

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 explicitly details the main filter criteria (branch, status, and event), giving agents clear conditions under which to invoke this tool. It establishes that filtering is optional, which is crucial context.

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