Skip to main content
Glama
ajaychinthapalli

Jenkins to GitHub Actions MCP Server

by ajaychinthapalli
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Jenkins to GitHub Actions MCP Server

An MCP (Model Context Protocol) Server that converts Jenkinsfiles to GitHub Actions workflows. This tool helps you migrate your CI/CD pipelines from Jenkins to GitHub Actions by automatically converting declarative Jenkins pipelines into equivalent GitHub Actions workflow YAML files.

Quick Start

# Install dependencies
npm install

# Build the project
npm run build

# Run tests
npm test

# Start the MCP server
npm start

# Try the examples
node examples/test-converter.js
node examples/test-mcp-tools.js

Related MCP server: GitHub Actions MCP

Features

  • 🔄 Convert Jenkins declarative pipelines to GitHub Actions workflows

  • 📊 Analyze Jenkinsfile structure and extract pipeline information

  • 🔍 Support for common Jenkins pipeline constructs:

    • Stages and steps

    • Environment variables

    • Shell commands (sh)

    • Echo commands

    • SCM checkout

  • ⚡ MCP protocol integration for seamless AI assistant interaction

  • 🛠️ Both JSON and YAML output formats

Installation

npm install
npm run build

Usage

As an MCP Server

The server can be integrated with MCP-compatible clients (like Claude Desktop):

npm start

Configuration for Claude Desktop

Add to your Claude Desktop configuration:

{
  "mcpServers": {
    "jenkins-to-github-actions": {
      "command": "node",
      "args": ["/path/to/jenkins-to-github-actions-mcp-server/dist/index.js"]
    }
  }
}

Available Tools

1. convert_jenkinsfile

Convert a Jenkinsfile to GitHub Actions workflow.

Parameters:

  • jenkinsfile (string, required): The content of the Jenkinsfile to convert

  • format (string, optional): Output format - "yaml" or "json" (default: "yaml")

Example:

{
  "jenkinsfile": "pipeline { agent any stages { stage('Build') { steps { sh 'npm install' } } } }",
  "format": "yaml"
}

2. analyze_jenkinsfile

Analyze a Jenkinsfile and provide information about its structure.

Parameters:

  • jenkinsfile (string, required): The content of the Jenkinsfile to analyze

Example:

{
  "jenkinsfile": "pipeline { agent any stages { stage('Build') { steps { sh 'npm install' } } } }"
}

Example Conversion

Input (Jenkinsfile):

pipeline {
  agent any
  
  environment {
    NODE_ENV = 'production'
    VERSION = '1.0.0'
  }
  
  stages {
    stage('Build') {
      steps {
        sh 'npm install'
        sh 'npm run build'
      }
    }
    
    stage('Test') {
      steps {
        sh 'npm test'
      }
    }
    
    stage('Deploy') {
      steps {
        echo 'Deploying application'
        sh 'npm run deploy'
      }
    }
  }
}

Output (GitHub Actions):

name: CI
on:
  push:
    branches:
      - main
      - master
  pull_request:
    branches:
      - main
      - master
jobs:
  build:
    runs-on: ubuntu-latest
    env:
      NODE_ENV: production
      VERSION: 1.0.0
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
      - name: Build
        run: npm install
      - name: Build
        run: npm run build
      - name: Test
        run: npm test
      - name: Deploy
        run: echo "Deploying application"
      - name: Deploy
        run: npm run deploy

Development

Build

npm run build

Watch Mode

npm run watch

Run Tests

npm test

Test Examples

Try the interactive examples to see the converter in action:

# Test the converter with the sample Jenkinsfile
node examples/test-converter.js

# Run the interactive MCP tools test suite
node examples/test-mcp-tools.js

Lint

npm run lint

Supported Jenkins Pipeline Features

  • ✅ Declarative pipeline syntax

  • ✅ Agent configuration

  • ✅ Environment variables

  • ✅ Multiple stages

  • ✅ Shell commands (sh)

  • ✅ Echo commands

  • ✅ SCM checkout

  • ⚠️ Scripted pipelines (limited support)

  • ❌ Complex Groovy scripting

  • ❌ Jenkins-specific plugins

Limitations

  • This tool focuses on declarative Jenkins pipelines

  • Complex Groovy scripting and Jenkins-specific plugins may not be fully supported

  • Some Jenkins-specific features may require manual adjustment in the output

  • The converter makes best-effort conversions and may include warnings for constructs that don't have direct GitHub Actions equivalents

Contributing

Contributions are welcome! Please feel free to submit a Pull Request.

License

MIT

Available Tools

2 tools
analyze_jenkinsfileA

Analyze a Jenkinsfile and provide information about its structure, including stages, steps, environment variables, and agent configuration.

ParametersJSON Schema
NameRequiredDescriptionDefault
jenkinsfileYesThe content of the Jenkinsfile to analyze

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It clearly states the tool provides structural information, implying a read-only operation, but it does not disclose error behavior, validation requirements, or any potential side effects. The description adds some context by listing output categories but lacks deep behavioral detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler or redundancy. It efficiently conveys the tool's purpose and output scope, earning a high score for conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter analysis tool without an output schema, the description lists the key output categories (stages, steps, environment variables, agent configuration) and the input. It lacks explicit detail on return format or edge cases, but is largely complete for its simple scope, making it more than minimally viable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already fully describes the single parameter 'jenkinsfile' with 100% coverage, including its type and description. The tool description does not add extra parameter details beyond what the schema provides, so a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Analyze' with resource 'Jenkinsfile' and lists the output components (stages, steps, environment variables, agent configuration). It clearly distinguishes itself from the sibling tool 'convert_jenkinsfile' by focusing on structural analysis rather than transformation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when an agent needs to inspect a Jenkinsfile's structure, but it does not explicitly mention when to use this tool instead of 'convert_jenkinsfile' or provide any exclusions. It lacks explicit alternative guidance, so the usage context is clear only through implication.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

convert_jenkinsfileA

Convert a Jenkinsfile (declarative pipeline syntax) to a GitHub Actions workflow YAML. Takes a Jenkinsfile content as input and returns the equivalent GitHub Actions workflow.

ParametersJSON Schema
NameRequiredDescriptionDefault
formatNoOutput format (yaml or json). Default is yaml.yaml
jenkinsfileYesThe content of the Jenkinsfile to convert

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses the input type (Jenkinsfile content) and output type (equivalent workflow), and scopes to declarative pipeline syntax. However, it does not disclose limitations such as unsupported constructs, error handling, or whether the conversion is lossy, which are important for a conversion tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no redundancy. It front-loads the primary purpose and adds the input/output relationship in the second sentence, making it concise and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with two well-documented parameters and no output schema, the description is complete: it states the input, output, and scope. The schema covers parameter details, and the return value is clearly described as the equivalent workflow. No significant information is missing for invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description does not add meaning beyond the schema; the 'format' parameter's purpose is only implied by the default output being YAML, but the schema already documents it. No additional parameter guidance is provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Convert') and clearly identifies the resource (Jenkinsfile declarative pipeline syntax) and target (GitHub Actions workflow YAML). It differentiates from the sibling tool 'analyze_jenkinsfile' by focusing on transformation rather than analysis.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context: use this tool when you have a Jenkinsfile and want a GitHub Actions workflow. It does not explicitly mention alternatives or exclusions, but the purpose is unambiguous and distinct from the sibling, so no exclusions are needed.

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. 2 tool updatesv1.0.0
    • First observedanalyze_jenkinsfile
    • First observedconvert_jenkinsfile
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

A4/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: one converts Jenkinsfiles to GitHub Actions workflows, the other analyzes their structure. There is no overlap or ambiguity between them.

Naming Consistency5/5

Both tools follow the same verb_noun pattern (convert_jenkinsfile, analyze_jenkinsfile), making the naming predictable and consistent.

Tool Count3/5

With only 2 tools, the server feels thin, but the narrow scope of Jenkins-to-GitHub-Actions conversion justifies a small toolset. It is borderline acceptable but not robust.

Completeness4/5

The core operations of analyzing and converting are covered, which addresses the server's primary purpose. Minor gaps exist, such as lack of validation or batch processing, but these are not critical.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Jenkins MCP Server

    Anil-appari007
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables AI assistants to interact with Jenkins CI/CD systems through natural language, providing build management, job monitoring, log analysis, and debugging capabilities.
    MIT

  • GitHub Actions MCP

    ArkTechNWA
    A
    license
    A
    quality
    Not graded
    maintenance
    Connects AI assistants to GitHub Actions workflows to monitor CI/CD pipelines, view run logs, diagnose failures, and optionally trigger or manage workflows with granular permission controls.
    10
    1
    -

  • github-actions-mcp

    lailo
    A
    license
    Not graded
    quality
    D
    maintenance
    Analyzes GitHub Actions workflows and performance, helping identify bottlenecks, failures, and optimization opportunities in CI/CD pipelines.
    18 npm
    MIT