Gaffer.sh

This MCP server connects AI coding assistants like Claude Code and Cursor to your Gaffer test history and coverage data. It runs in code mode: three MCP tools over a namespace of 17 functions — 16 read-only analytics functions plusupload_test_results. It allows AI to:

- Check your project's test health (pass rate, flaky tests, trends)
- Look up the history of specific tests to understand stability
- Get context about test failures when debugging
- Analyze code coverage and identify untested areas
- Browse all your projects (with user API Keys)
- Access test report files (HTML reports, coverage, etc.)
- AGafferaccount with test results uploaded
- An API Key from Account Settings > API Keys

claude mcp add gaffer -e GAFFER_API_KEY=gaf_your_api_key_here -- npx -y @gaffer-sh/mcp

{ "mcpServers": { "gaffer": { "command": "npx", "args": ["-y", "@gaffer-sh/mcp"], "env": { "GAFFER_API_KEY": "gaf_your_api_key_here" } } } }

Add to.cursor/mcp.jsonin your project:

{ "mcpServers": { "gaffer": { "command": "npx", "args": ["-y", "@gaffer-sh/mcp"], "env": { "GAFFER_API_KEY": "gaf_your_api_key_here" } } } }

This server usescode mode. Instead of exposing one MCP tool per API call, it exposes three tools plus acodemodenamespace you call from JavaScript. Fewer tool definitions occupy the context window, and a single execution can chain several calls.

const health = await codemode.get_project_health({ projectId: "proj_abc" }); if (health.flakyTestCount > 0) { const flaky = await codemode.get_flaky_tests({ projectId: "proj_abc" }); return { health, flaky }; } return { health };

Every function exceptupload_test_resultsis read-only.

- Input:organizationId(optional),limit(optional, default: 50)
- Returns:List of projects with IDs, names, and organization info
- Example:"What projects do I have in Gaffer?"

- Input:projectId(required),days(optional, default: 30)
- Returns:Health score (0-100), pass rate, test run count, flaky test count, trend
- Example:"What's the health of my test suite?"

Get the pass/fail history for a specific test.

- Input:projectId(required),testNameorfilePath(one required),limit(optional)
- Returns:History of runs with status, duration, branch, commit, errors
- Example:"Is the login test flaky? Check its history"

Get the list of flaky tests in a project.

- Input:projectId(required),threshold(optional, default: 0.1),days(optional),limit(optional)
- Returns:List of flaky tests with flip rates, transition counts, run counts
- Example:"Which tests are flaky in my project?"

List recent test runs with optional filtering.

- Input:projectId(required),commitSha(optional),branch(optional),status(optional),limit(optional)
- Returns:List of test runs with pass/fail/skip counts, commit and branch info
- Example:"What tests failed in the last commit?"

Get parsed test results for a specific test run.

- Input:testRunId(required),projectId(required),status(optional filter),limit(optional)
- Returns:Individual test results with name, status, duration, file path, errors
- Example:"Show me all failed tests from this test run"

Get URLs for report files uploaded with a test run.

- Input:testRunId(required)
- Returns:List of files with filename, size, content type, download URL
- Example:"Get the Playwright report for the latest test run"

Get a browser-navigable URL for viewing a test report.

- Input:projectId(required),testRunId(required),filename(optional)
- Returns:Signed URL valid for 30 minutes
- Example:"Give me a link to view the test report"

Get the slowest tests in a project, sorted by P95 duration.

- Input:projectId(required),days(optional),limit(optional),framework(optional),branch(optional)
- Returns:List of tests with average and P95 duration, run count
- Example:"Which tests are slowing down my CI pipeline?"

Compare test metrics between two commits or test runs.

- Input:projectId(required),testName(required),beforeCommit/afterCommitORbeforeRunId/afterRunId
- Returns:Before/after metrics with duration change and percentage
- Example:"Did my fix make this test faster?"

Get the coverage metrics summary for a project.

- Input:projectId(required),days(optional, default: 30)
- Returns:Line/branch/function coverage percentages, trend, report count, lowest coverage files
- Example:"What's our test coverage?"

Get coverage metrics for specific files or paths.

- Input:projectId(required),filePath(required - exact or partial match)
- Returns:List of matching files with line/branch/function coverage
- Example:"What's the coverage for our API routes?"

Get files with little or no test coverage.

- Input:projectId(required),maxCoverage(optional, default: 10%),limit(optional)
- Returns:List of files below threshold sorted by coverage (lowest first)
- Example:"Which files have no tests?"

Find code areas with both low coverage AND test failures (high risk).

- Input:projectId(required),days(optional),coverageThreshold(optional, default: 80%)
- Returns:Risk areas ranked by score, with file path, coverage %, failure count
- Example:"Where should we focus our testing efforts?"

Group failed tests by root cause using error message similarity.

- Input:projectId(required),testRunId(required)
- Returns:Clusters of failed tests grouped by similar error messages, with representative error and test count
- Example:"Are these 15 failures from the same bug?"

Search past failures by error message, stack trace, or test name — or list every failure in the window.

- Input:query(optional — omit to return all failures),projectId(required forgaf_keys),searchIn(optional:errors/names/all, defaultall),days(optional, default: 30),branch(optional),limit(optional, default: 20)
- Returns:Matching failures with test name, error message, run and commit context, plustruncatedwhen scan caps cut the list short
- Example:"Have we seen this connection-refused error before?" / "What failed in the last 7 days?"

Check if CI results have been uploaded and processed.

- Input:projectId(required),sessionId(optional),commitSha(optional),branch(optional)
- Returns:Upload session(s) with processing status, linked test runs and coverage reports
- Example:"Are my test results ready for commit abc123?"

Upload structured test results. This is the only function that writes.

Use it when you have results in hand — parsed from CI output or a runner's JSON report — and no Gaffer CLI is available to upload them.

- Input:projectId(required forgaf_keys),framework(required),tests(required),branch,commitSha,ciProvider,startedAt,finishedAt,coverage
- Returns:uploadSessionId, the generatedrunId, and the derived pass/fail/skip summary
- Example:"Upload these 42 parsed pytest results so we can track them"

runId, the run timestamps and the summary are derived fromtests— passstartedAt/finishedAtonly if you know the real wall-clock window.

- Not idempotent.Each call creates a new run, so a retry after an uncertain failure produces a duplicate. Checkget_upload_statusinstead of retrying.
- Rate-limited per project, and every call is written to the project's audit log with the id of the credential that made it.

Processing is asynchronous: results take a few seconds to become visible to the read functions.

These workflows show how an AI agent diagnoses CI failures, waits for results, and finds coverage gaps. Each step is acodemodefunction, so a whole chain runs inside oneexecute_codecall rather than one round-trip per step.

list_test_runs(projectId, status="failed") → get_test_run_details(projectId, testRunId, status="failed") → get_failure_clusters(projectId, testRunId) → get_test_history(projectId, testName="...") → compare_test_metrics(projectId, testName, beforeCommit, afterCommit)

- Find the failed test run
- Get individual failure details with stack traces
- Group failures by root cause — often 15 failures are 2-3 bugs
- Check if each failure is new (regression) or recurring
- Verify fixes by comparing before/after

get_upload_status(projectId, commitSha="abc123") → poll until processingStatus="completed" → get_test_run_details(projectId, testRunId)

- Check if results for a commit have been uploaded
- Wait for processing to complete
- Use linked test run IDs to get results

find_uncovered_failure_areas(projectId) → get_untested_files(projectId) → get_coverage_for_file(projectId, filePath="src/critical/")

- Find files with both low coverage and test failures (highest risk)
- Find files with no coverage at all
- Drill into specific directories for targeted analysis

When using coverage tools to improve your test suite, combine coverage data with codebase exploration for best results:

Before targeting files purely by coverage percentage, explore which code is actually critical:

- Find entry points:Look for route definitions, event handlers, exported functions - these reveal what code actually executes in production
- Find heavily-imported files:Files imported by many others are high-value targets
- Identify critical business logic:Look for files handling auth, payments, data mutations, or core domain logic

Low coverage alone doesn't indicate priority. Consider:

- High utilization + low coverage = highest priority- Code that runs frequently but lacks tests
- Large files with 0% coverage- More uncovered lines means bigger impact on overall coverage
- Files with both failures and low coverage- Usefind_uncovered_failure_areasfor this

Theget_untested_filestool may return many frontend components. For backend or specific areas:

# Query specific paths with get_coverage_for_file get_coverage_for_file(filePath="server/services") get_coverage_for_file(filePath="src/api") get_coverage_for_file(filePath="lib/core")

- Get baseline withget_coverage_summary
- Identify targets withget_coverage_for_fileon critical paths
- Write tests for highest-impact files
- Re-check coverage after CI uploads new results
- Repeat

User API Keys (gaf_prefix) provide read-only access to all projects across your organizations. Get your API Key from:Account Settings > API Keys

Project Tokens (gfr_prefix) are designed for uploading test results and only provide access to a single project. When you use one, omitprojectId— it resolves automatically. User API Keys are preferred for the MCP server because they enablelist_projectsand read across projects.

Test locally with Claude Code (use absolute path to built file):

{ "mcpServers": { "gaffer": { "command": "node", "args": ["/absolute/path/to/dist/index.js"], "env": { "GAFFER_API_KEY": "gaf_..." } } } }

This is a web browser that enables your coding agent, such as Claude Code, to visit websites on your behalf and assist you in identifying bugs or creating UI test cases.

Create crafted UI components inspired by the best 21st.dev design engineers.

Bring agent evaluations, observability, and synthetic test set generation directly into your IDE for free with Galileo's new MCP server

An MCP server to help AI assistants to answer questions and generate AccelByte Extend SDK code more effectively .

MCP server for AI Diagram Maker — generate beautiful software engineering diagrams directly inside Cursor, Claude Desktop, Claude Code, or any MCP-compatible AI agent

ALAPI MCP Tools,Call hundreds of API interfaces via MCP

AI-powered SVG animation generator that transforms static files into animated SVG components using the Allyson platform

MCP server that gives AI assistants on-demand access to 1,500+ amCharts docs, ~300 code examples, and 1000+ class API references.

APIMatic MCP Server is used to validate OpenAPI specifications using APIMatic. The server processes OpenAPI files and returns validation summaries by leveraging APIMatic’s API.

One shared context layer for AI agents and humans — live API specs, DB schemas, and versioned contracts across repos so every agent and teammate works from the same source of truth.