Skip to main content
Glama
deenesjakoruzh
ko1ynnky

GitHub Actions MCP Server

by ko1ynnky
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

GitHub Actions MCP Server

⚠️ Archive Notice: This repository will be archived soon as the official GitHub MCP server is adding Actions support. See github/github-mcp-server#491 for details on the official implementation.

MCP Server for the GitHub Actions API, enabling AI assistants to manage and operate GitHub Actions workflows. Compatible with multiple AI coding assistants including Claude Desktop, Codeium, and Windsurf.

Features

  • Complete Workflow Management: List, view, trigger, cancel, and rerun workflows

  • Workflow Run Analysis: Get detailed information about workflow runs and their jobs

  • Comprehensive Error Handling: Clear error messages with enhanced details

  • Flexible Type Validation: Robust type checking with graceful handling of API variations

  • Security-Focused Design: Timeout handling, rate limiting, and strict URL validation

Tools

  1. list_workflows

    • List workflows in a GitHub repository

    • Inputs:

      • owner (string): Repository owner (username or organization)

      • repo (string): Repository name

      • page (optional number): Page number for pagination

      • perPage (optional number): Results per page (max 100)

    • Returns: List of workflows in the repository

  2. get_workflow

    • Get details of a specific workflow

    • Inputs:

      • owner (string): Repository owner (username or organization)

      • repo (string): Repository name

      • workflowId (string or number): The ID of the workflow or filename

    • Returns: Detailed information about the workflow

  3. get_workflow_usage

    • Get usage statistics of a workflow

    • Inputs:

      • owner (string): Repository owner (username or organization)

      • repo (string): Repository name

      • workflowId (string or number): The ID of the workflow or filename

    • Returns: Usage statistics including billable minutes

  4. list_workflow_runs

    • List all workflow runs for a repository or a specific workflow

    • Inputs:

      • owner (string): Repository owner (username or organization)

      • repo (string): Repository name

      • workflowId (optional string or number): The ID of the workflow or filename

      • actor (optional string): Filter by user who triggered the workflow

      • branch (optional string): Filter by branch

      • event (optional string): Filter by event type

      • status (optional string): Filter by status

      • created (optional string): Filter by creation date (YYYY-MM-DD)

      • excludePullRequests (optional boolean): Exclude PR-triggered runs

      • checkSuiteId (optional number): Filter by check suite ID

      • page (optional number): Page number for pagination

      • perPage (optional number): Results per page (max 100)

    • Returns: List of workflow runs matching the criteria

  5. get_workflow_run

    • Get details of a specific workflow run

    • Inputs:

      • owner (string): Repository owner (username or organization)

      • repo (string): Repository name

      • runId (number): The ID of the workflow run

    • Returns: Detailed information about the specific workflow run

  6. get_workflow_run_jobs

    • Get jobs for a specific workflow run

    • Inputs:

      • owner (string): Repository owner (username or organization)

      • repo (string): Repository name

      • runId (number): The ID of the workflow run

      • filter (optional string): Filter jobs by completion status ('latest', 'all')

      • page (optional number): Page number for pagination

      • perPage (optional number): Results per page (max 100)

    • Returns: List of jobs in the workflow run

  7. trigger_workflow

    • Trigger a workflow run

    • Inputs:

      • owner (string): Repository owner (username or organization)

      • repo (string): Repository name

      • workflowId (string or number): The ID of the workflow or filename

      • ref (string): The reference to run the workflow on (branch, tag, or SHA)

      • inputs (optional object): Input parameters for the workflow

    • Returns: Information about the triggered workflow run

  8. cancel_workflow_run

    • Cancel a workflow run

    • Inputs:

      • owner (string): Repository owner (username or organization)

      • repo (string): Repository name

      • runId (number): The ID of the workflow run

    • Returns: Status of the cancellation operation

  9. rerun_workflow

    • Re-run a workflow run

    • Inputs:

      • owner (string): Repository owner (username or organization)

      • repo (string): Repository name

      • runId (number): The ID of the workflow run

    • Returns: Status of the re-run operation

Usage with AI Coding Assistants

This MCP server is compatible with multiple AI coding assistants including Claude Desktop, Codeium, and Windsurf.

Claude Desktop

First, make sure you have built the project (see Build section below). Then, add the following to your claude_desktop_config.json:

{
  "mcpServers": {
    "github-actions": {
      "command": "node",
      "args": [
        "<path-to-mcp-server>/dist/index.js"
      ],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "<YOUR_TOKEN>"
      }
    }
  }
}

Codeium

Add the following configuration to your Codeium MCP config file (typically at ~/.codeium/windsurf/mcp_config.json on Unix-based systems or %USERPROFILE%\.codeium\windsurf\mcp_config.json on Windows):

{
  "mcpServers": {
    "github-actions": {
      "command": "node",
      "args": [
        "<path-to-mcp-server>/dist/index.js"
      ],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "<YOUR_TOKEN>"
      }
    }
  }
}

Windsurf

Windsurf uses the same configuration format as Codeium. Add the server to your Windsurf MCP configuration as shown above for Codeium.

Related MCP server: GitHub MCP Server

Build

Unix/Linux/macOS

Clone the repository and build:

git clone https://github.com/ko1ynnky/github-actions-mcp-server.git
cd github-actions-mcp-server
npm install
npm run build

Windows

For Windows systems, use the Windows-specific build command:

git clone https://github.com/ko1ynnky/github-actions-mcp-server.git
cd github-actions-mcp-server
npm install
npm run build:win

Alternatively, you can use the included batch file:

run-server.bat [optional-github-token]

This will create the necessary files in the dist directory that you'll need to run the MCP server.

Windows-Specific Instructions

Prerequisites

  • Node.js (v14 or higher)

  • npm (v6 or higher)

Running the Server on Windows

  1. Using the batch file (simplest method):

    run-server.bat [optional-github-token]

    This will check if the build exists, build if needed, and start the server.

  2. Using npm directly:

    npm run start

Setting GitHub Personal Access Token on Windows

For full functionality and to avoid rate limiting, you need to set your GitHub Personal Access Token.

Options:

  1. Pass it as a parameter to the batch file:

    run-server.bat your_github_token_here

  2. Set it as an environment variable:

    set GITHUB_PERSONAL_ACCESS_TOKEN=your_github_token_here
npm run start

Troubleshooting Windows Issues

If you encounter issues:

  1. Build errors: Make sure TypeScript is installed correctly.

    npm install -g typescript

  2. Permission issues: Ensure you're running the commands in a command prompt with appropriate permissions.

  3. Node.js errors: Verify you're using a compatible Node.js version.

    node --version

Usage Examples

List workflows in a repository:

const result = await listWorkflows({
  owner: "your-username",
  repo: "your-repository"
});

Trigger a workflow:

const result = await triggerWorkflow({
  owner: "your-username",
  repo: "your-repository",
  workflowId: "ci.yml",
  ref: "main",
  inputs: {
    environment: "production"
  }
});

Troubleshooting

Common Issues

  1. Authentication Errors:

    • Ensure your GitHub token has the correct permissions

    • Check that the token is correctly set as an environment variable

  2. Rate Limiting:

    • The server implements rate limiting to avoid hitting GitHub API limits

    • If you encounter rate limit errors, reduce the frequency of requests

  3. Type Validation Errors:

    • GitHub API responses might sometimes differ from expected schemas

    • The server implements flexible validation to handle most variations

    • If you encounter persistent errors, please open an issue

License

This MCP server is licensed under the MIT License.

Available Tools

9 tools
cancel_workflow_runD
ParametersJSON Schema
NameRequiredDescriptionDefault
ownerYesRepository owner (username or organization)
repoYesRepository name
runIdYesThe ID of the workflow run

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_workflowD
ParametersJSON Schema
NameRequiredDescriptionDefault
ownerYesRepository owner (username or organization)
repoYesRepository name
workflowIdYesThe ID of the workflow or filename (string or number)

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_workflow_runD
ParametersJSON Schema
NameRequiredDescriptionDefault
ownerYesRepository owner (username or organization)
repoYesRepository name
runIdYesThe ID of the workflow run

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_workflow_run_jobsD
ParametersJSON Schema
NameRequiredDescriptionDefault
ownerYesRepository owner (username or organization)
repoYesRepository name
runIdYesThe ID of the workflow run
filterNoFilter jobs by their completed_at date
pageNoPage number for pagination
perPageNoResults per page (max 100)

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_workflow_usageD
ParametersJSON Schema
NameRequiredDescriptionDefault
ownerYesRepository owner (username or organization)
repoYesRepository name
workflowIdYesThe ID of the workflow or filename (string or number)

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

list_workflow_runsD
ParametersJSON Schema
NameRequiredDescriptionDefault
ownerYesRepository owner (username or organization)
repoYesRepository name
workflowIdNoThe ID of the workflow or filename (string or number)
actorNoReturns someone's workflow runs. Use the login for the user
branchNoReturns workflow runs associated with a branch
eventNoReturns workflow runs triggered by the event
statusNoReturns workflow runs with the check run status
createdNoReturns workflow runs created within date range (YYYY-MM-DD)
excludePullRequestsNoIf true, pull requests are omitted from the response
checkSuiteIdNoReturns workflow runs with the check_suite_id
pageNoPage number for pagination
perPageNoResults per page (max 100)

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

list_workflowsD
ParametersJSON Schema
NameRequiredDescriptionDefault
ownerYesRepository owner (username or organization)
repoYesRepository name
pageNoPage number for pagination
perPageNoResults per page (max 100)

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

rerun_workflowD
ParametersJSON Schema
NameRequiredDescriptionDefault
ownerYesRepository owner (username or organization)
repoYesRepository name
runIdYesThe ID of the workflow run

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

trigger_workflowD
ParametersJSON Schema
NameRequiredDescriptionDefault
ownerYesRepository owner (username or organization)
repoYesRepository name
workflowIdYesThe ID of the workflow or filename (string or number)
refYesThe reference of the workflow run (branch, tag, or SHA)
inputsNoInput parameters for the workflow

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 4 tool updatesv1.0.0
    • Changedget_workflow2 fields changed
      • changedInput schema / properties / workflowId / description
        Previous value: -"The ID of the workflow or filename"New value: +"The ID of the workflow or filename (string or number)"
      • changedInput schema / properties / workflowId / type
        Previous value: -[
-  "string",
-  "number"
-]New value: +"string"
    • Changedget_workflow_usage2 fields changed
      • changedInput schema / properties / workflowId / description
        Previous value: -"The ID of the workflow or filename"New value: +"The ID of the workflow or filename (string or number)"
      • changedInput schema / properties / workflowId / type
        Previous value: -[
-  "string",
-  "number"
-]New value: +"string"
    • Changedlist_workflow_runs2 fields changed
      • changedInput schema / properties / workflowId / description
        Previous value: -"The ID of the workflow or filename"New value: +"The ID of the workflow or filename (string or number)"
      • changedInput schema / properties / workflowId / type
        Previous value: -[
-  "string",
-  "number"
-]New value: +"string"
    • Changedtrigger_workflow2 fields changed
      • changedInput schema / properties / workflowId / description
        Previous value: -"The ID of the workflow or filename"New value: +"The ID of the workflow or filename (string or number)"
      • changedInput schema / properties / workflowId / type
        Previous value: -[
-  "string",
-  "number"
-]New value: +"string"
  2. 9 tool updates
    • First observedcancel_workflow_run
    • First observedget_workflow
    • First observedget_workflow_run
    • First observedget_workflow_run_jobs
    • First observedget_workflow_usage
    • First observedlist_workflow_runs
    • First observedlist_workflows
    • First observedrerun_workflow
    • First observedtrigger_workflow
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

C2.1/5.0
Disambiguation5/5

Every tool has a clearly distinct purpose targeting specific GitHub Actions resources and operations. The naming clearly indicates whether tools retrieve information (get_, list_), trigger actions (trigger_, rerun_, cancel_), or access different aspects (workflows, runs, jobs, usage). There is no ambiguity or overlap in functionality.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with perfect uniformity. The verbs (cancel, get, list, rerun, trigger) are consistently applied to clearly defined nouns (workflow, workflow_run, workflow_run_jobs, etc.). There are no deviations in naming conventions or styles.

Tool Count5/5

With 9 tools, this server is well-scoped for managing GitHub Actions workflows. The count is appropriate for covering core operations like listing, retrieving, triggering, and managing workflow runs without being overwhelming. Each tool serves a distinct purpose that earns its place in the set.

Completeness4/5

The tool surface provides excellent coverage for the GitHub Actions domain with operations for listing, retrieving, triggering, rerunning, and canceling workflows and runs. Minor gaps might include tools for managing workflow files or secrets, but the core lifecycle operations are well-covered for typical agent workflows.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

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/ko1ynnky/github-actions-mcp-server'

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