When should KentiCopilot use CI/CD files instead of the Management MCP server?

As KentiCopilot gains broader write access through the Management MCP server, teams can often reach the same desired state in two ways: modify CI/CD-tracked configuration and deploy it, or let an agent apply a direct change through Management MCP. Repository data may be authoritative but difficult for an agent to interpret, while MCP provides a structured, validated interface.

How are teams deciding which path to use? My instinct is that repeatable structural changes should normally begin in source control, pass review and testing, and flow through CI/CD. Direct MCP changes may fit exploratory setup, content operations, or tightly scoped maintenance—but only when the action is logged, attributable, validated, and reproducible.

What decision rules have worked in practice? In particular, how do you prevent configuration drift when an MCP action changes an environment directly, and should every successful direct action produce an export, change record, or pull request so CI/CD remains the source of truth?

Tags:
CI/CD KentiCopilot Deployments MCP

Answers

To response this discussion, you have to login first.