Which integrations are available for this server?

Provides tools to list, run, and validate GitHub Actions workflows locally using act.

How do I use act-testing-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@act-testing-mcp list my workflows" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

act-testing-mcp

by GarthDB

Overview Schema Related Servers Score Discussions

JavaScript

Local

Act Testing MCP

npm version npm downloads License

Model Context Protocol (MCP) server for testing GitHub Actions workflows locally using nektos/act.

Purpose

This MCP provides AI assistants (like Claude) with direct access to test GitHub Actions workflows locally, eliminating trial-and-error development cycles when working with CI/CD pipelines.

Related MCP server: GitHub MCP Server

Features

🔍 List Workflows: Discover all available GitHub Actions workflows in any repository
▶️ Run Workflows: Execute workflows locally with act
✅ Validate Syntax: Check workflow files for errors before committing
🎭 Custom Events: Test workflows with custom event data to simulate different scenarios
🐛 Debug Support: Detailed logging and error reporting
📊 Dependency Monitoring: Track act compatibility and detect breaking changes
🔐 Supply Chain Security: Published with npm provenance attestations for verifiable builds

Prerequisites

Docker Desktop (running)
nektos/act installed (Installation Guide)
Node.js 20+

Installing nektos/act

# macOS
brew install act

# Linux (with curl)
curl https://raw.githubusercontent.com/nektos/act/master/install.sh | sudo bash

# Windows (with chocolatey)
choco install act-cli

# Or download from releases
# https://github.com/nektos/act/releases

Installation

npm install -g act-testing-mcp

Verifying Package Integrity

This package is published with npm provenance for enhanced supply-chain security. You can verify the package's attestations:

npm audit signatures

Or clone and run locally:

git clone https://github.com/GarthDB/act-testing-mcp.git
cd act-testing-mcp
npm install

Configuration

MCP Setup

Add to your MCP configuration (e.g., .cursor/mcp.json for Cursor IDE):

Option 1: Using npx (Recommended)

{
  "mcpServers": {
    "act-testing": {
      "command": "npx",
      "args": ["act-testing-mcp"]
    }
  }
}

Option 2: Using global installation

{
  "mcpServers": {
    "act-testing": {
      "command": "act-testing-mcp"
    }
  }
}

Option 3: With custom project path (if needed)

{
  "mcpServers": {
    "act-testing": {
      "command": "npx",
      "args": ["act-testing-mcp"],
      "env": {
        "PROJECT_ROOT": "/path/to/your/project"
      }
    }
  }
}

Option 4: Local development

{
  "mcpServers": {
    "act-testing": {
      "command": "node",
      "args": ["./path/to/act-testing-mcp/index.js"],
      "env": {
        "PROJECT_ROOT": "/path/to/your/project",
        "ACT_BINARY": "act"
      }
    }
  }
}

Note: Using npx (Option 1) is recommended as it avoids PATH issues and ensures you always use the latest version. The MCP server automatically detects the current working directory, so PROJECT_ROOT is only needed if you want to override the default behavior. This approach mirrors other MCP servers like Browser MCP and resolves common NPX availability problems as mentioned in continuedev/continue#4791.

Act Configuration

Create an .actrc file in your project root (copy from the example):

# Copy example configuration and customize paths
cp mcp-config.example.json .cursor/mcp.json
# Edit .cursor/mcp.json to set your PROJECT_ROOT path

# Copy act configuration (optional)
cp .actrc /path/to/your/project/.actrc

Tools Provided

`list_workflows`

Lists all available GitHub Actions workflows in the repository.

Parameters: None

Example:

📋 **CI** (ci.yml)
   Job: test (test)
   Events: push, pull_request

📋 **Release** (release.yml)
   Job: release (release)
   Events: workflow_dispatch

`run_workflow`

Runs a workflow locally using act.

Parameters:

workflow (required): Workflow file name or job ID
event (optional): Event type (push, pull_request, etc.)
dryRun (optional): Show execution plan without running
verbose (optional): Enable detailed output
env (optional): Environment variables
secrets (optional): Secrets to provide
eventData (optional): Custom event data for testing

Examples:

# Run CI workflow
run_workflow workflow="ci.yml" event="push"

# Dry run with custom event data
run_workflow workflow="ci.yml" event="pull_request" dryRun=true eventData='{"number": 123}'

# Run with environment variables
run_workflow workflow="release.yml" env='{"NODE_ENV": "production"}'

`validate_workflow`

Validates workflow syntax and structure.

Parameters:

workflow (required): Workflow file name to validate

`act_doctor`

Checks act configuration and Docker setup.

Parameters: None

Usage Examples

With AI Assistant (Claude)

Once configured, you can ask your AI assistant to test workflows directly:

"Test my CI workflow"
"Run the release workflow in dry-run mode"
"Check if my new workflow file is valid"
"Test the pull request workflow with custom PR data"

Direct Usage

# Start the MCP server
npm start

# Run tests
npm test

# Run with coverage
npm run test:coverage

# Debug mode
npm run dev

Development

Running Tests

# Install dependencies
npm install

# Run all tests
npm test

# Run with coverage
npm run test:coverage

# Run in watch mode
npm run test:watch

Testing Coverage

The tool includes comprehensive testing:

Unit tests with AVA framework
Integration testing with real act and Docker
Code coverage with c8 (targeting 70%+ for core logic)
ES modules with native Node.js support

Compatibility Monitoring

Track act compatibility over time:

# Create baseline
npm run compatibility:baseline

# Check for changes
npm run compatibility:check

# Generate detailed report
npm run compatibility:report

Project Structure

act-testing-mcp/
├── index.js              # Main MCP server
├── package.json          # Dependencies and scripts
├── README.md             # This file
├── LICENSE               # Apache 2.0 license
├── .actrc                # Act configuration example
├── ava.config.js         # Test configuration
├── mcp-config.example.json # MCP configuration example
├── utils/                # Utility modules
│   ├── act-helpers.js    # Core act integration
│   └── act-monitor.js    # Compatibility monitoring
├── scripts/              # Utility scripts
│   └── check-act-compatibility.js
├── test/                 # Test suites
│   ├── index.test.js
│   ├── act-compatibility.test.js
│   ├── act-monitor.test.js
│   └── utils.test.js
└── docs/                 # Additional documentation
    ├── SETUP.md
    ├── GUIDE.md
    ├── TESTING.md
    └── DEPENDENCY_MONITORING.md

Troubleshooting

Docker Issues

# Check Docker is running
docker ps

# Pull required images
docker pull catthehacker/ubuntu:act-latest

Act Issues

# Check act installation
act --version

# Test act with simple workflow
act --list

MCP Connection Issues

Verify the MCP configuration file path
Check that Node.js path is correct
Ensure PROJECT_ROOT environment variable is set
Check that the project has a .github/workflows/ directory

Contributing

Fork the repository
Create a feature branch
Make your changes
Add tests for new functionality
Ensure all tests pass
Submit a pull request

License

This project is licensed under the Apache License 2.0 - see the LICENSE file for details.

nektos/act - Run your GitHub Actions locally
Model Context Protocol - Protocol for AI assistant tool integration

Support

Create an issue for bug reports or feature requests
Check the documentation for detailed guides
Review existing issues for solutions

Note: This tool was originally developed for the Adobe Spectrum Tokens project and has been extracted as a standalone, reusable MCP server.

Available Tools

4 tools

act_doctorA

Check act configuration and Docker setup

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior2/5

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

With no annotations, the description bears full responsibility for behavioral disclosure, yet it only states the action without detailing side effects, permissions, error cases, or output nature.

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?

Extremely concise with no unnecessary words, front-loading the core action in a single, clear phrase.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description should indicate what the tool returns or how results are presented; it fails to do so, leaving the agent without information on output interpretation.

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?

There are no parameters, and the description adds full meaning by specifying the tool's purpose beyond the empty schema, but no further semantics are needed.

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 uses a specific verb 'Check' and clearly identifies the resources 'act configuration and Docker setup', which distinguishes it from sibling tools focused on workflows.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like list_workflows or validate_workflow, nor any context for prerequisites or conditions.

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

list_workflowsA

List all available GitHub Actions workflows in the repository

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose any behavioral traits such as whether the operation is read-only, requires authentication, or has any side effects. The description is too minimal to guide safe invocation.

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?

A single, front-loaded sentence with no wasted words. Every part contributes to the purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no parameters and no output schema, the description is somewhat complete but lacks information about the return format or any filtering behavior. It is minimally viable.

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?

The input schema has zero parameters, so schema coverage is 100%. The description adds no parameter information, but baseline for zero parameters is 4.

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 clearly states the verb 'list' and the resource 'workflows' with scope 'in the repository'. It distinguishes from siblings like 'run_workflow' and 'validate_workflow' which perform different actions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use or when not to use this tool. No mention of alternatives or context, leaving the agent to infer usage from the name alone.

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

run_workflowB

Run a GitHub Actions workflow locally using act

ParametersJSON Schema

Name	Required	Description	Default
`workflow`	Yes	Workflow file name (e.g., ci.yml) or job ID
`event`	No	Event type to trigger (push, pull_request, workflow_dispatch, etc.)	push
`dryRun`	No	Show what would run without executing
`verbose`	No	Enable verbose output for debugging
`env`	No	Environment variables to set for the workflow
`secrets`	No	Secrets to provide to the workflow
`eventData`	No	Custom event data to simulate specific scenarios

TDQS

B3/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior, but it only states the action without detailing side effects, permissions, error handling, or installation requirements for act.

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

Conciseness3/5

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

The description is a single sentence with no wasted words, but it is too terse; conciseness should not come at the expense of necessary detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 7 parameters (including nested objects), no output schema, and no annotations, the description is inadequate. It does not explain execution behavior, output format, or how to use complex parameters like env and secrets.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the schema's parameter descriptions; it does not explain how parameters interact or provide usage examples.

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 clearly states the verb 'Run' and the resource 'a GitHub Actions workflow locally using act', which is specific and distinguishes it from sibling tools like act_doctor, list_workflows, and validate_workflow.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like list_workflows or validate_workflow. No prerequisites or exclusions are mentioned, leaving the agent to infer usage from context.

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

validate_workflowB

Validate a workflow file syntax and structure

ParametersJSON Schema

Name	Required	Description	Default
`workflow`	Yes	Workflow file name to validate

TDQS

B3.3/5.0

Behavior2/5

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

No annotations provided. Description only states it validates syntax, but does not disclose whether it modifies state (likely read-only), what happens on validation failure, or any side effects.

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?

Single sentence, front-loaded, no redundancy. Efficient for a simple tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple validation tool with one parameter and no output schema, description covers the basic purpose. However, lacking behavioral details and return value information limits completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the description of the parameter 'workflow' is minimal ('Workflow file name to validate') but sufficient. Description adds no extra meaning beyond schema.

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?

Description clearly states 'Validate a workflow file syntax and structure', using a specific verb and resource. It distinguishes from siblings like list_workflows and run_workflow.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. No mention of prerequisites or when not to use it.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

Each tool targets a distinct action: checking setup, listing workflows, running them, and validating syntax. No overlap in purposes.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern (e.g., list_workflows, run_workflow) with 'act_doctor' as a slight exception but still clear.

Tool Count5/5

4 tools is well-scoped for the server's purpose of testing GitHub Actions workflows locally, covering essential operations without excess.

Completeness4/5

Covers the key operations: setup check, listing, running, and validation. Minor gap might be configuring act, but the set is functional for typical use.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

docs
dev.continue
An MCP server for docs.continue.dev
Documentation Access Developer Tools Search
2
Second server!
com.fenetresurciel.verylongmcp
A non functional MCP server (yet)
Developer Tools
2
Arlet
dev.arlet
Create, deploy, and operate MCP servers directly from your GitHub repositories.
Developer Tools CI/CD & DevOps
2
vercel-mcpOAuth
com.vercel
An MCP server for Vercel
Cloud Platforms Developer Tools CI/CD & DevOps
2

Related MCP Servers

mcp-server-commands
Shell Access Command Line OS Automation
g0t4
A
license
B
quality
C
maintenance
An MCP server to run commands.
Updated 10 days ago (2026-08-24 05:50 UTC)
1
662
232
MIT
GitHub MCP Serverofficial
Version Control Developer Tools
github
A
license
Not graded
quality
A
maintenance
GitHub's official MCP Server
Updated 4 hours ago (2026-09-03 13:57 UTC)
32,678
MIT
buildkite-mcp-server
CI/CD & DevOps Developer Tools Code Execution
buildkite
A
license
Not graded
quality
A
maintenance
Official MCP Server for Buildkite.
Updated 7 hours ago (2026-09-03 10:05 UTC)
53
MIT
crafty-mcp
Games & Gamification Virtualization App Automation
HadiCherkaoui
A
license
B
quality
C
maintenance
MCP Server for crafty controller
Updated 24 days ago (2026-08-10 14:25 UTC)
63
18
2
AGPL 3.0

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/GarthDB/act-testing-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Act Testing MCP

Purpose

Features

Prerequisites

Installing nektos/act

Installation

Verifying Package Integrity

Configuration

MCP Setup

Option 1: Using npx (Recommended)

Option 2: Using global installation

Option 3: With custom project path (if needed)

Option 4: Local development

Act Configuration

Tools Provided

list_workflows

run_workflow

validate_workflow

act_doctor

Usage Examples

With AI Assistant (Claude)

Direct Usage

Development

Running Tests

Testing Coverage

Compatibility Monitoring

Project Structure

Troubleshooting

Docker Issues

Act Issues

MCP Connection Issues

Contributing

License

Related Projects

Support

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

GitHub MCP Serverofficial

Latest Blog Posts

MCP directory API

`list_workflows`

`run_workflow`

`validate_workflow`

`act_doctor`