Building an MCP Server to Interact with Ansible Automation Platform

Introduction: Why Red Hat Is Betting on MCP for Automation

Enterprise automation is at an inflection point.

Infrastructure is automated, but decision-making is still manual. AI is powerful, but direct access to production systems is dangerous. Bridging this gap safely is the real challenge—and this is exactly where Model Context Protocol (MCP) enters the picture.

Red Hat has publicly demonstrated MCP servers running on Red Hat OpenShift, exposing Ansible Automation Platform (AAP) as structured, policy-controlled tools to AI assistants. This pattern is not theoretical—it is intentionally designed for regulated, enterprise-grade environments.

This article builds on those Red Hat MCP implementation references and explains:

• Why MCP is the correct abstraction layer for AAP

• How Red Hat’s architecture influences real-world MCP design

• How to implement an MCP server that is secure, cloud-native, and AI-ready

• Common mistakes enterprises make when copying demos into production

This is written for architects, platform engineers, and automation leads—not beginners.

MCP in the Red Hat Ecosystem: What It Actually Is (and Is Not)

MCP According to Red Hat’s Reference Implementations

In Red Hat demos and reference material, MCP is positioned as:

A tool exposure protocol that allows LLMs to safely interact with enterprise systems through structured contracts, running on OpenShift.

Key characteristics consistently shown in Red Hat examples:

• MCP server runs as a containerized service

• Deployed inside OpenShift

• Uses service accounts, not user tokens

• Exposes high-level tools, not raw APIs

• Acts as a policy enforcement point

MCP Is Not a “Chatbot Layer”

A frequent misunderstanding (even in enterprise teams):

❌ MCP = Chat UI
❌ MCP = AI plugin
❌ MCP = REST proxy

✅ MCP = Intent-to-action control plane

This distinction is critical when integrating with Ansible Automation Platform, which already has powerful—but dangerous—APIs.

Why Red Hat Does NOT Recommend Direct AI → AAP API Access

Red Hat’s MCP demos intentionally avoid exposing AAP APIs directly to AI models. This is not accidental.

Problems With Direct Access (Enterprise Reality)

In regulated environments (telecom, finance, government), this fails compliance reviews almost immediately.

Red Hat’s MCP Pattern for Ansible Automation Platform

Reference Architecture (Conceptual)

+--------------------------------+
| AI Client (IDE / Chat / Agent)  |
+---------------+----------------+
                         |
                         | MCP Protocol
                         |
+---------------v----------------+
| MCP Server (on OpenShift)      |
| - Tool schemas                         |
| - Policy enforcement                |
| - Validation & summarization  |
+---------------+----------------+
                         |
                         | REST (Controlled)
                         |
+---------------v----------------+
| Ansible Automation Platform  |
| - Job Templates                       |
| - Inventories                            |
| - Credentials                            |
+--------------------------------+

This architecture mirrors Red Hat’s public MCP demos:

• MCP server is stateless

• AAP remains the system of record

• OpenShift provides security, scaling, and isolation

Designing MCP Tools the “Red Hat Way”

Red Hat’s MCP examples consistently follow one principle:

Expose automation intent, not automation mechanics

Anti-Pattern (Seen in Failed POCs)

This leaks platform internals and forces the LLM to understand AAP.

Recommended Pattern (Aligned With Red Hat Demos)

• MCP maps this to a specific job template

• Inventory is resolved server-side

• Credentials are never exposed

Core MCP Tools for Ansible Automation Platform (Validated by Practice)

Based on Red Hat demos and real production usage, these tools deliver the highest value.

1. Automation Discovery Tool

Purpose: Help AI understand what automation exists

Returns:

• Name

• Purpose

• Risk classification (read-only / disruptive)

• Environment scope

This aligns with Red Hat’s push toward automation as a product, not scripts.

2. Guarded Job Execution Tool

Red Hat MCP demos always show explicit safeguards:

• Allowlisted job templates

• Environment checks

• Dry-run defaults

• Optional approval hooks

Example policy:

Production jobs require either a dry-run or explicit approval metadata.

3. Job Observation & Health Tool

AAP jobs can hang due to:

• Network reachability

• SSH stalls

• External dependencies

Your MCP server should:

• Poll job state

• Detect inactivity

• Summarize progress

This reflects Red Hat’s emphasis on operability, not just execution.

4. Result Interpretation Tool (Critical for AI)

Raw Ansible logs are not AI-friendly.

MCP should:

• Extract failures

• Group by root cause

• Produce structured summaries

Example:

Implementing the MCP Server (Aligned With Red Hat Practices)

Technology Choices

Red Hat examples consistently use:

This is intentional: boring technology scales best.

Simplified MCP Endpoint Example

Note:

• No AAP IDs exposed

• No inventory names leaked

• Policy enforced before execution

Authentication & RBAC 

Red Hat guidance strongly implies:

❌ Never use personal AAP tokens
❌ Never give MCP admin privileges

Correct Model

• Dedicated AAP service account

• Limited to:

  • Specific job templates

  • Read-only inventory

• Token stored in OpenShift Secret

• Rotated regularly

In audits, this separation is non-negotiable.

Deploying MCP on OpenShift 

OpenShift provides:

• Native TLS (Routes)

• Network policies

• Pod security

• Resource limits

• Auditability

Red Hat MCP demos consistently deploy MCP servers inside the cluster, not externally.

This ensures:

• Low latency

• No exposed control plane

• Strong isolation from users

Real Enterprise Use Case 

Scenario: AI-Assisted Change Readiness

1. Engineer asks:

   “Is it safe to upgrade routers in APAC tonight?”

2. AI:

   • Calls MCP discovery tool

   • Identifies precheck automation

3. MCP server:

   • Runs read-only job

   • Summarizes risks

4. AI responds:

   “4 devices fail reachability checks. Recommend excluding them before proceeding.”

No credentials.
No inventory names.
No unsafe actions.

This is exactly the workflow Red Hat is enabling.

Common Mistakes When Copying Red Hat MCP Demos

Mistake 1: Treating MCP as a Proxy

Red Hat demos are conceptual. Production needs:

• Policies

• Audits

• Rate limits

Mistake 2: One MCP Tool for Everything

Red Hat uses many small tools, not one generic one.

Mistake 3: Ignoring Human Operators

MCP should augment, not replace, existing AAP workflows.

MCP vs Other Integration Models (Enterprise Comparison)

Future Direction: Where Red Hat MCP Is Headed

Based on Red Hat’s trajectory:

• MCP becomes a standard control plane for AI actions

• OpenShift becomes the AI tool runtime

• AAP becomes the execution backend

• Human approval loops integrate with MCP, not UI clicks

This aligns with Red Hat’s long-term hybrid cloud + AI platform strategy.

Mini FAQ

Is MCP officially supported by Red Hat today?
MCP is emerging, but Red Hat is actively shaping its enterprise adoption through OpenShift-based reference implementations.

Can MCP replace Ansible Automation Platform?
No. MCP orchestrates intent. AAP executes automation.

Is this safe for production?
Yes—if you follow Red Hat’s principles: isolation, RBAC, policy, and auditability.

Conclusion: MCP Is the Missing Control Plane for AI + Automation

Red Hat’s MCP implementations are not about flashy demos. They represent a fundamental architectural shift:

• From scripts → products

• From APIs → intent

• From human-only → human + AI collaboration

By placing an MCP server between AI systems and Ansible Automation Platform—running securely on OpenShift—you get automation that is powerful, explainable, and governable.

That is not just good engineering.
That is how automation survives enterprise reality.