AnsibleByExample

Ansible MCP User Management Example: Query Permissions via AI Chat

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 is a Tech Preview that exposes AAP as declarative tool sets to any LLM/agentic client. Fred van Zwieten demoed it live at Red Hat Tech Day Netherlands 2026 (Bunnik, 3 June 2026) from Cursor IDE over plain HTTP with Bearer-token auth. The User management tool set (32 tools) lets an AI chat client query permissions, roles, and teams without a human writing a single API call.

Playbook: audit team role assignments

Below is a companion playbook you'd still run through AAP itself for scheduled audits — the MCP chat path (shown after) is for ad hoc, natural-language lookups against the same data.

---
- name: Audit team role assignments in AAP
  hosts: localhost
  gather_facts: false
  vars:
    aap_host: "https://aap.example.com"
    aap_token: "{{ lookup('env', 'AAP_TOKEN') }}"

  tasks:
    - name: Fetch team list
      ansible.controller.team_info:
        controller_host: "{{ aap_host }}"
        controller_oauthtoken: "{{ aap_token }}"
        validate_certs: true
      register: teams_result

    - name: Fetch role assignments for each team
      ansible.controller.role_team_assignment_info:
        controller_host: "{{ aap_host }}"
        controller_oauthtoken: "{{ aap_token }}"
        team: "{{ item.name }}"
      loop: "{{ teams_result.results }}"
      register: role_assignments

    - name: Report teams with Admin role on Job Templates
      ansible.builtin.debug:
        msg: "Team {{ item.item.name }} holds Admin on Job Templates"
      loop: "{{ role_assignments.results }}"
      when: item.role_assignments | selectattr('role', 'equalto', 'Admin') | list | length > 0

What it does

The playbook pulls every team, then walks each team's role assignments, flagging any team with Admin rights on Job Templates. It's the kind of check a security team runs weekly. The MCP User management tool set exposes the same underlying data — roles, teams, permissions — as 32 individually callable tools, so an agent can answer the same question interactively instead of waiting for a scheduled job.

Natural-language example via MCP

This is illustrative of the interaction pattern shown in the Cursor IDE demo, using the same request/response shape as the live "last 5 jobs" and job-launch examples:

You:   Which teams have Admin permissions on the "Network Ops" job template?

Agent: [calling tool: list_role_assignments_for_job_template]
       [calling tool: resolve_team_names]

       Two teams currently hold Admin on "Network Ops":
       | Team          | Role  | Granted By   |
       |---------------|-------|--------------|
       | NetOps-Leads  | Admin | org_admin    |
       | Automation-CoE| Admin | org_admin    |

You:   Does the "Contractors" team have Execute rights on it too?

Agent: [calling tool: get_team_permissions]

       No. "Contractors" has no role assignment on "Network Ops".
       Its only grant is Read on the "Sandbox" inventory.

The agent chains multiple User management tools (listing role assignments, resolving team names, checking a specific team's permissions) behind one plain-English question, then returns a structured table — the same "structured table via natural language" behavior Red Hat showed for job history queries.

Notes / Gotchas

  • Tech Preview: the MCP Server isn't GA — treat outputs as advisory and keep the audit playbook as your source of truth until it graduates.
  • Read vs. write: querying permissions is safe by nature, but the same MCP connection can reach the other 106 tools across five other tool sets, including job launch. Scope the Bearer token narrowly if you only want read access to User management.
  • Guardrails still apply: Red Hat's demo showed AAP rejecting an invalid survey value ("Purple") on a job launch through MCP — the server enforces AAP's own validation, it doesn't let the AI bypass RBAC or survey rules either.
  • Auth: the demoed connection used plain HTTP with a Bearer token; use TLS and short-lived tokens in any real deployment.

Takeaway

The User management tool set turns "who can do what in AAP" from an API-digging exercise into a chat question, while the underlying RBAC engine — and playbooks like the one above — remain the actual enforcement and audit trail.

References

All Tutorials