I’m using AI…you’re using AI…now how do we get it to play with the rest of our tools? MCP is the way my friends.

I’m going to cover how I quickly connected my AAP MCP to Claude Code(CC) running on a RHEL 9 VM. I was initially trying to do it via the Windows desktop app, but as of this writing it’s not quite there yet.

Video Demo

What is an MCP

First, an Model Context Protocol(MCP) is a standardized interface that exposes tools, data, and actions to an AI model, allowing it to interact with external systems in a structured, consistent way.

Essentially an MCP acts as an interpreter for an LLM to talk to a software stack.

Why would you need an MCP when your software already has an API?
Each API is a little bit different. They have different options inside not to mention the way you interact with them is different for each.
An MCP is always interfaced the same, so no matter if you are using ChatGPT, Claude, or any other Large Language Model(LLM), it will automatically know how to talk to it. Not only this, but it can query the MCP to learn its capabilities, so the MCP will tell your LLM exactly what it can do!

Install The AAP MCP

Here’s the documentation on deploying your MCP on your AAP install. It’s really just a matter of grabbing a recent version of the installer, configuring the MCP section, and running said installer.

Configure inventory for installer

1
2
3
4
5
6
7
8
9
10
11

# This section is for your Ansible MCP Server host(s)
# -----------------------------------------------------
[ansiblemcp]
aap.example.com
 
[all:vars]
lightspeed_mcp_controller_enabled=true
lightspeed_mcp_ignore_certificate_errors=true
mcp_ignore_certificate_errors=true
lightspeed_mcp_allow_write_operations=false
mcp_allow_write_operations=false

Notice above that I turned off write permission, which means I will only be able to read from the MCP server, which means the LLM of choice can’t make any changes on my AAP instance. I feel this is a good place to start. Also note I have a mix of variable names for the same thing…a bit of old documentation mixed with new and I’m not sure which is the one to use moving forward(it’s not hurting to have them both for now LOL).

Then rerun the installer and you should be good to go.

1

ansible-playbook -i inventory.ini ansible.containerized_installer.install

Note: The MCP server will default to port 8443, so ensure you have that open on your firewalls between your machine running Claude Code and the MCP server.

AAP API Token

Documentation is here.
To authenticate your LLM to the MCP you have to setup a token.
Go to access management, users, select your user, click on the API Tokens tab, and click the + to add a new one:

Here you will give a description and set the scope. So here I have the scope set to read, but even if I set it to write the LLM wouldn’t be able to write because when I installed the MCP server I disabled writing. So setting this to read is kind of a belt and suspenders safety. I want to be very specific with permissions, because at some point in the future I will set the MCP server to write, so I want to ensure users are correctly configured now.

Once you click create token you will be supplied with the token one time, so be sure to save it in a password vault.

As a note, best practice is to have each user who wants to have their LLM connect to the MCP should use their own credential to create a token. This means the MCP will only have access to what their credential has access to, so it helps prevent accidental access to unauthorized resources. It also makes it easy to expire that user without affecting anyone else.

Configure Claude Code

From the CC project folder where you want to access your LLM, issue the following commands. Note that at the time of this writing these are all of the supported MCP servers for AAP. Each one supplies access to different aspects of AAP and each has its own capabilities. Only enter the ones you want your LLM to access:

1
2
3
4
5

claude mcp add aap-job --transport http "https://aap.example.com:8448/job_management/mcp" --header "Authorization: Bearer YourTokenHere"
claude mcp add aap-inv --transport http "https://aap.example.com:8448/inventory_management/mcp" --header "Authorization: Bearer YourTokenHere"
claude mcp add aap-mon --transport http "https://aap.example.com:8448/system_monitoring/mcp" --header "Authorization: Bearer YourTokenHere"
claude mcp add aap-user --transport http "https://aap.example.com:8448/user_management/mcp" --header "Authorization: Bearer YourTokenHere"
claude mcp add aap-sec --transport http "https://aap.example.com:8448/security_compliance/mcp" --header "Authorization: Bearer YourTokenHere"

Here a breakdown of what each does:
Job management
Tools to list available job templates, launch automation jobs, and monitor their real-time status.

Inventory management
Tools to query your inventory for host details, check group membership, and verify system facts.

System monitoring
Tools to retrieve job logs, troubleshoot failed tasks, and check the health of your automation environment.

User management
Tools to allow the AI agent to administer access and organizational structure within Ansible Automation Platform.

Security and compliance
Tools that enable the AI agent to act as a security operator, managing sensitive credentials and verifying platform integrity without exposing raw secrets.

Platform configuration
Tools that enable administrators and developers to inspect and tune Ansible Automation Platform infrastructure itself.

Now when you load up claude from that folder you will be able to access these MCPs natively.

To view their status issue(optional):

1

/mcp

A decent prompt to start with is:

1

Using the aap mcp tools, XXX

So this could be something like:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

Using the aap mcp tools, find the last job templates that ran against the nexus9k3 switch and let me know the name of the job along with its outcome.
 
Here's the full report of every job where nexus9k3 was involved across your AAP environment:
 
  ---
  nexus9k3 Job Report
 
  Total jobs scanned: 185
  Jobs involving nexus9k3: 73 jobs across 5 job templates
 
  ---
  1. group_vars testing — 1 job
 
  ┌─────┬─────────────────────────┬──────────────────────────────────────────┐
  │ Job │         Status          │           Result for nexus9k3            │
  ├─────┼─────────────────────────┼──────────────────────────────────────────┤
  │ 500 │ Successful (2026-01-26) │ OK: 1, Changed: 0, Failed: 0, Skipped: 0 │
  └─────┴─────────────────────────┴──────────────────────────────────────────┘
 
  ---
  2. Netbox - nexus vlans — 21 jobs
 
  - All successful except job 1030 (2026-04-30), where nexus9k3 had 1 failed task
  - Typical result: OK: 2, Changed: 0–2, Skipped: 2–4
  - One run (job 535) had nexus9k3 fully skipped (all 4 tasks skipped)
 
  ---
  3. Netbox - nexus int desc — 16 jobs
 
  - All successful, all runs clean
  - Typical result: OK: 1, Changed: 0–1, Skipped: 0
 
  ---
  4. nexus stale interface report — 33 jobs (2026-02-27 to 2026-02-28)
 
  - 7 jobs where nexus9k3 had failed tasks: Jobs 791, 811, 836, 842, 846, 852, 854
  - Failures showed OK: 0–2, Failed: 1, suggesting intermittent connectivity or task issues during that testing period
  - All other runs in this template were successful for nexus9k3
 
  ---
  5. python networking integration — 16 jobs (2026-03-05)
 
  - 2 early runs failed for nexus9k3: Jobs 869, 871 (OK: 0, Failed: 1)
  - Template was stabilized after those initial failures
  - All subsequent runs were successful
 
  ---
  Key Takeaways
 
  - nexus9k3 was never unreachable in any job (unreachable count always 0)
  - The bulk of failures were concentrated in late Feb 2026 during "nexus stale interface report" development and early March 2026
  during "python networking integration" testing — both appear to be transient issues during template development
  - The Netbox vlan/int desc jobs have been rock solid for nexus9k3, with only a single task failure in job 1030 on 2026-04-30

Connecting your LLM With Self Signed Certs

In my lab I went direct to the server rather than through the normal channels so it couldn’t authenticate the cert. What I did was connect to the VM with the AAP container and nabbed the root CA files and installed them on my RHEL server running CC. You could follow these steps on your own or have CC walk you through the process LOL.

1. Diagnosing that your failure to connect is the cert:

1

curl -v https://aap.example.com:8448/job_management/mcp -H "Authorization: <token>"

Look for: SSL certificate problem: unable to get local issuer certificate — confirms a CA trust issue.

2. Find the CA Cert on the AAP Server

SSH into the AAP host and locate the CA cert:

1

find /home /root /opt /var -name "*.crt" -o -name "*.pem" 2>/dev/null | grep -iv "mozilla\|nss\|pki/tls"

For containerized AAP 2.6 on RHEL 9, it’s typically at:

1

/home/<user>/.config/containers/certs.d/aap.example.com:443/ca.crt

Verify it’s the right cert (subject and issuer should both say Ansible Automation Platform):

1

openssl x509 -in /home/gsowell/.config/containers/certs.d/aap.example.com:443/ca.crt -noout -subject -issuer

3. Copy and Extract the CA Cert

Copy from the AAP host to the machine running Claude Code:

1

scp [email protected]:/home/gsowell/.config/containers/certs.d/aap.example.com\:443/ca.crt /tmp/aap-root-ca.crt

Extract just the AAP CA cert from the bundle:

1
2
3
4
5
6
7
8

  csplit -z -f /tmp/aap-cert- /tmp/aap-root-ca.crt '/-----BEGIN CERTIFICATE-----/' '{*}'
  for f in /tmp/aap-cert-*; do
    subj=$(openssl x509 -in "$f" -noout -subject 2>/dev/null)
    if echo "$subj" | grep -q "Ansible Automation Platform"; then
      cp "$f" /tmp/aap-ca-only.crt
      echo "Extracted: $f"
    fi
  done

Verify the extracted cert:

1

  openssl x509 -in /tmp/aap-ca-only.crt -noout -subject -issuer

4. Add to System Trust Store

1
2

  sudo cp /tmp/aap-ca-only.crt /etc/pki/ca-trust/source/anchors/aap-root-ca.crt
  sudo update-ca-trust

5. Verify

1
2

  curl -s https://aap.example.com:8448/job_management/mcp \
    -H "Authorization: <token>" -o /dev/null -w "HTTP status: %{http_code}\n"

Anything other than a TLS error (e.g. 200, 405) confirms the cert is trusted.

Conclusion

Connecting to the AAP MCP isn’t too bad. I look forward to the standard desktop client getting access, but until then I plan to build some interesting workflows.
How do you plan to use this…have anything interesting planned?

Thanks for reading and happy MCPing 🙂