GitHub Actions Optimization with Pipetrics MCP

GitHub Actions optimization with measured CI data

Pipetrics MCP makes measured GitHub Actions data available to Codex, Claude Code, OpenCode, or any other compatible MCP client. Use it for GitHub Actions optimization: find slow workflows, queue delays, failed spend, job bottlenecks, and regressions.

Pipetrics analyzes workflow telemetry without receiving your source code. Your coding agent can inspect workflow files in your local workspace, subject to its own permissions.

MCP endpoint: https://mcp.pipetrics.com/mcp

For an introduction to the approach, read GitHub Actions optimization with MCP and AI. To evaluate other approaches, see GitHub Actions cost optimization tools.

CI context and repository context

Pipetrics supplies measured CI execution context through MCP. Your coding agent supplies repository context through its own file-access tools. These are separate permissions: connecting Pipetrics does not grant it access to your application source files.

The agent can first identify a high-impact workflow using telemetry, then inspect local workflow YAML and relevant diffs. Ask it to separate measured findings from hypotheses and propose a change for review before editing files.

CI metadata can still be sensitive. Review the GitHub App permissions, your client's provider and retention policies, and its repository-read and edit approval settings.

Prerequisites

Before connecting:

1. Install the Pipetrics GitHub App.
2. Grant the required read-only permissions.
3. Activate at least one repository in Pipetrics.
4. Wait for its first workflow data to be collected.

Authentication uses browser-based OAuth. No Pipetrics API key is required in client configuration.

Connect Codex

Add the remote MCP server, authenticate, and verify it:

codex mcp add pipetrics --url https://mcp.pipetrics.com/mcp
codex mcp login pipetrics
codex mcp list

You can also add it to ~/.codex/config.toml:

[mcp_servers.pipetrics]
url = "https://mcp.pipetrics.com/mcp"

Use /mcp inside Codex to check the connection. See the official Codex MCP documentation for client-specific options.

Connect Claude Code

Add Pipetrics at user scope so it is available across projects:

claude mcp add --transport http pipetrics \
  --scope user https://mcp.pipetrics.com/mcp
claude mcp login pipetrics
claude mcp list

For a project-scoped configuration, create .mcp.json:

{
  "mcpServers": {
    "pipetrics": {
      "type": "http",
      "url": "https://mcp.pipetrics.com/mcp"
    }
  }
}

Project-scoped servers require approval when Claude Code first loads them. If claude mcp login is unavailable in your installed version, run /mcp in an interactive session and authenticate there.

See the official Claude Code MCP documentation for scopes and server management.

Connect OpenCode

OpenCode provides an interactive setup command:

opencode mcp add

Select Remote, enter pipetrics as the name, and use https://mcp.pipetrics.com/mcp as the URL. Then authenticate and verify the server:

opencode mcp auth pipetrics
opencode mcp list

Alternatively, add the server to opencode.json or opencode.jsonc:

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "pipetrics": {
      "type": "remote",
      "url": "https://mcp.pipetrics.com/mcp",
      "enabled": true
    }
  }
}

OpenCode detects OAuth automatically for remote MCP servers. See the official OpenCode MCP documentation for authentication and debugging commands.

GitHub Actions optimization prompts

Check this repository's retained data coverage. Compare the most recent seven complete days with the preceding seven days only if both periods are available. Otherwise, analyze the available period and state the limitation. Rank meaningful changes in runtime, failed runtime, queue delay, and modeled cost. For each finding, separate measured facts from assumptions and tell me which workflow file or job to inspect next. Do not edit files yet.

Where does this repository spend most of its GitHub Actions time? Separate runtime from queueing and tell me what to investigate first.

Analyze this repository’s GitHub Actions workflows at job and step level. Which jobs are slow, unreliable, or expensive, and what should we improve first?

Which workflows and jobs cost the most, how much is spent on failed runs, and where are the biggest opportunities to reduce cost?

Have any recent commits been associated with meaningful increases in workflow runtime or cost? Investigate the strongest signals and explain what might account for them.

What are the most important GitHub Actions findings for this repository, and what should we investigate next?

What does this repository’s GitHub Actions usage actually cost? Explain the modeled cost, likely billable amount, included usage, and any important limitations.

Where are failed GitHub Actions runs wasting the most time and money, and what should we fix first?

Why did GitHub Actions cost increase for this repository? Compare a recent period with a stable baseline, separate run volume from duration and runner changes, and rank the workflows responsible.

Measured finding
- Scope: owner/repository, exact available period and comparison baseline
- Workflow: .github/workflows/ci.yml
- Execution count: increased
- Median and p95 duration: include measured values
- Failed runtime: include measured value
- Modeled cost change: include measured value and pricing basis

Interpretation
- The increase is associated primarily with execution count, duration, runner mix,
  failure, or a combination of those factors.

Next inspection
- Open the named workflow and inspect triggers, matrix expansion, runner choice,
  concurrency, and the highest-impact job or step.

Which workflow regressed most recently? Compare median and p95 duration, show the first observed commit associated with the change, check whether it persisted, and avoid claiming that the commit caused the regression.

Inspect the associated workflow file and relevant commit diff. List plausible explanations for the measured change, evidence for and against each one, and the smallest safe experiment. Do not change the workflow until I approve the plan.

Rank workflows by failed runtime and modeled failed cost. State whether each figure covers all jobs in failed workflow attempts or only jobs whose own outcome failed. Keep those definitions separate. Include valid reruns, distinguish frequent quick failures from expensive late failures, and identify the job and step that should be investigated first.

GitHub Actions optimization flow

Use this sequence for GitHub Actions optimization:

1. Request the top repository findings.
2. Select the workflow with the largest measured impact.
3. Drill into its jobs and steps.
4. Inspect the local workflow YAML.
5. Check commit evidence for recent regressions.
6. Make one focused change and compare later runs with the baseline.

This keeps recommendations tied to measured pipeline behavior instead of generic CI/CD advice.

Data access and plans

Pipetrics uses read-only GitHub permissions for Actions and repository metadata. MCP analysis returns telemetry such as durations, queue delays, failures, retries, workflow paths, commit SHAs, absolute modeled costs, and scoped billing estimates.

For GitHub Actions optimization, start with runtime and failure evidence. Both plans can analyze modeled cost within their retention window. Pro provides a longer history for baselines, regressions, and cost comparisons.

The Pipetrics plan controls telemetry retention. The GitHub account or organization plan controls included Actions minutes used by estimated billable-cost calculations. Upgrading Pipetrics does not change GitHub billing.

See Cost Profiler for visual GitHub Actions cost analysis.

For practical changes after the investigation, use the GitHub Actions cost optimization guide. It covers triggers, concurrency, caching, matrices, failures, artifacts, and runner selection without assuming every repository needs the same fix.

Troubleshooting

Authentication is required

Run the login command for your client and complete OAuth in the browser:

codex mcp login pipetrics
claude mcp login pipetrics
opencode mcp auth pipetrics

The server does not connect

1. Confirm the URL is exactly https://mcp.pipetrics.com/mcp.
2. List configured MCP servers in the client.
3. Repeat browser authentication.

No repository data appears

Confirm that the GitHub App is installed, the repository is activated, and at least one workflow run has been collected. Review the integration guide for required permissions.

Security boundary

Pipetrics MCP does not need source-code access. It supplies measured CI/CD telemetry to the agent. Local file reads and edits are controlled separately by Codex, Claude Code, or OpenCode and remain subject to your approval settings.