How to Build a DevOps Agent

Turn your AI coding assistant into a DevOps specialist that sees across Jenkins, GitHub Actions, and CloudBees Workflows.

What if you could ask your IDE "what's happening across all my pipelines?" and get a unified answer in seconds?

That's what the DevOps Agent Kit does. It's an open-source project that turns Claude Code or Cursor into a DevOps-specialized agent using MCP (Model Context Protocol). No application code. Just configuration files that teach the AI how to pull data from your CI/CD tools and take action.

In this guide, I'll walk you through setting it up and show you what it can do.

The DevOps Agent connects to three tools via MCP servers, plus GitHub via its native CLI:

This is a realistic setup — you use MCP servers where they exist and fall back to CLI tools where they don't. The agent handles both seamlessly.

Once connected, you get 7 slash commands:

Before you start, you'll need:

• Docker (for the CloudBees Unify MCP server)

• Node.js v18+ (for the Slack MCP server via npx)

• uv (for the Jira MCP server via uvx)

• Claude Code or Cursor

• A CloudBees Unify account (sign up free — GitHub or Google login, no credit card)

• GitHub CLI (gh) authenticated (for GitHub operations)

• Credentials for Jira and Slack (optional but recommended)

git clone https://github.com/cloudbees-oss/devops-agent-kit.git
cd devops-agent-kit

The repo structure is simple:

devops-agent-kit/
  CLAUDE.md                          # Agent persona (the brain)
  .claude/
    settings.json                    # MCP server connections
    skills/                          # 7 slash commands
      pipeline-overview/SKILL.md
      triage/SKILL.md
      security-scan/SKILL.md
      release-status/SKILL.md
      flag-rollout/SKILL.md
      ci-health/SKILL.md
      file-ticket/SKILL.md
  .cursor/
    mcp.json                         # Same MCP servers for Cursor
    rules/                           # Agent behavior rules for Cursor
  demo/
    setup.sh                         # Environment validator
    env.template                     # Token template

No application code. The "engineering" is the CLAUDE.md persona and the skill definitions. The MCP servers are all open-source or vendor-provided packages.

Copy the environment template:

cp demo/env.template .env

Open .env and fill in your credentials:

CloudBees Unify (required)

This is the core connection — all seven skills depend on it.

1. Log into your CloudBees Unify instance (e.g., https://your-org.cloudbees.io)

2. Click your avatar (top right) > User Settings > API Tokens

3. Click Generate Token, give it a name like "devops-agent-kit", and copy the token

4. Click Admin Settings (top right) > Organizational Profile and copy the Organization ID (a UUID)

5. Pull the Docker image: docker pull cloudbees/unify-mcp-server:latest

Add your credentials to .env:

CLOUDBEES_API_TOKEN=cb_api_your_token_here
CLOUDBEES_ORG_ID=your-org-uuid-here

The CloudBees Unify MCP server runs as a Docker container (cloudbees/unify-mcp-server) and gives the agent access to 63 tools: CI runs, logs, components, security findings, analytics, workflows, feature flags, release orchestration, and controller health. This is the foundation of everything the agent does. (Full docs)

Verify it works: Launch the agent and say "who am I?" — it calls user_whoami and confirms the token is valid.

Slack (recommended)

The Slack MCP server lets the agent post triage summaries, security alerts, and release status updates to your team's channels. Here's the full setup:

Create a Slack App:

1. Go to api.slack.com/apps and click Create New App > From scratch

2. Name it (e.g., "DevOps Agent") and select your workspace

Configure permissions:

1. In your app settings, go to OAuth & Permissions

2. Under Bot Token Scopes, add these three scopes:

3. chat:write — lets the agent post messages

4. channels:read — lets the agent list channels

5. channels:history — lets the agent read messages for context (optional)

6. Click Install to Workspace and authorize the app

Grab your credentials:

1. On the OAuth & Permissions page, copy the Bot User OAuth Token (starts with xoxb-)

2. For the Team ID: open any channel in Slack (desktop or web app). Look at the URL — it follows the pattern https://app.slack.com/client/TXXXXXXXX/CXXXXXXXX. The first ID (starting with T) is your Team ID. You can also find it under workspace settings

Add both to your .env:

SLACK_BOT_TOKEN=xoxb-your-bot-token-here
SLACK_TEAM_ID=T0123456789

One more step — invite the bot: Go to any channel where you want the agent to post and type /invite @DevOps Agent (using whatever name you gave your app).

The Slack MCP server (@zencoderai/slack-mcp-server) lets the agent post summaries to channels. When the agent triages a build failure or completes a security scan, it can push a formatted summary directly to your team.

Verify it works: Ask the agent to post a test message to the channel.

Jira (optional — powers /file-ticket)

1. Generate an API token at id.atlassian.com/manage-profile/security/api-tokens

2. Note your Jira instance URL and the email you log in with

JIRA_URL=https://your-instance.atlassian.net
JIRA_USERNAME=your-email@example.com
JIRA_API_TOKEN=your-jira-api-token

The Jira MCP server (mcp-atlassian) lets the agent create and search issues. This powers the /file-ticket skill and the "take action" steps in every scenario.

GitHub (CLI, not MCP)

No MCP server needed. The agent uses the gh CLI directly for GitHub operations — checking PR status, viewing Actions runs, commenting on issues. Just make sure you're authenticated:

gh auth login

This is intentional. Not every tool has an MCP server, and that's fine. The agent uses MCP where servers exist (CloudBees, Jira, Slack) and falls back to CLI tools where they don't (GitHub). It's the same mix you'd use in practice.

bash demo/setup.sh

The script checks prerequisites (Docker, node, npx, uvx), validates all environment variables, and confirms GitHub auth. Green checks across the board means you're ready.

claude .

That's it. Claude Code loads the persona from CLAUDE.md, connects to the three MCP servers, and registers the 7 skills. You now have a working DevOps agent.

For Cursor users: cursor . works the same way using the .cursor/ configs.

Use Case 1: Unified Pipeline Overview

The question: "What's happening across all my pipelines?"

The agent calls CloudBees Unify to discover your components, pulls recent runs across GitHub Actions, CloudBees Workflows, and Jenkins, checks security findings, and checks feature flag state. It presents a unified dashboard:

This is the cross-tool picture no single vendor dashboard can give you. Three service components across three CI tools (GitHub Actions, CloudBees Workflows, Jenkins), with security findings and feature flag state included.

What makes it powerful: The agent spots patterns across components. In this case, GitHub Actions is healthy but CloudBees Workflows are failing on all three services — suggesting a common config issue, not three separate bugs. A human checking dashboards one at a time might miss the pattern.

Use Case 2: Build Failure Triage

The question: "Triage the web-portal failures."

The agent finds the latest failed run, pulls the logs, reads the workflow YAML, analyzes each step, and classifies the root cause. Here's what it found for the Meridian web-portal:

• Run: #189 (CloudBees Workflow, triggered by push to main)

• Root cause: The publish-test-results action requires a folder-name input, but the workflow provides path — a CONFIG error caught at validation before any steps execute

• Classification: CONFIG

• Fix: Change path: reports/junit.xml to folder-name: reports/ in ci.yaml

The five classification categories:

• CONFIG (workflow/pipeline configuration error)

• CODE (compilation or test failure)

• SECURITY (scan gate failure)

• ENVIRONMENT (infra/timeout/resource issue)

• KNOWN (matches a previous failure pattern)

The agent then offers to file a Jira ticket with the root cause (via Jira MCP), post a summary to Slack (via Slack MCP), or comment on the relevant GitHub PR (via gh CLI). All with confirmation prompts before taking any action.

Use Case 3: Security Posture

The question: "Give me the security posture across all our components."

The agent pulls findings by severity, checks scanner coverage, tracks SLA status, and lists every finding with file path and line number:

All 7 findings from Gitleaks (SAST), all UNREVIEWED, all with SLA tracking active. The agent ranks by priority, recommends credential rotation, and offers to file Jira tickets for each component.

This is DevSecOps made tangible. Security connected to CI, feature flags, and project management in one view.

Use Case 4: Release Readiness

The question: "Is the release candidate ready?"

The agent checks every component: CI status, security gates, feature flag states per environment (Production and Staging). It produces a go/no-go report:

Verdict: NOT READY

Blockers: 1. 7 HIGH security findings with active SLAs 2. All 3 CloudBees Workflows failing 3. 3 new feature flags (dark-mode, new-dashboard, beta-payments-v2) not yet configured for environments

The report includes a checklist of what must be done before release. When blockers are resolved, the agent can enable feature flags progressively (Staging first, then Production with an extra confirmation warning) and trigger release workflows, all from the IDE with confirmation guardrails.

Use Case 5: Live Feature Flag Rollout

The question: "Enable instant-transfers in production."

This is where it gets real. The Meridian payment app is running locally. The sidebar shows Dashboard and Send Payment — no instant transfer option. That feature is behind a flag in CloudBees Unify.

From the terminal, you ask the agent to enable instant-transfers in production. The agent warns: "This will affect production traffic. Confirm?" You confirm. Within 10 seconds — no page refresh, no deploy, no restart — the Instant Transfer nav item appears in the sidebar with a green NEW badge. The app's SDK polled CloudBees, picked up the flag change, and updated the UI live.

One command in Claude Code. One flag toggle in CloudBees Unify. The feature is in front of users.

That's progressive delivery from your terminal.

The kit uses four Claude Code extension mechanisms:

CLAUDE.md is the agent persona. It defines the agent's capabilities, MCP tool routing (which tool to call for which task), output formatting rules, and guardrails (always ask before taking action, skip code_scan workflows, handle 500 errors gracefully).

Skills (.claude/skills/*/SKILL.md) are slash commands. Each skill is a markdown file that describes a multi-step workflow. When you type /triage, Claude reads the skill definition and follows the workflow: find the component, pull runs, filter for failures, analyze jobs, classify the root cause, present the report.

MCP servers (.mcp.json) are the connections to external tools. Each server runs as a subprocess — CloudBees Unify via Docker, Jira via uvx, and Slack via npx. The CloudBees Unify server alone provides 63 tools. For GitHub, the agent uses the gh CLI directly — showing how MCP and traditional CLI tools work side by side.

Cursor rules (.cursor/rules/*.mdc) are the Cursor equivalent of CLAUDE.md and skills, formatted for Cursor's agent system.

The kit works against any CloudBees Unify environment. The demo uses a pre-configured org, but you can point it at your own:

1. Set CLOUDBEES_API_TOKEN and CLOUDBEES_ORG_ID to your values

2. Run claude .

3. Ask about your real pipelines

The agent adapts to whatever components, workflows, and findings exist in your org.

Tip: For read-only access to a production org, add --toolsets=all=r to the Docker args in .mcp.json. This exposes all tools but prevents write operations — no flag changes, no workflow triggers, no risk.

Every write action goes through a confirmation step. The agent won't create a ticket, post a message, or flip a flag without asking first.

• Reasoning before action. The agent explains what it found and what it recommends before offering to do anything.

• Confirmation for all write operations. Jira tickets, Slack posts, and flag changes all require explicit approval.

• Extra production warning. Changing a flag in production triggers a second confirmation: "This will affect production traffic."

• CI workflows are read-only by default. The agent will read and analyze workflow YAML but will not modify it unless you explicitly ask.

• Graceful API fallbacks. If a CloudBees Unify endpoint is unavailable (e.g., the logs API returns a 500), the agent tells you and continues the analysis using step names, statuses, and durations instead.

git clone https://github.com/cloudbees-oss/devops-agent-kit.git
cd devops-agent-kit
cp demo/env.template .env
# Fill in your tokens
bash demo/setup.sh
claude .

The agent is only as good as the data it can access. This one has access to 63 tools across your entire DevOps stack because it's built on CloudBees Unify.

Star the repo if you find it useful. File issues if you hit problems. PRs welcome.

Repo: github.com/cloudbees-oss/devops-agent-kit

The DevOps Agent Kit is a community project maintained by CloudBees DevRel. It is not a CloudBees product and is not covered by CloudBees support.