CloudBees Unify MCP Server – AI DevOps Context

CloudBees Unify MCP Server enables MCP-compatible AI clients to interact with CloudBees Unify using CloudBees-supported tools and toolsets. It is intended for agentic DevOps workflows where assistants need controlled access to software delivery context, CI information, workflows, users, organizations, reporting, feature flags, actions, and security findings.

#devops#ci-cd#security-findings

Overview

CloudBees Unify MCP Server is CloudBees' Model Context Protocol server for
connecting AI clients to CloudBees Unify. It gives an assistant a governed
interface into software delivery data and actions instead of requiring the
assistant developer to build direct integrations against each CloudBees Unify
API. The server is organized around toolsets so administrators and users can
control which groups of tools are available to an agent.

What the MCP server enables

CloudBees documents toolsets for users, organizations, components, CI,
workflows, actions, feature flags, security, and reporting. Toolsets can be
disabled, read-only, or read-write, which allows an installation to expose
only the capabilities needed for a particular AI workflow. In practice, an
agent can use the server to retrieve delivery context, inspect CI-related
information, review workflow and component data, and work with security
findings or issue-tracking context when the corresponding toolsets are
enabled.

When to use it

Use this MCP server when an AI assistant needs CloudBees Unify context for
DevOps, platform engineering, or release management tasks. Typical examples
include summarizing pipeline or component state, reviewing delivery data
before a release decision, investigating workflow context, or helping teams
triage security findings using the information already available in
CloudBees Unify. It is also useful when teams want to limit an assistant to
read-only data access for analysis, or explicitly enable read-write toolsets
for carefully governed automation.

Connection and authentication

CloudBees documents a local stdio configuration using the
cloudbees-unify-mcp-server executable or the cloudbees/unify-mcp-server
Docker image. The stdio command requires CloudBees Unify mode and an
organization ID. The Docker-based configuration passes
CLOUDBEES_PERSONAL_ACCESS_TOKEN to the container. CloudBees documentation
also states that the local stdio transport is being deprecated as of May 31,
2026 and directs users to migrate to the remote CloudBees-hosted MCP server,
which uses OAuth-based authentication.

Key considerations

Toolsets are the primary control surface. Avoid enabling read-write access
unless the agent workflow genuinely requires it, and prefer read-only
toolsets for reporting, investigation, and summarization. Personal access
tokens and organization IDs should be treated as sensitive configuration.
Because the local stdio option is deprecated, new deployments should review
CloudBees' migration guidance and use the CloudBees-hosted OAuth server when
that option is available to the organization.

Frequently Asked Questions

When should an AI agent use the CloudBees Unify MCP Server?

Use it when an agent needs controlled access to CloudBees Unify context for DevOps workflows such as CI investigation, component review, workflow analysis, reporting, release preparation, or security finding triage.

What does CloudBees Unify MCP add to an AI agent's capabilities?

It exposes CloudBees Unify capabilities through MCP toolsets so the agent can work with live delivery context instead of relying on static model knowledge or custom one-off API integrations.

What can the AI agent access or manage through this server?

CloudBees documents toolsets for users, organizations, components, CI, workflows, actions, feature flags, security, and reporting. Each toolset can be disabled, read-only, or read-write, so actual access depends on the configured toolset states and user permissions.

How is authentication configured for this MCP server?

The local stdio setup uses CloudBees Unify configuration including an organization ID and, for Docker-based usage, the CLOUDBEES_PERSONAL_ACCESS_TOKEN environment variable. CloudBees also documents migration to a hosted remote server that uses OAuth-based authentication.

Which transport should be used for this MCP server?

The YAML includes the documented local stdio command because it has a verified startup configuration. CloudBees states that local stdio is deprecated as of May 31, 2026, so new deployments should prefer the CloudBees-hosted OAuth MCP server where available and follow CloudBees' migration guidance.