Skip to main content
Glama
deenesjakoruzh
ko1ynnky

GitHub Actions MCP Server

by ko1ynnky
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

GitHub Actions MCP 服务器

铁匠徽章

适用于 GitHub Actions API 的 MCP 服务器，使 AI 助手能够管理和操作 GitHub Actions 工作流程。兼容多种 AI 编码助手，包括 Claude Desktop、Codeium 和 Windsurf。

特征

  • 完整的工作流管理：列出、查看、触发、取消和重新运行工作流

  • 工作流运行分析：获取有关工作流运行及其作业的详细信息

  • 全面的错误处理：清晰的错误信息，增强详细信息

  • 灵活的类型验证：强大的类型检查，优雅地处理 API 变化

  • 以安全为中心的设计：超时处理、速率限制和严格的 URL 验证

工具

  1. list_workflows

    • 列出 GitHub 存储库中的工作流程

    • 输入：

      • owner （字符串）：存储库所有者（用户名或组织）

      • repo （字符串）：存储库名称

      • page （可选数字）：分页的页码

      • perPage （可选数字）：每页结果数（最多 100 条）

    • 返回：存储库中的工作流列表

  2. get_workflow

    • 获取特定工作流的详细信息

    • 输入：

      • owner （字符串）：存储库所有者（用户名或组织）

      • repo （字符串）：存储库名称

      • workflowId （字符串或数字）：工作流程或文件名的 ID

    • 返回：有关工作流程的详细信息

  3. get_workflow_usage

    • 获取工作流的使用情况统计信息

    • 输入：

      • owner （字符串）：存储库所有者（用户名或组织）

      • repo （字符串）：存储库名称

      • workflowId （字符串或数字）：工作流程或文件名的 ID

    • 返回：使用情况统计数据，包括计费分钟数

  4. list_workflow_runs

    • 列出存储库或特定工作流程的所有工作流程运行

    • 输入：

      • owner （字符串）：存储库所有者（用户名或组织）

      • repo （字符串）：存储库名称

      • workflowId （可选字符串或数字）：工作流程或文件名的 ID

      • actor （可选字符串）：按触发工作流程的用户进行过滤

      • branch （可选字符串）：按分支过滤

      • event （可选字符串）：按事件类型过滤

      • status （可选字符串）：按状态过滤

      • created （可选字符串）：按创建日期过滤（YYYY-MM-DD）

      • excludePullRequests （可选布尔值）：排除 PR 触发的运行

      • checkSuiteId （可选数字）：按检查套件 ID 进行过滤

      • page （可选数字）：分页的页码

      • perPage （可选数字）：每页结果数（最多 100 条）

    • 返回：符合条件的工作流运行列表

  5. get_workflow_run

    • 获取特定工作流程运行的详细信息

    • 输入：

      • owner （字符串）：存储库所有者（用户名或组织）

      • repo （字符串）：存储库名称

      • runId （数字）：工作流程运行的 ID

    • 返回：有关特定工作流程运行的详细信息

  6. get_workflow_run_jobs

    • 获取特定工作流程运行的作业

    • 输入：

      • owner （字符串）：存储库所有者（用户名或组织）

      • repo （字符串）：存储库名称

      • runId （数字）：工作流程运行的 ID

      • filter （可选字符串）：按完成状态过滤作业（‘最新’，‘全部’）

      • page （可选数字）：分页的页码

      • perPage （可选数字）：每页结果数（最多 100 条）

    • 返回：工作流程运行中的作业列表

  7. trigger_workflow

    • 触发工作流程运行

    • 输入：

      • owner （字符串）：存储库所有者（用户名或组织）

      • repo （字符串）：存储库名称

      • workflowId （字符串或数字）：工作流程或文件名的 ID

      • ref （字符串）：运行工作流的引用（分支、标签或 SHA）

      • inputs （可选对象）：工作流的输入参数

    • 返回：有关触发的工作流程运行的信息

  8. cancel_workflow_run

    • 取消工作流程运行

    • 输入：

      • owner （字符串）：存储库所有者（用户名或组织）

      • repo （字符串）：存储库名称

      • runId （数字）：工作流程运行的 ID

    • 返回：取消操作的状态

  9. rerun_workflow

    • 重新运行工作流程

    • 输入：

      • owner （字符串）：存储库所有者（用户名或组织）

      • repo （字符串）：存储库名称

      • runId （数字）：工作流程运行的 ID

    • 返回：重新运行操作的状态

与 AI 编码助手一起使用

该 MCP 服务器兼容多种 AI 编码助手，包括 Claude Desktop、Codeium 和 Windsurf。

克劳德桌面

首先，确保你已经构建了项目（参见下面的“构建”部分）。然后，将以下内容添加到你的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

将以下配置添加到您的 Codeium MCP 配置文件（通常在基于 Unix 的系统上为~/.codeium/windsurf/mcp_config.json或在 Windows 上%USERPROFILE%\.codeium\windsurf\mcp_config.json ）：

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

风帆冲浪

Windsurf 使用与 Codeium 相同的配置格式。请按照上图所示，将服务器添加到 Windsurf MCP 配置中。

Related MCP server: GitHub MCP Server

建造

Unix/Linux/macOS

克隆存储库并构建：

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

视窗

对于 Windows 系统，使用 Windows 特定的构建命令：

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

或者，您可以使用附带的批处理文件：

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

这将在dist目录中创建运行 MCP 服务器所需的必要文件。

Windows 特定说明

先决条件

  • Node.js（v14 或更高版本）

  • npm（v6 或更高版本）

在 Windows 上运行服务器

  1. 使用批处理文件（最简单的方法）：

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

    这将检查构建是否存在，如果需要则构建，然后启动服务器。

  2. 直接使用 npm：

    npm run start

在 Windows 上设置 GitHub 个人访问令牌

为了获得完整的功能并避免速率限制，您需要设置您的 GitHub 个人访问令牌。

选项：

  1. 将其作为参数传递给批处理文件：

    run-server.bat your_github_token_here

  2. 将其设置为环境变量：

    set GITHUB_PERSONAL_ACCESS_TOKEN=your_github_token_here
npm run start

解决 Windows 问题

如果您遇到问题：

  1. 构建错误：确保 TypeScript 已正确安装。

    npm install -g typescript

  2. 权限问题：确保您在命令提示符中以适当的权限运行命令。

  3. Node.js 错误：验证您是否使用了兼容的 Node.js 版本。

    node --version

使用示例

列出存储库中的工作流程：

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

触发工作流程：

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

故障排除

常见问题

  1. 身份验证错误：

    • 确保您的 GitHub 令牌具有正确的权限

    • 检查令牌是否正确设置为环境变量

  2. 速率限制：

    • 服务器实施速率限制以避免达到 GitHub API 限制

    • 如果遇到速率限制错误，请降低请求频率

  3. 类型验证错误：

    • GitHub API 响应有时可能与预期模式不同

    • 服务器实现灵活的验证来处理大多数变化

    • 如果您遇到持续性错误，请打开一个问题

执照

此 MCP 服务器根据 MIT 许可证获得许可。

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.

  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
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 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

Related MCP Connectors

Related MCP Servers

Appeared in Searches