RFC: Introduce MCP Server for PipeCD

[gunta]

Summary

This proposal introduces a new plugin or component to run an MCP (Model Context Protocol) Server within PipeCD to enable LLM-driven integrations and workflows. The MCP Server would allow external clients (e.g., Cursor MCP Client tools, or other MCP-based applications) to discover, monitor, and trigger PipeCD deployments, thus providing a standardized way to integrate advanced AI workflows, prompt-driven automation, and other context-dependent tasks.

Motivation

PipeCD provides a GitOps-style continuous delivery solution for multiple platforms (Kubernetes, Terraform, Cloud Run, AWS Lambda, AWS ECS, etc.). Meanwhile, MCP (https://modelcontextprotocol.io/introduction) offers a standardized way for AI models to interact with data sources, orchestration layers, and external tools. By bridging these two technologies—PipeCD's robust CD capabilities and MCP's standardized AI integration model—we aim to:

1. Allow LLM-driven operational tasks to trigger and monitor deployments within PipeCD.
2. Provide a unified interface for AI-based automation across multiple enterprise services and clouds.
3. Avoid vendor lock-in by ensuring that any AI model with an MCP client can interact with PipeCD in the same way.
4. Simplify the complexities of multi-platform CD by letting LLM agents handle context, logs analysis, and deployment validations through standardized requests to the MCP Server.

Detailed Design

High-Level Architecture

1. MCP Server Plugin/Component

   • A new PipeCD service that implements the MCP Specification, listening on the standard MCP transport (e.g., gRPC or HTTP endpoints).
   • The server orchestrates requests from LLM-based clients (or any MCP client) and translates them into PipeCD API calls.

2. MCP Resource Adapters

   • For each resource type in PipeCD (e.g., deployments, applications, control plane states, environment statuses), the MCP server would implement the Resource interface (as per the MCP specs).
   • This means an AI-driven agent can list and read available resources (like current deployments or pipeline definitions) in PipeCD, as well as create new deployment triggers.

3. Integration with PipeCD Control Plane

   • The MCP server calls existing PipeCD gRPC or REST APIs (similar to how "piped" interacts with the control plane) to manipulate deployments.
   • Authentication to the Control Plane would reuse existing Piped keys or a new dedicated service account mechanism to isolate the MCP server's permissions.

4. Prompt and Action Handling

   • The MCC (Model Context Client) can send a prompt requesting an action like "deploy application X to production using pipeline Y."
   • The MCP server interprets that request, checks resource definitions for that application, then calls PipeCD's deployment API to start the process.
   • The server would keep track of the deployment logs and statuses, and feed relevant updates back to the LLM client in a standardized way.

5. Security / Access Control

   • The MCP server can be secured using standard authentication (mTLS, OAuth, or tokens) as recommended by the MCP spec. Only authorized clients would be able to read or manipulate deployments.
   • Fine-grained ACL can be implemented by restricting which operations are available to the user's access token.

Example Sequence Diagram

Below is a simplified example showing an LLM-based ChatOps agent requesting a new deployment through MCP:

1. LLM-based ChatOps agent → "MCP Client" → (Prompt) "Deploy service-a to staging environment."
2. MCP Client → "MCP Server for PipeCD" → (POST /resources/deployments, JSON body with deployment details)
3. MCP Server → PipeCD Control Plane → (Trigger new deployment using existing gRPC calls)
4. PipeCD → "MCP Server" → (Deployment status events)
5. "MCP Server" → "MCP Client" → Returns real-time updates with logs or success/failure status.
6. LLM-based ChatOps agent surfaces the result to the user.

Potential APIs

Below is a sample of how we might define the endpoints (assuming a JSON-based HTTP for brevity, though actual protocol might be gRPC):

1. GET /mcp/resources/applications
   • Lists all known PipeCD applications.
2. GET /mcp/resources/deployments
   • Lists ongoing deployments, plus metadata (state, logs, pipeline steps).
3. POST /mcp/resources/deployments
   • Initiates a new deployment with JSON body specifying application, pipeline, etc.
4. GET /mcp/resources/deployments/{deployment_id}
   • Retrieves deployment details and logs.

Cursor MCP Client Usage Example

Below is a snippet of how a Cursor client could specify a prompt:

User -> LLM:
"Deploy Application X to Production with monitoring enabled."

LLM -> MCP:
{
  "type": "CreateResourceRequest",
  "resourceType": "Deployment",
  "payload": {
    "application": "service-x",
    "pipeline": "production-bluegreen",
    "analysis": "metrics"
  }
}

MCP -> PipeCD:
Triggers the deployment, returns status updates, logs, etc.

From the LLM user perspective, the entire flow can be interactive, with the LLM prompting for additional context if needed (e.g., retrieving environment variables, verifying config versions, etc.).

Alternatives

1. Directly integrating LLM-based logic into PipeCD's web UI or CLI
   • This approach would tightly couple AI logic to the PipeCD codebase, making it less flexible to changes in LLM providers and losing the standardized interface that MCP provides.
2. Using existing ChatOps integrations (e.g., Slack bots or GitHub Actions)
   • These do not provide a single standard for how AI models interact with the data or the environment, lacking the uniform approach that MCP offers.
3. Not implementing MCP integration at all
   • AI-driven automation would remain ad-hoc, with each user implementing custom logic instead of a standard approach.

Unresolved Questions

1. How to handle advanced concurrency scenarios? For instance, if multiple LLM/agents simultaneously attempt to deploy conflicting versions.
2. Are there performance concerns with scaling the MCP server when hundreds of deployments are triggered concurrently by multiple clients?
3. Should logs be streamed as a resource or stored in a filestore and fetched only on-demand?
4. What level of detail (metrics, logs, pipeline steps) do we expose by default vs. behind a configuration toggle?

---

References

• Model Context Protocol Introduction

Author(s): Günther Brunner
Status: Draft

[Warashi]

Hello, thanks for your proposal.
I created an MCP server for PipeCD to learn how it works.
If you are interested in this, please try it.

The implementation is found here.
https://github.com/Warashi/mcp-server-pipecd