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ワークフローの管理と操作を可能にします。Claude Desktop、Codeium、Windsurfなど、複数のAIコーディングアシスタントと互換性があります。

特徴

  • 完全なワークフロー管理: ワークフローの一覧表示、トリガー、キャンセル、再実行

  • ワークフロー実行分析: ワークフロー実行とそのジョブに関する詳細情報を取得します。

  • 包括的なエラー処理: 詳細な情報を備えた明確なエラーメッセージ

  • 柔軟な型検証: APIのバリエーションを適切に処理する堅牢な型チェック

  • セキュリティ重視の設計: タイムアウト処理、レート制限、厳格な URL 検証

ツール

  1. list_workflows

    • GitHub リポジトリ内のワークフローを一覧表示する

    • 入力:

      • owner (文字列): リポジトリの所有者（ユーザー名または組織）

      • repo (文字列): リポジトリ名

      • page （オプションの数値）：ページ番号

      • perPage （オプションの数値）：1ページあたりの結果数（最大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 （オプションの数値）：1ページあたりの結果数（最大100件）

    • 戻り値: 条件に一致するワークフロー実行のリスト

  5. get_workflow_run

    • 特定のワークフロー実行の詳細を取得する

    • 入力:

      • owner (文字列): リポジトリの所有者（ユーザー名または組織）

      • repo (文字列): リポジトリ名

      • runId (数値): ワークフロー実行のID

    • 戻り値: 特定のワークフロー実行に関する詳細情報

  6. get_workflow_run_jobs

    • 特定のワークフロー実行のジョブを取得する

    • 入力:

      • owner (文字列): リポジトリの所有者（ユーザー名または組織）

      • repo (文字列): リポジトリ名

      • runId (数値): ワークフロー実行のID

      • filter （オプションの文字列）：完了ステータス（「最新」、「すべて」）でジョブをフィルタリングします

      • page （オプションの数値）：ページ番号

      • perPage （オプションの数値）：1ページあたりの結果数（最大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 サーバーは、Claude Desktop、Codeium、Windsurf などの複数の AI コーディング アシスタントと互換性があります。

クロードデスクトップ

まず、プロジェクトがビルドされていることを確認してください（以下のビルドセクションを参照）。次に、 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 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と同じ設定形式を使用します。上記の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]

これにより、MCP サーバーを実行するために必要なファイルがdistディレクトリに作成されます。

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