Note: This video and podcast was generated using AI, adapting the original content and technical insights created by the author of the blog post.

The answer is in Confluence. It has been there for eight months. The module even has a README. But the developer doesn’t know where to look, isn’t confident the page is current, and has three other things open in their IDE. The platform engineer answers – again – and both of them lose twenty minutes of context.

This isn’t a people problem. It’s an interface problem. Static documentation was never the right way to expose a dynamic platform to developers. The Model Context Protocol (MCP) offers a different model – and it changes not just how developers ask questions, but how they work across every stage of the SDLC.

What MCP Actually Is (In One Paragraph)

MCP is an open standard from Anthropic that lets an AI agent connect to external systems through structured, typed tool interfaces. An MCP server exposes tools – callable functions with defined input schemas – that the agent invokes at runtime, getting live structured data back. The agent doesn’t consult training data. It reads the actual state of your platform, right now. That’s the core difference: MCP is about context, not memory. It makes your systems directly legible to AI, rather than trying to teach an AI about your systems in advance.

The result – what we’re calling Infrastructure-as-Context – is a platform that developers can interact with conversationally, and that platform engineers can reason over programmatically, without maintaining a parallel documentation layer.

The Reference Platform

We validated this pattern through a proof-of-concept we’re calling PayFlow Pro – a backend microservice running on GCP, with three environment tiers (dev / staging / prod), GitOps delivery via Helm and Argo CD, and governance requirements that include mandatory change management through ServiceNow and work tracking through Jira.

The platform-facing component is a custom MCP server – the platform-orchestrator – that exposes three tools:

• get_platform_state – returns the live inventory of deployed environments, versions, database hosts, and compliance flags
• detect_drift – reads Helm values files from Git and compares them against the active deployment state, flagging mismatches with severity and remediation steps
• register_deployment – writes new deployment state after a provisioning workflow completes, keeping the inventory self-maintaining

Five MCP servers run together: the orchestrator for platform state, GitHub MCP for repository operations, Atlassian MCP for Jira and Confluence, ServiceNow MCP for change management, and Lucid MCP for architecture diagrams. Two agents – a Platform Agent for infrastructure provisioning and a Helm Provisioner Agent for Kubernetes delivery – orchestrate across all five within a single conversation.

That’s the platform. Now let’s walk through what it changes, stage by stage.

Stage 1 – Week 1: Scaffolding a New Service

Greenfield. A developer joins the team or starts a new feature service. Before MCP, their first week looks like a scavenger hunt: find the right Terraform module for the database, understand which Helm values file to start from, figure out the epic in Jira, learn the branching convention, discover that the staging environment needs a manager-approved ServiceNow change and prod needs full CAB review.

Most of this information exists somewhere. But knowing which Confluence page, which version is authoritative, and how it connects to the actual repository takes days that should be spent building product.

With MCP, this is a single conversation.

“Hey, starting a new service for the payments retry feature. I think it needs a GCP dev env and a Postgres DB like the other services – can you set that up and get me a Jira epic? Also need a Helm chart, not sure which template to base it on. Oh and a Lucid diagram would be good if you can pull that together.”

The agent reads the existing module structure through GitHub MCP, identifies the relevant Terraform modules (gcp-gke-cluster, gcp-cloud-sql), creates the Jira epic, files a Standard Change in ServiceNow (auto-approved for dev tier), creates a feature branch, scaffolds the Helm values file from the appropriate template, opens a PR, and registers the new environment in the platform state. It then calls Lucid MCP to create or update an architecture diagram – generating a visual representation of the new service’s infrastructure, dependencies, and data flows directly in the team’s shared Lucid workspace.

The developer didn’t read a single Confluence page to make this happen. The institutional knowledge – which modules to use, what the naming convention is, whether dev needs a change request (it does, but it’s auto-approved), where the architecture diagram lives – is encoded in the agent’s governance rules, not in a document the developer might not find.

For brownfield teams, the pattern is the same but the first conversation is different:

“I’m trying to get payflow-pro running locally. The README mentions a .env file but I’m not sure where to get the values from. Also what’s the deal with the two Helm values files – which one do I actually use for local dev? Is there a Lucid diagram somewhere for this?”

The agent reads the actual README.md, the Helm values files, the Terraform module inputs, and the Jira epic that tracks the current sprint – and synthesizes an accurate picture of the service, as it exists today, not as it was documented six months ago. If a Lucid diagram exists for the service, the agent retrieves it directly through Lucid MCP, so the developer sees the current architecture alongside the code context – no hunting through shared drives.

What Doesn’t Work (Yet)

Context integrity is fragile. If any deployment happens outside the agent – a manual terraform apply, a direct Helm upgrade in the cluster – the orchestrator’s state goes stale. The agent’s next answer is wrong by definition. The fix is disciplined: make the agent the only authorized path for state changes. That’s an organizational commitment, not a technical one.

Tool schema quality is the hidden investment. Getting the tool descriptions right – precise enough that the model knows when to call detect_drift vs. get_platform_state – takes iteration. Budget time for it. Vague descriptions produce vague behavior.

Managers and architects will ask about AI hallucination. The answer is: MCP significantly reduces the surface area for hallucination by giving the model live structured data to reason from. But it doesn’t eliminate it. Good agent design includes validation at the MCP server level (required fields, type checking) and confirmation prompts for destructive actions. The agent is not magic – it’s a reasoning layer over your actual platform state.

Agent permissions are not self-enforcing at the infrastructure level. The governance rules encoded in the system prompt constrain what the agent proposes, not what it can technically execute. Three mitigations matter in practice:

• Scope MCP server credentials tightly. The platform-orchestrator should hold only the permissions it needs: read access to Git, write access to the deployment state store, and create-only access to ServiceNow change requests. It should not hold admin credentials to GCP or the Kubernetes cluster. Destructive operations (teardown, rollback) should require a separate, explicitly scoped credential with a human confirmation step.
• Build confirmation gates for write operations. Any MCP tool that creates, modifies, or deletes infrastructure state should return a structured confirmation payload that the agent presents to the developer before executing. The agent pattern here is: propose → confirm → execute → register. The confirm step is non-negotiable for prod-tier actions.
• Treat audit logs as a forensic primitive, not a courtesy. The register_deployment call and the Confluence audit entry aren’t just nice-to-haves – they’re the mechanism by which a team can reconstruct exactly what the agent did and when, if something goes wrong. Audit log entries should be write-once and tamper-evident. If your Confluence space allows page deletion, route audit entries to a more durable store (e.g., a locked S3 bucket or a SIEM).

Stage 2 – CI/CD Gates: The PR That Checks Itself

Pull requests are where platform knowledge collides with developer workflow most visibly. The right Terraform module was used – but with the right variables? The image tag was updated in values-staging.yaml – but does it match what the IDP expects? The PR has a Jira ticket in the description – but is it the right epic?

Without MCP, these checks are either manual (someone on the platform team reviews the PR) or absent (the problem surfaces in staging after a failed deployment).

With MCP, the agent performs a pre-flight check as part of the deployment conversation:

Listing 1: Deployment pre-flight check

1. [platform-orchestrator]  detect_drift - verify Git config matches live state
2. [GitHub MCP]             Read current values-staging.yaml for declared database host
3. [platform-orchestrator]  Compare declared vs. active: no drift detected
4. [Jira MCP]               Verify SCRUM-47 is open and linked to correct epic
5. [GitHub MCP]             Update values-staging.yaml: image.tag → 1.2.0
6. [GitHub MCP]             Open PR with SCRUM-47 in title and CHG reference in body
7. [platform-orchestrator]  register_deployment - log new staging state

The drift check runs before any change is proposed. This is worth emphasizing: the agent calls detect_drift not because a developer remembered to – because it’s a governance rule encoded in the agent’s system prompt:

Listing 2: Agent governance rules

ALWAYS call detect_drift before proposing deployments
ALWAYS register new infrastructure state via register_deployment
ALWAYS create audit log entry in Confluence

These aren’t checklist items. They’re runtime constraints. An agent that hasn’t called detect_drift won’t proceed to open a PR. This is structurally different from a governance process that depends on humans following steps correctly, every time.

Stage 3 – Sprint Planning: Platform Health as a Conversation

The 30 minutes before a release review tends to look the same everywhere: someone opens the Confluence page for the staging environment, confirms it hasn’t been updated in two weeks, opens a terminal, runs a few kubectl commands, cross-references against the Jira board, and pastes a summary into Slack. It’s not hard work. It’s just friction – repeated every sprint, by the same person, generating information that’s stale by the time the meeting starts.

The question “what’s actually running right now?” should take ten seconds, not thirty minutes. With MCP, it does:

“What’s the state of all PayFlow environments before the release review?”

The agent calls get_platform_state, reads the live inventory, cross-references against Git (Helm values, Terraform state), and returns a structured summary: which environments are active, what versions are deployed, which change requests are on record, and whether any drift exists between declared and actual configuration.

Listing 3: PayFlow environment inventory

{
  "inventory": {
    "gcp-dev":     { "version": "v1.1.0", "status": "active", "drift": false },
    "gcp-staging": { "version": "v1.0.9", "status": "active", "drift": true,
                     "drift_detail": "DATABASE_HOST mismatch - declared vs. active" },
    "gcp-prod":    { "version": "v1.0.8", "status": "active", "drift": false }
  }
}

That drift flag on GCP staging isn’t hypothetical – it’s the kind of issue that surfaces in production after a manual terraform apply that bypassed the agent workflow. The platform engineer now has it surfaced before the release review, not during an incident post-mortem.

This also matters for brownfield teams adopting the pattern incrementally. You don’t have to migrate everything at once. Start by querying existing state through MCP. Even if your deployments are still manual, having a queryable view of your platform’s current state is immediately useful – and it creates the foundation for progressively moving write operations through the agent.

💡 Adopting Incrementally? This section is for teams with existing infrastructure who are introducing MCP alongside a running platform – not as a greenfield replacement. The SDLC stages above apply in both contexts; this section covers the entry point that’s different.

Brownfield Reality: When the Docs Diverge from the Platform

The most common brownfield scenario isn’t a blank-slate migration. It’s an organization that has been running infrastructure for years, has accumulated Confluence pages at varying levels of accuracy, and is trying to figure out which of those pages to trust.

The MCP answer to this isn’t “migrate your docs.” It’s “stop using docs as the primary interface and let the agent read the platform directly.”

Consider this: a Confluence page says the staging database IP is 10.114.0.3. The actual Helm values file says 10.114.0.5. The live database is on 10.114.0.7. All three are wrong by different amounts. A developer reading Confluence will provision against the wrong address. An agent calling detect_drift will surface all three discrepancies immediately, with file-level specificity and remediation steps.

This is the brownfield unlock: you don’t need to fix your documentation to start using MCP effectively. You need clean IaC in Git (which most organizations already have) and a thin MCP server that exposes your platform’s live state. The agent reconciles the gap between declared and actual – and surfaces it to whoever needs to act on it.

“Something feels off with staging – the DB connection keeps failing intermittently. Can you check if what’s in Git actually matches what’s deployed?”

Listing 4: Drift detection result

[platform-orchestrator] detect_drift called
Result: DRIFT DETECTED
  - Parameter: DATABASE_HOST
  - Declared in charts/payflow-pro/values-gcp-staging.yaml: 10.114.0.5
  - Active in GCP staging: 10.114.0.7
  - Severity: High
  - Action: Reconcile - update DATABASE_HOST in Git or re-provision Cloud SQL instance
  - Created Confluence audit entry: DriftReport-2026-09-02-gcp-staging

The Confluence entry is created automatically – not because someone remembered to file it, but because the governance rule says to. This is where audit trails stop being a tax and start being a byproduct.

Greenfield teams build the MCP orchestrator alongside the platform. Every provisioning workflow goes through the agent from day one. Documentation becomes an output – the agent creates Confluence entries, Jira tickets, and audit logs as a byproduct of work. Developers never have to read a wiki to know how to provision an environment because the agent is the interface from the start.

Brownfield teams start with read-only queries. The agent reads existing Terraform modules and Helm values through GitHub MCP, answers questions about current state through the orchestrator, and surfaces drift without changing anything. This builds trust incrementally. As confidence grows, teams progressively route write operations – new environments, deployments, change requests – through the agent. The Confluence wiki doesn’t get deleted; it just stops being the primary interface.

Both paths lead to the same place: a platform where developers interact with intent, and the agent translates intent into correctly-governed action.

Stage 4 – Release Management: CHG Without the Spreadsheet

Change management fails in one of two ways. The first is that people skip it – the deployment goes out, the change request gets filed retroactively, and the audit record is technically compliant but substantively false. The second is that people do it correctly but slowly: finding the right ServiceNow template, classifying the change type, attaching the Jira ticket, getting the approval chain right – 45 minutes of process for a deployment that takes 5.

The agent doesn’t skip it and doesn’t slow it down. The change request is a side effect of starting a deployment conversation – created in the correct template, with the right Jira link, before the agent proposes a single infrastructure change.

“Deploy PayFlow v1.2.0 to prod.”

The agent knows – because it’s encoded in the governance rules – that production deployments require a CAB-approved change request. It won’t proceed without one. It creates the ServiceNow change request in the correct template for a production deployment, attaches the Jira ticket, notes the approval requirement, and waits. Once CAB approval is recorded, it proceeds with the deployment, creates the Confluence audit entry, and registers the new state.

The approval gates aren’t a feature of the agent. They’re a function of the governance rules – which means they apply consistently, even when the developer is in a hurry, even when the platform engineer isn’t watching, even at 11pm before a deadline.

The Shift That Matters

For engineering managers and architects, the framing question is usually: “What problem does this solve that my current tooling doesn’t?”

The answer is the interface. Your current tooling – Terraform, Helm, ServiceNow, Jira, Argo CD – is fine. MCP doesn’t replace any of it. What it replaces is the documentation-and-training layer that sits between your platform and the developers who use it.

That layer has always been expensive to maintain, inconsistent to apply, and slow to update. MCP makes it unnecessary – not because the platform became simpler, but because developers now have a way to interact with it directly, conversationally, with governance enforced structurally at every step.

The measure of success changes. It was coverage – how many procedures are documented, how many modules have READMEs. It becomes latency – how quickly a developer can go from intent to provisioned environment without escalating to the platform team.

In our testing across dev and staging environment provisioning runs on PayFlow Pro, median time from developer request to provisioned environment dropped from approximately 2–3 hours to under 15 minutes. The baseline includes the time a developer would typically spend locating the right Terraform module, understanding Helm values conventions, filing a ServiceNow change request, creating a Jira ticket, and opening a PR – all handled manually and without a guaranteed correct outcome. The 15 minutes reflects the agent completing all of those steps in a single conversation, with governance enforced at each step. That’s not a speed improvement. It’s a reduction in the number of handoffs.

The PayFlow Pro proof-of-concept referenced throughout – MCP Orchestrator, Terraform modules, Helm charts, agent definitions – is available as an open reference implementation.

References

Model Context Protocol

1. Anthropic. Model Context Protocol – Introduction.
2. Anthropic. Model Context Protocol Specification (Draft).
3. Anthropic. MCP Server SDK for Node.js.
4. Anthropic. Building MCP Servers – Quickstart Guide.
5. Lucid Software. Lucid MCP Server – Architecture Diagram Integration.

Internal Developer Platforms & Platform Engineering

6. Humanitec. What Is an Internal Developer Platform (IDP)?
7. CNCF TAG App Delivery. Platforms White Paper. Cloud Native Computing Foundation, 2022.
8. Skelton, M., Pais, M. Team Topologies. IT Revolution Press, 2019.
9. Hohpe, G. The Software Architect Elevator. O’Reilly Media, 2020.

GitOps & Infrastructure as Code

10. Weaveworks. Introduction to GitOps.
11. Argo CD Project. Argo CD – Declarative GitOps CD for Kubernetes. CNCF.
12. HashiCorp. Terraform Documentation – Module Development.
13. Helm Authors. Helm – The Kubernetes Package Manager.

AI Agents & Agentic Workflows

14. Weng, L. LLM-Powered Autonomous Agents. Lil’Log, June 2023.
15. OpenAI. Function Calling in the OpenAI API.
16. Anthropic. Claude’s Tool Use (Function Calling).

SDLC & Developer Experience

17. DORA. Accelerate State of DevOps Report 2023.
18. Forsgren, N., Humble, J., Kim, G. Accelerate: The Science of Lean Software and DevOps. IT Revolution Press, 2018.
19. Nygard, M. Release It! Design and Deploy Production-Ready Software, 2nd Ed. Pragmatic Bookshelf, 2018.

Configuration Drift & Observability

20. Puppet. State of DevOps Report 2023.
21. Driftctl Project. Infrastructure Drift Detection with Terraform.
22. HashiCorp. Terraform State Management.

Change Management & Governance

23. ITIL Foundation. ITIL 4 – Change Enablement Practice. Axelos, 2019.
24. PCI Security Standards Council. PCI-DSS v4.0.
25. Google Cloud. PCI DSS Compliance on Google Cloud.