AnsibleByExample

Ansible MCP Job Management Example: Launch and Monitor Jobs 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, a Tech Preview shown at Red Hat Tech Day Netherlands 2026 in Bunnik, exposes AAP as 107 declarative tools across six sets. The Job management set alone carries 25 tools for launching, monitoring, and cancelling jobs — enough for an AI chat client to run real operations against AAP without a human touching the UI.

Connecting a client to the Job management tools

# mcp-client-config.yaml
# Example client-side config for an MCP-aware IDE/agent (e.g. Cursor)
# pointing at the hosted AAP MCP Server over plain HTTP with Bearer auth.
mcpServers:
  aap:
    url: "https://aap-mcp.example.com/mcp"
    transport: "http"
    headers:
      Authorization: "Bearer {{ aap_mcp_token }}"
    toolsets:
      - job_management     # 25 tools: launch, monitor, cancel jobs
      - inventory_management
      - system_monitoring

# example inventory used by the "Paint" job template referenced below
# inventories/paint-demo.yml
all:
  hosts:
    paint-node1:
      ansible_host: 10.0.4.21
  vars:
    ec2_vpc_name: aap

What happens when you chat with it

This isn't a playbook you run with ansible-playbook — it's a natural-language session against the MCP server, which then calls AAP's REST API on your behalf using the Job management tool set. A transcript from the kind demoed live:

You: show me the last 5 jobs from AAP

Assistant: (calls job_management.list_jobs, limit=5)
| ID   | Job Template     | Status   | Finished             |
|------|------------------|----------|----------------------|
| 4821 | Deploy-WebApp     | successful | 2026-06-03 09:14:02 |
| 4820 | Paint             | failed     | 2026-06-03 09:10:47 |
| 4819 | Nightly-Patch     | successful | 2026-06-03 02:00:11 |
| 4818 | Paint             | failed     | 2026-06-03 09:10:44 |
| 4817 | Backup-DB         | successful | 2026-06-02 22:00:03 |

You: launch the Paint job template with color=Purple

Assistant: (calls job_management.launch_job, template=Paint, survey={color: Purple})
Request rejected: survey field "color" only accepts one of
["Red", "Green", "Blue"]. AAP's survey validation blocked this
launch before it reached the scheduler.

You: job 4820 failed, find out why

Assistant: (calls job_management.get_job_stdout, id=4820)
(calls job_management.get_job_events, id=4820)
Root cause: task "Create VPC" references ec2_vpc_name "caap"
(typo — should be "aap"), so the lookup returned no matching VPC.
Also: jobs 4818 and 4820 ran in parallel against the same
inventory group, causing a race condition on VPC creation.
Recommend serializing this job template or adding a queue lock.

The first turn uses a read-only tool (list_jobs) to return a structured table straight from AAP's job list — no screen-scraping, just a declarative call. The second turn tries to launch a job with a bad survey answer; because validation lives in AAP itself, not in the LLM, the MCP server rejects it the same way the AAP UI would. The AI cannot talk its way past a guardrail it doesn't control. The third turn chains two more tools — pulling stdout and job events — to do real root-cause analysis, spotting both a typo and a concurrency bug from raw job output.

Notes

  • The Job management tool set (25 of the 107 total tools) covers launch, monitor, and cancel — it does not expose inventory editing or credential management, which live in their own tool sets (7 and 18 tools respectively).
  • Every write action (like launch_job) still passes through AAP's normal RBAC and survey validation. MCP is a transport and tool-calling layer, not a privilege escalation path.
  • The connection in the demo used plain HTTP with a Bearer token; treat that token like any other AAP API credential — scope it and rotate it.
  • This is a Tech Preview feature as shown at Red Hat Tech Day Netherlands 2026, so tool names and counts may change before general availability.

Takeaway: the Job management tool set turns "launch and monitor" into a conversation, but every guardrail — survey validation, RBAC, job history — still comes from AAP itself, not from the AI.

References

All Tutorials