Hi everyone,
I wanted to open a discussion about something I think could be a valuable addition to the Ascender ecosystem: a Model Context Protocol (MCP) server for Ascender.
For those unfamiliar, MCP is an open standard (originally from Anthropic, now widely adopted) that allows AI coding agents — Claude Code, GitHub Copilot, Cursor, Windsurf, and others — to interact with external tools and APIs through a structured interface. Instead of the AI agent having to craft raw curl commands against a REST API, an MCP server exposes well-defined "tools" that the agent can call natively, with proper input validation, descriptions, and error handling.
The problem today is I run Ascender both in production and in my homelab, and I've been increasingly using AI agents (primarily Claude Code) for infrastructure automation tasks that involve Ascender — launching jobs, checking inventory syncs, managing projects, debugging failed runs, etc.
Right now, the experience is rough. Without a proper MCP server, the agent falls back to raw API calls (curl against /api/v2/), which means:
The agent has to discover the API structure on its own every time
No input validation or guardrails before executing actions
No structured output — the agent parses raw JSON responses
Context gets wasted on API plumbing instead of actual problem-solving
There are a few community MCP servers for AWX out there (e.g., a37ai/ansible-tower-mcp and forks, SurgeX-Labs/awx-mcp-server), but they all have significant gaps — most cover only a handful of endpoints (job templates, jobs, projects, inventories) and miss large parts of the API surface (credentials, credential types, execution environments, schedules, workflow job templates, notification templates, inventory sources, etc.). I've been working with a fork of one of these and hitting its limitations constantly.
That brings me to the proposal ; I was already planning to write my own MCP server from scratch, based on the patterns I've seen in the existing community projects but with much better API coverage. However, I think it would be far more valuable to have this as an official Ascender project, something the community can build and evolve together, rather than yet another individual fork.
The Ascender API is very regular, and vy regular I mean most resources follow the same CRUD patterns under /api/v2/ — which makes it a great candidate for a well-structured MCP server that can cover the full API surface systematically rather than one endpoint at a time.
An official ascender-mcp would fit naturally alongside the existing ecosystem projects (ascender-install, ascender-ledger, ascender-ee) and would position Ascender ahead of both upstream AWX and Red Hat AAP in terms of AI tooling integration (I think!).
Suggested scope for an initial version
A reasonable MVP could cover:
Job Templates & Workflow Job Templates: list, get details, launch
Jobs & Workflow Jobs: list, get status, get stdout/events, cancel, relaunch
Projects: list, get details, trigger SCM update
Inventories & Inventory Sources: list, get details, trigger sync
Credentials & Credential Types: list, get details
Execution Environments: list, get details
Organizations & Teams: list, get details
Schedules: list, get details, enable/disable
Unified Jobs: search/filter across job types
Settings: read configuration (non-sensitive)
With the MCP SDK (Python), this is not a massive undertaking — the Ascender API is well-documented and consistent and it's mostly what awx was at least right now.
About me (I understand that this may look like a significant request, so I want to present myself a little bit)
I'm beginning to contribute to the Ascender project and I'm mostly an aap, awx and ascender user, that said I'm willing to contribute more to the project, I have a merged PR fixing the UnifiedJob.save() / finished timestamp issue on pending-cancelled jobs (#247). I run Ascender in production at work (team of 5 engineers, platform engineering) and in my homelab for learning and testing. I'd be happy to lead the initial development effort and contribute the first working version.
Question would be mostly for CIQ and community is there interest from CIQ in hosting this under the ctrliq org (e.g., ctrliq/ascender-mcp)?
Is anyone else already working on something similar?
