de en es ja ko ru zh

GitHub Actions MCP Server

Name: GitHub Actions MCP Server
Author: ko1ynnky

by ko1ynnky

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Servidor MCP de Acciones de GitHub

insignia de herrería

Servidor MCP para la API de GitHub Actions, que permite a los asistentes de IA gestionar y operar flujos de trabajo de GitHub Actions. Compatible con múltiples asistentes de programación de IA, como Claude Desktop, Codeium y Windsurf.

Características

Gestión completa del flujo de trabajo : enumerar, visualizar, activar, cancelar y volver a ejecutar flujos de trabajo
Análisis de ejecución del flujo de trabajo : obtenga información detallada sobre las ejecuciones del flujo de trabajo y sus trabajos
Manejo integral de errores : mensajes de error claros con detalles mejorados
Validación de tipos flexible : verificación de tipos robusta con manejo elegante de variaciones de API
Diseño centrado en la seguridad : gestión del tiempo de espera, limitación de velocidad y validación estricta de URL

Herramientas

list_workflows
- Enumerar flujos de trabajo en un repositorio de GitHub
- Entradas:
  - owner (cadena): propietario del repositorio (nombre de usuario u organización)
  - repo (cadena): nombre del repositorio
  - page (número opcional): Número de página para paginación
  - perPage (número opcional): Resultados por página (máximo 100)
- Devuelve: Lista de flujos de trabajo en el repositorio
get_workflow
- Obtener detalles de un flujo de trabajo específico
- Entradas:
  - owner (cadena): propietario del repositorio (nombre de usuario u organización)
  - repo (cadena): nombre del repositorio
  - workflowId (cadena o número): el ID del flujo de trabajo o nombre de archivo
- Devoluciones: Información detallada sobre el flujo de trabajo
get_workflow_usage
- Obtener estadísticas de uso de un flujo de trabajo
- Entradas:
  - owner (cadena): propietario del repositorio (nombre de usuario u organización)
  - repo (cadena): nombre del repositorio
  - workflowId (cadena o número): el ID del flujo de trabajo o nombre de archivo
- Devoluciones: Estadísticas de uso, incluidos los minutos facturables
list_workflow_runs
- Enumere todas las ejecuciones de flujo de trabajo para un repositorio o un flujo de trabajo específico
- Entradas:
  - owner (cadena): propietario del repositorio (nombre de usuario u organización)
  - repo (cadena): nombre del repositorio
  - workflowId (cadena o número opcional): el ID del flujo de trabajo o el nombre del archivo
  - actor (cadena opcional): Filtrar por usuario que activó el flujo de trabajo
  - branch (cadena opcional): Filtrar por rama
  - event (cadena opcional): Filtrar por tipo de evento
  - status (cadena opcional): Filtrar por estado
  - created (cadena opcional): Filtrar por fecha de creación (AAAA-MM-DD)
  - excludePullRequests (booleano opcional): Excluye ejecuciones activadas por PR
  - checkSuiteId (número opcional): Filtrar por ID de suite de verificación
  - page (número opcional): Número de página para paginación
  - perPage (número opcional): Resultados por página (máximo 100)
- Devoluciones: Lista de ejecuciones de flujo de trabajo que coinciden con los criterios
get_workflow_run
- Obtener detalles de una ejecución de flujo de trabajo específica
- Entradas:
  - owner (cadena): propietario del repositorio (nombre de usuario u organización)
  - repo (cadena): nombre del repositorio
  - runId (número): El ID de la ejecución del flujo de trabajo
- Devoluciones: Información detallada sobre la ejecución del flujo de trabajo específico
get_workflow_run_jobs
- Obtener trabajos para una ejecución de flujo de trabajo específica
- Entradas:
  - owner (cadena): propietario del repositorio (nombre de usuario u organización)
  - repo (cadena): nombre del repositorio
  - runId (número): El ID de la ejecución del flujo de trabajo
  - filter (cadena opcional): filtrar trabajos por estado de finalización ('más reciente', 'todos')
  - page (número opcional): Número de página para paginación
  - perPage (número opcional): Resultados por página (máximo 100)
- Devuelve: Lista de trabajos en la ejecución del flujo de trabajo
trigger_workflow
- Activar una ejecución de flujo de trabajo
- Entradas:
  - owner (cadena): propietario del repositorio (nombre de usuario u organización)
  - repo (cadena): nombre del repositorio
  - workflowId (cadena o número): el ID del flujo de trabajo o nombre de archivo
  - ref (cadena): La referencia para ejecutar el flujo de trabajo (rama, etiqueta o SHA)
  - inputs (objeto opcional): parámetros de entrada para el flujo de trabajo
- Devoluciones: Información sobre la ejecución del flujo de trabajo activado
cancel_workflow_run
- Cancelar una ejecución de flujo de trabajo
- Entradas:
  - owner (cadena): propietario del repositorio (nombre de usuario u organización)
  - repo (cadena): nombre del repositorio
  - runId (número): El ID de la ejecución del flujo de trabajo
- Devoluciones: Estado de la operación de cancelación
rerun_workflow
- Volver a ejecutar una ejecución de flujo de trabajo
- Entradas:
  - owner (cadena): propietario del repositorio (nombre de usuario u organización)
  - repo (cadena): nombre del repositorio
  - runId (número): El ID de la ejecución del flujo de trabajo
- Devuelve: Estado de la operación de re-ejecución

Uso con asistentes de codificación de IA

Este servidor MCP es compatible con múltiples asistentes de codificación de IA, incluidos Claude Desktop, Codeium y Windsurf.

Escritorio de Claude

Primero, asegúrese de haber compilado el proyecto (consulte la sección "Compilación" más abajo). Luego, agregue lo siguiente a su claude_desktop_config.json :

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

Codeio

Agregue la siguiente configuración a su archivo de configuración Codeium MCP (normalmente en ~/.codeium/windsurf/mcp_config.json en sistemas basados en Unix o %USERPROFILE%\.codeium\windsurf\mcp_config.json en Windows):

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

Windsurf

Windsurf utiliza el mismo formato de configuración que Codeium. Añada el servidor a su configuración de Windsurf MCP como se muestra arriba para Codeium.

Related MCP server: GitHub MCP Server

Construir

Unix/Linux/macOS

Clonar el repositorio y compilar:

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

Ventanas

Para sistemas Windows, utilice el comando de compilación específico de Windows:

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

Alternativamente, puede utilizar el archivo por lotes incluido:

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

Esto creará los archivos necesarios en el directorio dist que necesitará para ejecutar el servidor MCP.

Instrucciones específicas de Windows

Prerrequisitos

Node.js (v14 o superior)
npm (v6 o superior)

Ejecución del servidor en Windows

Usando el archivo por lotes (método más simple):
```
run-server.bat [optional-github-token]
```
Esto verificará si la compilación existe, la compilará si es necesario e iniciará el servidor.
Usando npm directamente:
```
npm run start
```

Configuración del token de acceso personal de GitHub en Windows

Para obtener una funcionalidad completa y evitar la limitación de velocidad, debe configurar su token de acceso personal de GitHub.

Opciones:

Páselo como parámetro al archivo por lotes:
```
run-server.bat your_github_token_here
```

Establezcalo como una variable de entorno:

set GITHUB_PERSONAL_ACCESS_TOKEN=your_github_token_here
npm run start

Solución de problemas de Windows

Si encuentra problemas:

Errores de compilación : asegúrese de que TypeScript esté instalado correctamente.
```
npm install -g typescript
```
Problemas de permisos : asegúrese de estar ejecutando los comandos en un símbolo del sistema con los permisos adecuados.
Errores de Node.js : verifique que esté usando una versión de Node.js compatible.
```
node --version
```

Ejemplos de uso

Enumerar flujos de trabajo en un repositorio:

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

Activar un flujo de trabajo:

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

Solución de problemas

Problemas comunes

Errores de autenticación :
- Asegúrese de que su token de GitHub tenga los permisos correctos
- Compruebe que el token esté configurado correctamente como variable de entorno
Limitación de velocidad :
- El servidor implementa una limitación de velocidad para evitar alcanzar los límites de la API de GitHub
- Si encuentra errores de límite de velocidad, reduzca la frecuencia de las solicitudes
Errores de validación de tipo :
- Las respuestas de la API de GitHub a veces pueden diferir de los esquemas esperados
- El servidor implementa una validación flexible para manejar la mayoría de las variaciones
- Si encuentra errores persistentes, abra un problema.

Licencia

Este servidor MCP tiene licencia MIT.

Available Tools

9 tools

cancel_workflow_runD

ParametersJSON Schema

Name	Required	Description
`owner`	Yes	Repository owner (username or organization)
`repo`	Yes	Repository name
`runId`	Yes	The 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

Name	Required	Description
`owner`	Yes	Repository owner (username or organization)
`repo`	Yes	Repository name
`workflowId`	Yes	The 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

Name	Required	Description
`owner`	Yes	Repository owner (username or organization)
`repo`	Yes	Repository name
`runId`	Yes	The 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

Name	Required	Description
`owner`	Yes	Repository owner (username or organization)
`repo`	Yes	Repository name
`runId`	Yes	The ID of the workflow run
`filter`	No	Filter jobs by their completed_at date
`page`	No	Page number for pagination
`perPage`	No	Results 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

Name	Required	Description
`owner`	Yes	Repository owner (username or organization)
`repo`	Yes	Repository name
`workflowId`	Yes	The 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

Name	Required	Description
`owner`	Yes	Repository owner (username or organization)
`repo`	Yes	Repository name
`workflowId`	No	The ID of the workflow or filename (string or number)
`actor`	No	Returns someone's workflow runs. Use the login for the user
`branch`	No	Returns workflow runs associated with a branch
`event`	No	Returns workflow runs triggered by the event
`status`	No	Returns workflow runs with the check run status
`created`	No	Returns workflow runs created within date range (YYYY-MM-DD)
`excludePullRequests`	No	If true, pull requests are omitted from the response
`checkSuiteId`	No	Returns workflow runs with the check_suite_id
`page`	No	Page number for pagination
`perPage`	No	Results 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

Name	Required	Description
`owner`	Yes	Repository owner (username or organization)
`repo`	Yes	Repository name
`page`	No	Page number for pagination
`perPage`	No	Results 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

Name	Required	Description
`owner`	Yes	Repository owner (username or organization)
`repo`	Yes	Repository name
`runId`	Yes	The 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

Name	Required	Description
`owner`	Yes	Repository owner (username or organization)
`repo`	Yes	Repository name
`workflowId`	Yes	The ID of the workflow or filename (string or number)
`ref`	Yes	The reference of the workflow run (branch, tag, or SHA)
`inputs`	No	Input 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.

4 tool updatesv1.0.0Jan 2, 2026

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"

9 tool updatesApr 7, 2025
- 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

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

C2.1/5.0

Scored 2026-04-18 11:05 across 9 tools

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

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

FlowraOAuth
io.github.flowradev
MCP server for your apps' tools and custom tools, plus hosted AI agents and approval-gated workflows
Agent Orchestration Autonomous Agents
1
driflyte-mcp-server
com.driflyte
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
Search Web Scraping Knowledge & Memory
211
gread A
io.github.NitroRCr
An MCP server that gives your AI access to the source code and docs of all public github repos
Version Control Code Analysis Documentation Access
5365
ArletOAuth
dev.arlet
Create, deploy, and operate MCP servers directly from your GitHub repositories.
Developer Tools CI/CD & DevOps
2

Related MCP Servers

GitHub CLI MCP Server
Version Control Developer Tools App Automation
CodingButterBot
A
license
Not graded
quality
D
maintenance
An MCP server that wraps around the GitHub CLI tool, allowing AI assistants to interact with GitHub repositories through commands for pull requests, issues, and repository operations.
Updated a year ago (2025-05-02 04:53 UTC)
15 npm
MIT
GitHub MCP Server
Version Control Developer Tools
grysonbaltazar
A
license
Not graded
quality
D
maintenance
An MCP server that provides tools for interacting with the GitHub API, enabling AI assistants to query repositories, pull requests, issues, commits, users, and more.
Updated a year ago (2025-11-03 16:42 UTC)
494 npm
ISC
GitHub MCP Server
Version Control Developer Tools CI/CD & DevOps
Pawangunjkar
A
license
B
quality
C
maintenance
A comprehensive MCP server that exposes 73 GitHub API tools for managing repositories, pull requests, issues, actions, releases, search, and more, enabling natural language control of GitHub.
Updated 2 months ago (2026-08-01 13:36 UTC)
73
MIT
github-directory-mcp
Version Control Developer Tools
Productdeveloper5192
F
license
A
quality
C
maintenance
An MCP server that enables AI assistants to list GitHub repositories for a user or organization and list directories within a repository via the GitHub REST API.
Updated 3 months ago (2026-07-27 15:54 UTC)
2
-

Servidor MCP de Acciones de GitHub

Características

Herramientas

Uso con asistentes de codificación de IA

Escritorio de Claude

Codeio

Windsurf

Construir

Unix/Linux/macOS

Ventanas

Instrucciones específicas de Windows

Ejemplos de uso

Solución de problemas

Problemas comunes

Licencia

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches