Skip to main content
Glama
deenesjakoruzh
ko1ynnky

GitHub Actions MCP Server

by ko1ynnky
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

GitHub Actions MCP-Server

Schmiedeabzeichen

MCP-Server für die GitHub Actions API, der KI-Assistenten die Verwaltung und Bedienung von GitHub Actions-Workflows ermöglicht. Kompatibel mit mehreren KI-Programmierassistenten, darunter Claude Desktop, Codeium und Windsurf.

Merkmale

  • Umfassendes Workflow-Management : Workflows auflisten, anzeigen, auslösen, abbrechen und erneut ausführen

  • Analyse der Workflow-Läufe : Erhalten Sie detaillierte Informationen zu Workflow-Läufen und deren Jobs

  • Umfassende Fehlerbehandlung : Klare Fehlermeldungen mit erweiterten Details

  • Flexible Typvalidierung : Robuste Typprüfung mit eleganter Handhabung von API-Variationen

  • Sicherheitsorientiertes Design : Timeout-Behandlung, Ratenbegrenzung und strenge URL-Validierung

Werkzeuge

  1. list_workflows

    • Auflisten von Workflows in einem GitHub-Repository

    • Eingänge:

      • owner (Zeichenfolge): Repository-Besitzer (Benutzername oder Organisation)

      • repo (Zeichenfolge): Repository-Name

      • page (optionale Zahl): Seitenzahl für die Paginierung

      • perPage (optionale Zahl): Ergebnisse pro Seite (max. 100)

    • Rückgabe: Liste der Workflows im Repository

  2. get_workflow

    • Abrufen von Details zu einem bestimmten Workflow

    • Eingänge:

      • owner (Zeichenfolge): Repository-Besitzer (Benutzername oder Organisation)

      • repo (Zeichenfolge): Repository-Name

      • workflowId (Zeichenfolge oder Zahl): Die ID des Workflows oder der Dateiname

    • Retouren: Detaillierte Informationen zum Workflow

  3. get_workflow_usage

    • Abrufen der Nutzungsstatistik eines Workflows

    • Eingänge:

      • owner (Zeichenfolge): Repository-Besitzer (Benutzername oder Organisation)

      • repo (Zeichenfolge): Repository-Name

      • workflowId (Zeichenfolge oder Zahl): Die ID des Workflows oder der Dateiname

    • Rückgabe: Nutzungsstatistiken einschließlich abrechenbarer Minuten

  4. list_workflow_runs

    • Auflisten aller Workflow-Ausführungen für ein Repository oder einen bestimmten Workflow

    • Eingänge:

      • owner (Zeichenfolge): Repository-Besitzer (Benutzername oder Organisation)

      • repo (Zeichenfolge): Repository-Name

      • workflowId (optionale Zeichenfolge oder Zahl): Die ID des Workflows oder der Dateiname

      • actor (optionale Zeichenfolge): Filtern nach Benutzer, der den Workflow ausgelöst hat

      • branch (optionale Zeichenfolge): Nach Zweig filtern

      • event (optionale Zeichenfolge): Filtern nach Ereignistyp

      • status (optionale Zeichenfolge): Nach Status filtern

      • created (optionale Zeichenfolge): Filtern nach Erstellungsdatum (JJJJ-MM-TT)

      • excludePullRequests (optionaler Boolescher Wert): PR-getriggerte Läufe ausschließen

      • checkSuiteId (optionale Zahl): Filtern nach Check-Suite-ID

      • page (optionale Zahl): Seitenzahl für die Paginierung

      • perPage (optionale Zahl): Ergebnisse pro Seite (max. 100)

    • Gibt zurück: Liste der Workflow-Läufe, die den Kriterien entsprechen

  5. get_workflow_run

    • Abrufen von Details zu einem bestimmten Workflow-Ausführungsvorgang

    • Eingänge:

      • owner (Zeichenfolge): Repository-Besitzer (Benutzername oder Organisation)

      • repo (Zeichenfolge): Repository-Name

      • runId (Nummer): Die ID des Workflow-Laufs

    • Rückgabe: Detaillierte Informationen zum jeweiligen Workflow-Lauf

  6. get_workflow_run_jobs

    • Abrufen von Aufträgen für einen bestimmten Workflow-Lauf

    • Eingänge:

      • owner (Zeichenfolge): Repository-Besitzer (Benutzername oder Organisation)

      • repo (Zeichenfolge): Repository-Name

      • runId (Nummer): Die ID des Workflow-Laufs

      • filter (optionale Zeichenfolge): Filtern Sie Jobs nach Abschlussstatus („neueste“, „alle“)

      • page (optionale Zahl): Seitenzahl für die Paginierung

      • perPage (optionale Zahl): Ergebnisse pro Seite (max. 100)

    • Gibt zurück: Liste der Jobs im Workflow-Lauf

  7. trigger_workflow

    • Auslösen eines Workflow-Laufs

    • Eingänge:

      • owner (Zeichenfolge): Repository-Besitzer (Benutzername oder Organisation)

      • repo (Zeichenfolge): Repository-Name

      • workflowId (Zeichenfolge oder Zahl): Die ID des Workflows oder der Dateiname

      • ref (Zeichenfolge): Die Referenz, auf der der Workflow ausgeführt werden soll (Zweig, Tag oder SHA)

      • inputs (optionales Objekt): Eingabeparameter für den Workflow

    • Rückgabe: Informationen zum ausgelösten Workflow-Lauf

  8. cancel_workflow_run

    • Abbrechen einer Workflow-Ausführung

    • Eingänge:

      • owner (Zeichenfolge): Repository-Besitzer (Benutzername oder Organisation)

      • repo (Zeichenfolge): Repository-Name

      • runId (Nummer): Die ID des Workflow-Laufs

    • Retouren: Status des Stornierungsvorgangs

  9. rerun_workflow

    • Einen Workflow-Lauf erneut ausführen

    • Eingänge:

      • owner (Zeichenfolge): Repository-Besitzer (Benutzername oder Organisation)

      • repo (Zeichenfolge): Repository-Name

      • runId (Nummer): Die ID des Workflow-Laufs

    • Rückgabe: Status des erneut ausgeführten Vorgangs

Verwendung mit KI-Codierungsassistenten

Dieser MCP-Server ist mit mehreren KI-Codierungsassistenten kompatibel, darunter Claude Desktop, Codeium und Windsurf.

Claude Desktop

Stellen Sie zunächst sicher, dass Sie das Projekt erstellt haben (siehe Abschnitt „Erstellen“ weiter unten). Fügen Sie anschließend Folgendes zu Ihrer claude_desktop_config.json hinzu:

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

Codeium

Fügen Sie Ihrer Codeium MCP-Konfigurationsdatei die folgende Konfiguration hinzu (normalerweise unter ~/.codeium/windsurf/mcp_config.json auf Unix-basierten Systemen oder %USERPROFILE%\.codeium\windsurf\mcp_config.json unter Windows):

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

Windsurf

Windsurf verwendet dasselbe Konfigurationsformat wie Codeium. Fügen Sie den Server Ihrer Windsurf MCP-Konfiguration hinzu, wie oben für Codeium gezeigt.

Related MCP server: GitHub MCP Server

Bauen

Unix/Linux/macOS

Klonen Sie das Repository und erstellen Sie:

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

Windows

Verwenden Sie für Windows-Systeme den Windows-spezifischen Build-Befehl:

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

Alternativ können Sie die mitgelieferte Batchdatei verwenden:

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

Dadurch werden die erforderlichen Dateien im Verzeichnis dist erstellt, die Sie zum Ausführen des MCP-Servers benötigen.

Windows-spezifische Anweisungen

Voraussetzungen

  • Node.js (v14 oder höher)

  • npm (v6 oder höher)

Ausführen des Servers unter Windows

  1. Mithilfe der Batchdatei (einfachste Methode):

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

    Dadurch wird überprüft, ob der Build vorhanden ist, bei Bedarf erstellt und der Server gestartet.

  2. Direkte Verwendung von npm:

    npm run start

Festlegen des persönlichen GitHub-Zugriffstokens unter Windows

Für die volle Funktionalität und um eine Ratenbegrenzung zu vermeiden, müssen Sie Ihr persönliches GitHub-Zugriffstoken festlegen.

Optionen:

  1. Übergeben Sie es als Parameter an die Batchdatei:

    run-server.bat your_github_token_here

  2. Legen Sie es als Umgebungsvariable fest:

    set GITHUB_PERSONAL_ACCESS_TOKEN=your_github_token_here
npm run start

Beheben von Windows-Problemen

Wenn Probleme auftreten:

  1. Build-Fehler : Stellen Sie sicher, dass TypeScript korrekt installiert ist.

    npm install -g typescript

  2. Berechtigungsprobleme : Stellen Sie sicher, dass Sie die Befehle in einer Eingabeaufforderung mit entsprechenden Berechtigungen ausführen.

  3. Node.js-Fehler : Stellen Sie sicher, dass Sie eine kompatible Node.js-Version verwenden.

    node --version

Anwendungsbeispiele

Workflows in einem Repository auflisten:

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

Lösen Sie einen Workflow aus:

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

Fehlerbehebung

Häufige Probleme

  1. Authentifizierungsfehler :

    • Stellen Sie sicher, dass Ihr GitHub-Token über die richtigen Berechtigungen verfügt

    • Überprüfen Sie, ob das Token korrekt als Umgebungsvariable festgelegt ist

  2. Ratenbegrenzung :

    • Der Server implementiert eine Ratenbegrenzung, um das Erreichen der GitHub-API-Grenzen zu vermeiden

    • Wenn Sie auf Ratenbegrenzungsfehler stoßen, reduzieren Sie die Häufigkeit der Anfragen

  3. Typvalidierungsfehler :

    • GitHub-API-Antworten können manchmal von erwarteten Schemata abweichen

    • Der Server implementiert eine flexible Validierung, um die meisten Variationen zu verarbeiten

    • Wenn Sie auf anhaltende Fehler stoßen, öffnen Sie bitte ein Problem

Lizenz

Dieser MCP-Server ist unter der MIT-Lizenz lizenziert.

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