Skip to main content
In this lesson you’ll learn how to use an MCP server as a bridge to trigger a CI/CD workflow (GitHub Actions) from an LLM-enabled client. We’ll:
  • Run a local Vite dev server that hosts the Turbo Broccoli site.
  • Install and run an MCP server that calls the GitHub Actions API.
  • Configure authentication (GitHub Personal Access Token).
  • Add the MCP server to your host/Claude configuration.
  • Trigger a workflow and inspect the result in GitHub Actions.
A presentation slide that reads "Trigger a CI/CD Workflow via MCP" with a large "Demo" label on a dark curved shape. A small "© Copyright KodeKloud" appears in the lower-left.
Overview:
  • The MCP server acts as a bridge to a CI/CD platform (GitHub Actions in this example).
  • The client (an LLM client such as Claude) runs inside your AI-enabled app/IDE and calls the MCP server for Actions operations.
  • The host application is the UI you interact with (for example, the Claude desktop app).

​
1) Run the Vite site locally

Start the local dev server in your Turbo Broccoli project directory: 
jeremy@MACSTUDIO turbo-broccoli % npm run dev
You should see output similar to: 
> vue-splash@0.0.0 dev
> vite

12:25:32 AM [vite] (client) Re-optimizing dependencies because vite config has changed
VITE v7.0.5 ready in 299 ms
→  Local:   http://localhost:5173/
→  Network: use --host to expose
press h + enter to show help
This serves the site at http://localhost:5173/ so you can validate changes before or after triggering CI/CD. (See Vite docs: https://vitejs.dev/)

​
2) GitHub Actions workflow (what we will trigger)

The repo uses an Azure Static Web Apps CI/CD workflow implemented with GitHub Actions. The workflow runs on pushes to main, PR updates, or manual dispatch. Example workflow header and a build job: 
name: Azure Static Web Apps CI/CD

on:
  push:
    branches:
      - main
  pull_request:
    types: [opened, synchronize, reopened, closed]
    branches:
      - main

jobs:
  build_and_deploy_job:
    if: github.event_name == 'push' || (github.event_name == 'pull_request' && github.event.action != 'closed')
    runs-on: ubuntu-latest
    name: Build and Deploy Job
    permissions:
      id-token: write
      contents: read
    steps:
      - uses: actions/checkout@v3
        with:
          # additional configuration here
Quick reference — common workflow trigger types:
Trigger typeWhen it runsTypical use
push to branchOn commit pushAuto-build & deploy on main branch
pull_requestOn PR open/updateValidate changes via CI
workflow_dispatchManual dispatch or APIManual redeploys or ad-hoc runs
Note: A workflow_dispatch can accept inputs which you may pass via the MCP server when triggering.

​
3) Install the GitHub Actions trigger MCP server

Install (or run via npx) the MCP package that exposes GitHub Actions operations: 
# Global install (may require sudo)
sudo npm install -g @nextdrive/github-action-trigger-mcp

# Or run it via npx (no global install required)
npx -y @nextdrive/github-action-trigger-mcp
Package: https://www.npmjs.com/package/@nextdrive/github-action-trigger-mcp

​
4) Configure authentication (GitHub Personal Access Token)

The MCP server needs a GitHub Personal Access Token (PAT) with the correct permissions to trigger workflows. Export the token into your environment before starting the MCP server or include it in your host configuration: 
export GITHUB_PERSONAL_ACCESS_TOKEN="ghp_XXXXXXXXXXXXXXXXXXXXXXXXXXXX"
Recommended scopes/permissions:
Token typeRequired scopes / permissions
Classic PATrepo (private repos) or public_repo (public) and workflow
Fine‑grained PATActions (Read & Write) or equivalent for workflows
AlternativeUse GitHub Apps or OIDC where possible to avoid long‑lived tokens
Store and manage PATs securely. Do not commit tokens to source control. Use secrets managers or environment variables with least privilege and proper access controls.
For more on PATs and security: https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token

​
5) Add the MCP server to your Claude/host configuration

Add an MCP server entry so your host can start and connect to it. Example mcpServers JSON snippet for the host configuration: 
{
  "mcpServers": {
    "google-calendar": {
      "command": "npx",
      "args": ["@cocal/google-calendar-mcp"],
      "env": {
        "GOOGLE_OAUTH_CREDENTIALS": "/Users/jeremy/demos/mcpstuff/google-calendar-mcp/credentials.json"
      }
    },
    "github-action-trigger-mcp": {
      "command": "npx",
      "args": ["-y", "@nextdrive/github-action-trigger-mcp"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": ""
      }
    }
  }
}
Fill GITHUB_PERSONAL_ACCESS_TOKEN with your token or ensure the environment variable is set for the running process. See your host/Claude docs for exact config file location and syntax.

​
6) Start the MCP server and authorize the client

  • Start the host/Claude application (or the MCP directly via npx) and ensure github-action-trigger-mcp appears in the tools/services list.
  • When the LLM client requests the tool, grant access (for example, “Allow always”) so the client can call the MCP.
  • When asked for repository context, provide the owner and repo (for example: jeremymorgan/turbo-broccoli).
The MCP will query GitHub for available workflows and present them to the client.

​
7) Trigger a workflow via the MCP server

To trigger a workflow manually, provide the payload that includes the repository, workflow identifier, and the ref (branch or SHA). Example request payload: 
{
  "owner": "jeremymorgan",
  "repo": "turbo-broccoli",
  "workflow_id": "azure-static-web-apps-black-rock-02284341e.yml",
  "ref": "main"
}
Notes:
  • workflow_id may be the workflow file name, the numeric workflow id, or the workflow name depending on the API/MCP implementation.
  • Many implementations accept optional inputs for workflow_dispatch inputs.
Example success response: 
{
  "success": true,
  "message": "Workflow triggered successfully",
  "run_id": 123456789,
  "triggered_by": "jeremymorgan"
}
After triggering, open the GitHub Actions UI to view the run, logs, and deployment progress. In this demo the run redeploys the site to Azure Static Web Apps.

​
8) Next steps and possibilities

  • Extend this pattern to trigger different workflows, pass inputs, or orchestrate multiple workflows across repositories.
  • Use other MCP servers that expose Git commands, cloud provider APIs, or infra actions to build more sophisticated LLM-driven automation.
  • Always evaluate security: prefer short‑lived credentials (OIDC, GitHub Apps) and minimize granted scopes.
This lesson demonstrated wiring an MCP server to GitHub Actions, configuring authentication with a PAT, adding the MCP to your host/Claude setup, and triggering a workflow. The pattern generalizes to other CI/CD platforms and MCP implementations.

Watch Video