AnsibleByExample

Ansible MCP System Monitoring Example: Check Service Health via AI Agent

Beginner
2024-01-014By Luca Berton

Lesson 1 of 15 in Foundations

Ansible Foundations to Production — full curriculum
  1. 1. Introduction to Ansible and Automation
  2. 2. Installing and Configuring Ansible
  3. 3. Running Ad-Hoc Commands
  4. 4. Writing Your First Playbook
  5. 5. Understanding and Using Modules
  6. 6. Variables and Facts
  7. 7. Conditionals and Loops
  8. 8. Handlers and Idempotency
  9. 9. Structuring Projects with Roles
  10. 10. Inventory Management
  11. 11. Using Ansible Vault for Secrets
  12. 12. Debugging and Troubleshooting
  13. 13. Real-World Automation Examples
  14. 14. Final Project: Deploy a Web Server
  15. 15. Bonus - What's Next with Ansible?
View path overview →

Red Hat's hosted MCP (Model Context Protocol) Server for Ansible Automation Platform exposes AAP as a set of declarative tools that any LLM or agentic client can call. Among the 107 tools across six tool sets, the System monitoring set (13 tools) covers service health and resource usage — the kind of check you'd otherwise run by hand against /api/v2/ping/ or the AAP dashboard.

Example: querying service health with a playbook fallback

Even with an AI agent doing the asking, the MCP server still just calls AAP's own API underneath. The equivalent direct automation — useful when you want the same health check without a chat client in the loop — looks like this:

---
- name: Check AAP service health via API
  hosts: localhost
  gather_facts: false
  vars:
    aap_hostname: "https://aap.example.com"
    aap_validate_certs: true

  tasks:
    - name: Query AAP ping/health endpoint
      ansible.builtin.uri:
        url: "{{ aap_hostname }}/api/v2/ping/"
        method: GET
        headers:
          Authorization: "Bearer {{ aap_mcp_token }}"
        validate_certs: "{{ aap_validate_certs }}"
        status_code: 200
      register: aap_health

    - name: Report unhealthy instance groups
      ansible.builtin.debug:
        msg: "Instance group {{ item.name }} has {{ item.capacity }} capacity"
      loop: "{{ aap_health.json.instance_groups }}"
      when: item.capacity == 0

What it does

The task hits AAP's ping endpoint with the same Bearer-token HTTP auth the hosted MCP Server uses (demoed live via Cursor IDE at Red Hat Tech Day Netherlands 2026 in Bunnik by Fred van Zwieten). It returns node status, instance group capacity, and version info, then flags any instance group reporting zero capacity — a quick signal that a controller node or execution node is down.

An AI agent connected to the MCP Server does the same thing conversationally. A transcript from that kind of session:

User: check service health on AAP and flag anything degraded

Agent: Calling system_monitoring.get_instance_health...

  Instance groups:
  - controlplane   capacity: 42   status: healthy
  - execution_west  capacity: 0    status: degraded
  - execution_east  capacity: 38   status: healthy

  execution_west is reporting zero capacity. Checking node-level status...

  Calling system_monitoring.get_node_status(group="execution_west")...

  Node aap-exec-04 is offline (last heartbeat 14 minutes ago).
  Recommend restarting the receptor service on aap-exec-04
  or removing it from the execution_west instance group.

The agent chains two of the 13 system monitoring tools — one for aggregate instance group health, one for per-node status — without the operator needing to know the underlying API paths. This mirrors the demo's other live examples, like returning a structured table for "show me the last 5 jobs from AAP," and reading job stdout to root-cause a failed run down to a typo in an ec2_vpc_name value.

Notes

  • The MCP Server is a Tech Preview hosted service — treat it as pre-production and don't wire it into critical alerting paths yet.
  • Read access to system monitoring tools still respects AAP's RBAC. An agent authenticated with a token scoped to a restricted user sees only what that user could see in the UI.
  • Guardrails apply everywhere, not just in job launches: in the same demo, launching a "Paint" job template with an invalid survey value ("Purple") was rejected because the MCP server enforces AAP's own survey validation — the AI cannot bypass those checks by calling a tool directly.
  • If you're scripting the equivalent check outside of an agent (as in the playbook above), store aap_mcp_token in Ansible Vault or an external secrets lookup, never inline.

Takeaway

System monitoring is one of the smaller tool sets (13 of 107) but it's the one that turns "is AAP healthy?" into a single natural-language question an agent can answer by chaining a couple of read-only API calls — with the same RBAC and validation guardrails as the AAP UI itself.

References

All Tutorials