AnsibleByExample

Ansible MCP Platform Configuration Example: Manage Credentials 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 an LLM agent can call directly. Demoed live at Red Hat Tech Day Netherlands 2026 by Fred van Zwieten via Cursor IDE, the server ships six tool sets totaling 107 tools; the Platform configuration set (18 tools) covers settings, credentials, and integrations — the surface you'd normally reach through the AAP UI or awx.awx modules.

Example: connecting to the MCP server

---
- name: Register AAP MCP server as an agent tool source
  hosts: localhost
  gather_facts: false
  vars:
    aap_mcp_endpoint: "https://aap.example.com/mcp/v1"
    aap_mcp_token: "{{ lookup('env', 'AAP_MCP_BEARER_TOKEN') }}"
  tasks:
    - name: Confirm MCP endpoint is reachable and authenticated
      ansible.builtin.uri:
        url: "{{ aap_mcp_endpoint }}/tools/list"
        method: GET
        headers:
          Authorization: "Bearer {{ aap_mcp_token }}"
          Accept: "application/json"
        status_code: 200
      register: mcp_tools

    - name: Show the platform_configuration tool set
      ansible.builtin.debug:
        msg: "{{ mcp_tools.json.tools | selectattr('name', 'match', '^platform_configuration_') | map(attribute='name') | list }}"

What the tool set actually does

The 18 Platform configuration tools wrap read/write operations that already exist in AAP's own RBAC and credential model — the MCP server does not add new privileges, it just makes them agent-callable. In practice that means tools like platform_configuration_list_credentials, platform_configuration_get_credential_type, platform_configuration_update_setting, and platform_configuration_list_integrations.

A natural-language session against these tools looks like this:

You:   List the credentials scoped to the "network-ops" organization.

Agent: [calls platform_configuration_list_credentials(org="network-ops")]
       3 credentials found:
       - core-switch-ssh (Machine, last used 2 hours ago)
       - netbox-api-token (Custom, last used 6 days ago)
       - vault-network-ops (Vault, last used 14 minutes ago)

You:   Which of those haven't been rotated in over 90 days?

Agent: [calls platform_configuration_get_credential_type for each,
        cross-checks metadata.updated_at]
       core-switch-ssh was last updated 118 days ago — flagged.
       The other two are within policy.

You:   Rotate core-switch-ssh's password to a new generated value.

Agent: I can't rotate credential secrets directly — the platform_configuration
       tool set exposes metadata and settings, not secret material writes.
       Use `platform_configuration_update_setting` for org policy changes,
       or update the credential through AAP's credential form.

That last exchange isn't a scripted refusal — it mirrors the guardrail behavior Fred van Zwieten showed live: when he launched a "Paint" job template with an invalid survey value ("Purple"), the MCP server rejected it because it enforces AAP's own survey validation server-side. The AI agent can query and reason, but it cannot bypass controls AAP itself enforces — credential secret values are a good example of a boundary the tool set respects by design.

Notes / Gotchas

  • Tech Preview status. The MCP server is not GA; endpoint names and exact tool signatures shown here are illustrative of the announced tool set, not a frozen API.
  • Plain HTTP + Bearer token is what was demoed — put this behind TLS and a short-lived token in any real deployment, same as you would for the AAP API itself.
  • Read-heavy by design. Of the six tool sets (job management 25, inventory 7, system monitoring 13, user management 32, security and compliance 12, platform configuration 18), platform configuration is the one most likely to touch sensitive data — audit which tools are write-capable before granting an agent broad scope.
  • Validation still lives in AAP, not in the agent or the MCP layer — the Paint/Purple survey rejection at Tech Day Netherlands 2026 demonstrated this is enforced downstream, not something the agent has to get right on its own.

An MCP-connected agent can inventory and reason about your credentials in plain English, but AAP's own RBAC and validation remain the actual gatekeeper — the agent is a new client, not a new set of permissions.

References

All Tutorials