Claude Code + Ansible Automation Platform: How I Manage AAP with MCP Server

Introduction

I design and deploy Ansible Automation Platform for customers, and the day-to-day routine for most teams hasn’t changed much over the years: log in to the UI, click through to job templates, check inventories, dig through job output when something fails. It works, but it’s a lot of clicking for things that are really just questions like “did that job run?” or “which hosts are unreachable right now?”

That’s starting to change with the Ansible MCP server, available as a Technology Preview from AAP 2.6 onward. Model Context Protocol (MCP) is an open standard that lets AI tools talk to external systems through a unified interface. It’s not tied to any single AI product: Red Hat built it to connect with whichever AI tool you already use, whether that’s Claude, Cursor, ChatGPT, or something else. I happen to use Claude Code, so that’s what this walkthrough covers, but the setup on the AAP side is the same regardless of which AI client you connect.

I’ve been setting this up for a few customer environments recently, and this post is my walkthrough of getting it running with Claude Code and what it’s actually useful for. I’m writing it the way I wish I’d found it: as someone seeing this for the first time, not as a reference manual.

It’s Not Just for Chat Tools Like Claude Code

Worth clearing up early: MCP isn’t a Claude thing, or even a “chat with an AI” thing. It’s an open protocol, so anything that speaks MCP as a client can connect to the AAP MCP server - that includes chat-based tools like Claude Code, Cursor, or ChatGPT, but it also includes autonomous agents, orchestration frameworks, and custom agentic pipelines that don’t have a chat interface at all. If you’re building your own agent for incident response, CI/CD automation, or a broader multi-tool workflow, it can talk to AAP through the same MCP server, using the same toolsets, without you writing a single line of API integration code.

Claude Code is just the client I use day to day, and it’s the one this walkthrough covers, but the AAP side of the setup doesn’t care what’s on the other end of the connection.

Why Bother With an MCP Server for AAP at All

A fair question, since AAP already has a full REST API. A few reasons this is worth the setup time:

It removes the integration work. Without MCP, connecting an AI agent to AAP means writing and maintaining custom API wrappers, handling auth, and translating natural language into API calls yourself. The MCP server already does that translation, exposed as a standard set of toolsets, so there’s no custom middleware to build or maintain.

It keeps permissions where they belong. Every action an AI tool or agent takes is still scoped to the RBAC permissions of the token it’s using. The AI doesn’t get its own identity or elevated access - it’s just acting on your behalf, within your existing access boundaries.

It turns AAP into something agents can actually operate, not just query. Because the toolsets cover job execution, inventory, monitoring, user management, credentials, and platform config, an agent isn’t limited to reading data. With write access enabled, it can trigger the same automation workflows a human operator would, which opens the door to AI-driven remediation, self-service automation, and agent-to-agent workflows where AAP is one node in a larger chain.

It’s tool-agnostic by design. Since it’s a standard protocol rather than a Claude-specific or vendor-specific integration, the same MCP server setup keeps working even if your team switches AI tools down the line, or runs several in parallel.

What Actually Happens When You Ask Claude Code Something

Before getting into setup, it helps to know what’s going on behind the scenes, because it’s a pretty short chain:

1. You type something in plain English into Claude Code, like “list all failed jobs.”
2. Claude Code figures out which MCP tool matches that request.
3. That request goes to the MCP server running on your AAP host, which checks it against your API token’s permissions.
4. The automation controller processes it and sends back the result.
5. Claude Code shows it to you in a readable format, not raw JSON.

What You Need Before Starting

Nothing exotic here, but worth confirming before you go further:

• Ansible Automation Platform 2.6 or later, containerized installation, already running
• Admin or sufficiently privileged RBAC access to the AAP web UI
• Claude Code CLI installed on your machine (or whichever AI tool you prefer - Cursor and ChatGPT work too)
• Network access from your machine to the AAP host on port 8448, which is where the MCP server listens
• A terminal - Linux, macOS, or WSL all work fine

If you don’t have Claude Code installed yet, the quickest path is the native installer:

curl -fsSL https://claude.ai/install.sh | bash

Deploying the MCP Server (Keeping This High Level)

I’m not going to turn this into a full AAP installer walkthrough since that deserves its own post, but here’s the gist of how the MCP server gets deployed on a containerized AAP setup:

You add an [ansiblemcp] group to your inventory file with the host that’ll run the MCP server, then set a couple of variables under [all:vars]: one to control whether the AI tool gets read-only or read-write access, and another if you need to bypass certificate validation for a self-signed cert. Run the install playbook, and the MCP server gets deployed as its own container alongside your existing AAP components, exposed over HTTPS on port 8448 by default.

If you’re on OpenShift instead of a standalone containerized install, the MCP server comes through the AAP Operator instead - you add the mcp component under the custom resource spec, and the operator handles the rest.

$ podman ps |grep mcp
bf966c3809d3  registry.redhat.io/ansible-automation-platform-27/mcp-server-rhel9:latest         /entrypoint.sh        4 days ago   Up 4 hours  8080/tcp, 8086/tcp  ansiblemcp

Either way, once deployed, your MCP server lives at a URL that looks like this:

https://<your-aap-host>:8448

For the actual installer steps and full list of variables, Red Hat’s own documentation covers that in detail, so I’d rather send you there than reproduce it badly here: Deploy Ansible MCP server on Ansible Automation Platform.

Verify the MCP Server Is Actually Running

Before touching any AI client configuration, it’s worth confirming the MCP server itself is up and reachable. A plain curl against the base URL is enough - you don’t need a full MCP client for this:

$ curl -k https://aapaio.lab.gineesh.com:8448
This is a MCP server, you can access it with a MCP client through the following end-points:
    - /mcp/job_management
    - /mcp/inventory_management
    - /mcp/system_monitoring
    - /mcp/user_management
    - /mcp/security_compliance
    - /mcp/platform_configuration
  or just /mcp if you want to get access to all the tools at the same time.

That /mcp endpoint at the end is worth noting - it gives you all six toolsets through a single connection, instead of registering each one separately. Handy if you don’t need to scope access per toolset and just want everything available in one go.

If this doesn’t return anything, there’s no point moving on to the client setup yet - go back and check the deployment step, the container is running, and port 8448 is reachable from where you’re testing.

Read-Only vs Read-Write: Know Which Mode You’re In

This part matters more than it sounds. The MCP server can run in one of two modes, and it’s your AAP admin who sets this globally at deployment time, not something you toggle per user:

Even in read-write mode, your token’s RBAC permissions are still the ceiling - the AI tool never gets more access than the account behind it. Red Hat’s own documentation flags a fair warning here: LLMs can occasionally misread a prompt or invent a command, so turning on read-write access does carry some risk of unintended changes. Worth keeping in mind before flipping that switch on a production instance.

Creating an API Token

This is the part that actually authenticates you, and it’s fairly quick once you know where to look. The AI tool inherits whatever permissions this token has, so it’s worth being deliberate about which account you generate it from. See Red Hat’s guide on token-based authentication for more on how tokens work across AAP.

1. Log in to the Ansible Automation Platform web UI.

2. In the left sidebar, go to Access Management, then Users.

3. Click on your own username to land on your user profile.

4. Open the Tokens tab.

5. Click Create token.

6. Set the scope: Read if you just want monitoring, Write if you want the AI tool to actually launch jobs and change things.

7. Hit Create. The token only shows up once, so copy it somewhere safe right away.

The Six Toolsets You Get Access To

This is the part I found genuinely useful to understand upfront, because the MCP server doesn’t expose everything as one big bucket. It’s split into six toolsets, each registered separately, so you can pick and choose what your AI client actually has access to.

Job Management is the toolset customers reach for the most, honestly - asking “what’s the status of job 1042” beats hunting through the jobs list. Platform Configuration is read-only by default, and changing things there needs write access explicitly turned on.

Wiring Claude Code Up to Each Toolset

This part is specific to Claude Code - if you’re connecting Cursor, ChatGPT, or something else, the concept is the same but the exact registration steps will differ for your tool. Each toolset is added to Claude Code as its own MCP server entry. The pattern for the URL is:

https://<your-aap-host>:8448/<toolset_name>/mcp

Run the following in your terminal, swapping in your own AAP host and the token you generated earlier:

# Job Management
claude mcp add -s user -t http \
  aap-mcp-job-mgmt https://<your-aap-host>:8448/job_management/mcp \
  -H "Authorization: Bearer <your-aap-token>"

# Inventory Management
claude mcp add -s user -t http \
  aap-mcp-inventory-mgmt https://<your-aap-host>:8448/inventory_management/mcp \
  -H "Authorization: Bearer <your-aap-token>"

# System Monitoring
claude mcp add -s user -t http \
  aap-mcp-system-monitoring https://<your-aap-host>:8448/system_monitoring/mcp \
  -H "Authorization: Bearer <your-aap-token>"

# User Management
claude mcp add -s user -t http \
  aap-mcp-user-mgmt https://<your-aap-host>:8448/user_management/mcp \
  -H "Authorization: Bearer <your-aap-token>"

# Security and Compliance
claude mcp add -s user -t http \
  aap-mcp-security-compliance https://<your-aap-host>:8448/security_compliance/mcp \
  -H "Authorization: Bearer <your-aap-token>"

# Platform Configuration
claude mcp add -s user -t http \
  aap-mcp-platform-config https://<your-aap-host>:8448/platform_configuration/mcp \
  -H "Authorization: Bearer <your-aap-token>"

A couple of flags worth knowing when you run those commands: -s user saves the config globally so it’s available across all your projects (use -s project if you only want it scoped to one), and -t http tells Claude Code this is an HTTP-based MCP server, which is how AAP exposes it. The -H flag is just passing your token along as an auth header.

Each command confirms success with something like:

Added HTTP MCP server aap-mcp-job-mgmt with URL: https://...

Once each command runs, the config gets saved to ~/.claude.json on your machine. It’s just JSON, so you can also skip the CLI entirely and edit it directly - each entry ends up looking like this:

{
  "mcpServers": {
    "aap-mcp-job-mgmt": {
      "type": "http",
      "url": "https://<your-aap-host>:8448/job_management/mcp",
      "headers": {
        "Authorization": "Bearer <your-aap-token>"
      }
    }
  }
}

Repeat that block for each of the six toolsets, with the matching URL path and server name. Handy to know if you ever need to fix a typo or swap a token without re-running the whole set of commands.

Dealing With Self-Signed Certificates

If your AAP environment is a lab or internal setup, chances are it’s running a self-signed certificate, and Claude Code (being Node.js under the hood) will reject that connection by default.

You’ve got two options.

Option A: Set it permanently in Claude Code settings. Open ~/.claude/settings.json and add NODE_TLS_REJECT_UNAUTHORIZED to the env block:

{
  "env": {
    "NODE_TLS_REJECT_UNAUTHORIZED": "0"
  }
}

Option B: Set it for a single session instead, without touching the settings file:

NODE_TLS_REJECT_UNAUTHORIZED=0 claude

Confirming It All Works

Restart Claude Code so it picks up the new MCP servers, then just ask it something simple like “what MCP tools are available for my Ansible Automation Platform?” If everything’s wired up correctly, it’ll list out the tools from each toolset you registered.

$ claude mcp list
aap-mcp-job-mgmt: https://aapaio.lab.gineesh.com:8448/job_management/mcp (HTTP) - ✔ Connected
aap-mcp-user-mgmt: https://aapaio.lab.gineesh.com:8448/user_management/mcp (HTTP) - ✔ Connected
aap-mcp-inventory-mgmt: https://aapaio.lab.gineesh.com:8448/inventory_management/mcp (HTTP) - ✔ Connected
aap-mcp-system-monitoring: https://aapaio.lab.gineesh.com:8448/system_monitoring/mcp (HTTP) - ✔ Connected
aap-mcp-security-compliance: https://aapaio.lab.gineesh.com:8448/security_compliance/mcp (HTTP) - ✔ Connected
aap-mcp-platform-config: https://aapaio.lab.gineesh.com:8448/platform_configuration/mcp (HTTP) - ✔ Connected

What This Actually Looks Like: Real Scenarios

Reading a list of features doesn’t really tell you much until you see it in action, so here are a few scenarios pulled from how customers end up using this day to day. Each one is just a short back-and-forth with Claude Code, no UI involved.

Scenario 1: Quick Platform Health Check

Goal: get a full picture of the platform without logging into the UI at all.

❯ Show me a summary of my Ansible Automation Platform - how many job templates, inventories, and users are configured?
❯ Are there any jobs currently running?
❯ Show me all failed jobs from the last 7 days

❯ Show me a summary of my Ansible Automation Platform - how many job templates, inventories, and users are configured?
...
  Thought for 4s (ctrl+o to expand)

● I'll pull the counts from your AAP instance in parallel.

  Called aap-mcp-job-mgmt, aap-mcp-inventory-mgmt, aap-mcp-user-mgmt 3 times (ctrl+o to expand)

● Here's a summary of your Ansible Automation Platform:

  ┌───────────────┬───────┐
  │   Resource    │ Count │
  ├───────────────┼───────┤
  │ Job Templates │ 37    │
  ├───────────────┼───────┤
  │ Inventories   │ 6     │
  ├───────────────┼───────┤
  │ Users         │ 9     │
  └───────────────┴───────┘

  A few highlights:
  - Job templates are primarily under the Cac-Demo-Org organization, using projects like Ansible-Real-Life-Cac.
  - Inventories include ones like Cac-Demo-Inventory (21 hosts, 11 groups) and AIOps-Localhost.
  - The admin user is a superuser, last logged in on July 17, 2026.

  Want me to drill deeper into any of these — list all job templates, show inventory details, or check recent job runs?

Scenario 2: Investigate a Failed Job

Goal: troubleshoot a failure entirely through conversation, no clicking through job logs manually.

❯ List the last 5 failed jobs
❯ Show me the error output for job <ID from above>
❯ Which host did it fail on and what task caused the failure?
❯ Show me the facts for that host from the inventory

Scenario 3: End-to-End Job Execution

Goal: launch a job, monitor it, and review the result, all without leaving Claude Code.

❯ List all job templates that contain "ocp" in the name
...

  Called aap-mcp-job-mgmt (ctrl+o to expand)

● Found 6 job templates containing "OCP" in the name. All are part of the Disaster Recovery (DR) workflow:

  ┌─────┬───────────────────────────────┬───────────────────────────────────────────────────────┬─────────────────┐
  │ ID  │             Name              │                      Description                      │ Last Run Status │
  ├─────┼───────────────────────────────┼───────────────────────────────────────────────────────┼─────────────────┤
  │ 26  │ DR-02-App-Stop-OCP            │ Stop application services on OpenShift - Primary Site │ Successful      │
  ├─────┼───────────────────────────────┼───────────────────────────────────────────────────────┼─────────────────┤
  │ 30  │ DR-06-Storage-Unmount-OCP     │ Unmount OpenShift storage volumes - Primary Site      │ Successful      │
  ├─────┼───────────────────────────────┼───────────────────────────────────────────────────────┼─────────────────┤
  │ 34  │ DR-10-Storage-BreakSync-OCP   │ Break storage replication sync for OCP volumes        │ Successful      │
  ├─────┼───────────────────────────────┼───────────────────────────────────────────────────────┼─────────────────┤
  │ 38  │ DR-14-Storage-Mount-OCP       │ Mount OpenShift storage volumes - DR Site             │ Successful      │
  ├─────┼───────────────────────────────┼───────────────────────────────────────────────────────┼─────────────────┤
  │ 43  │ DR-19-App-Start-OCP           │ Start application services on OpenShift - DR Site     │ Never run       │
  ├─────┼───────────────────────────────┼───────────────────────────────────────────────────────┼─────────────────┤
  │ 45  │ DR-21-Storage-ReverseSync-OCP │ Establish reverse replication sync for OCP volumes    │ Never run       │
  └─────┴───────────────────────────────┴───────────────────────────────────────────────────────┴─────────────────┘

  All are labeled critical, DR, and production, and belong to the Cac-Demo-Org organization. The first four have been run
  successfully; the last two (App-Start and ReverseSync) haven't been executed yet.

✻ Sautéed for 15s

More examples:

❯ Launch the "patch-rhel-servers" job template against the staging inventory
❯ What is the status of that job? Is it still running?
❯ Show me the full output of that job

Scenario 7: Multi-Step Operational Workflow (Advanced)

Goal: chain multiple actions in a single conversation. This is where the conversational approach really pulls ahead of clicking through a UI.

❯ I need to patch all staging servers. First, show me the hosts in the staging inventory so I can verify the target list.
❯ Good. Now launch the "pre-patch-snapshot" job template against those hosts.
❯ Wait for it to finish and show me the result.
❯ All snapshots succeeded. Now launch the "patch-rhel-servers" job template against the same staging inventory.
❯ Show me the job output - did all hosts patch successfully?
❯ Which hosts required a reboot?

None of this replaces the AAP UI entirely, but for quick checks, troubleshooting, and routine operational workflows, it’s genuinely faster than navigating there manually.

A Few More Scenarios Worth Trying

If you want to explore further, here are some other prompts worth running against your own environment:

• Inventory exploration - list all inventories, show hosts in a specific inventory, check which groups a host belongs to
• User access audit - list all users and roles, check who has admin access, review team membership and permissions
• Credential safety check - list credential types, see which credentials a job template uses, spot unused credentials worth cleaning up
• Comparing environments - list hosts across two inventories and check for drift, or review the execution environments configured on the platform

When Something Doesn’t Connect

A few things worth checking if it’s not working:

Certificate errors usually mean you need NODE_TLS_REJECT_UNAUTHORIZED=0 set, as covered above. Connection refused generally points to the MCP server not actually running, or port 8448 not being reachable from where you are. A 401 means your token’s expired or wrong, so generate a fresh one. A 403 means the token’s valid, but its RBAC permissions don’t cover whatever you just tried to do. And if the tools just aren’t showing up at all in Claude Code, a full restart usually fixes it.

You can always check what’s currently registered with:

$ claude mcp list

And remove anything misconfigured with claude mcp remove <server-name>.

Wrapping Up

This is still a Technology Preview feature, so I wouldn’t bet production workflows on it yet, but as a way to interact with AAP without constant UI navigation, it’s already proven useful across the customer environments I’ve set it up in. If you’re running AAP 2.6 or later and haven’t tried this yet, it’s worth an afternoon to set up - and remember, it’s not locked to Claude Code, so use whichever AI tool your team already works in.

If you want to go deeper on the official deployment steps, Red Hat’s documentation is the right place: Deploy Ansible MCP server on Ansible Automation Platform.

Happy Engineering!