Ask an AI assistant how to lint an Ansible playbook today, and you'll likely get a helpful but generic answer: "Use ansible-lint. Install it with pip install ansible-lint, then run it against your playbook." Correct. But not useful when you already have ansible-lint installed, your team has a custom linting profile, and what you wanted was for the tool to run and fix the violations.
That's the gap between an AI that describes and an AI that does. The Ansible development tools Model Context Protocol (MCP) server bridges it, and it works with whatever AI model you already use.
The Ansible playbook context-switching problem
Developing Ansible automation today involves constant context switching. Checking module documentation across upstream docs, Red Hat Knowledgebase articles, and internal communities of practice. Figuring out which tool to use and how to run it. Parsing AI-generated suggestions against what's installed. Correlating lint violations with runtime failures. All of it means jumping between browser tabs, terminals, and the editor. It adds up.
The workflow is fragmented, and it hits new automation developers hardest. When someone asks an AI assistant for help writing a playbook, the assistant generates syntactically correct code, but it might reference uninstalled collections, use nonexistent module parameters, or ignore the organization's naming conventions entirely. The AI doesn't know what's in the developer's local environment.
Model Context Protocol: From advisor to operator
The Model Context Protocol (MCP) is an open standard for connecting AI assistants to external tools through a unified interface. Instead of the AI guessing how to use a tool, MCP provides a structured contract: the tool declares what it can do (with full parameter schemas), and the AI calls it deterministically.
The Ansible development tools MCP server (@ansible/ansible-mcp-server) wraps the Ansible development tools command-line interface (CLI) into this protocol. With the MCP server configured, the interaction changes, as shown in Table 1:
| Scenario or prompt | Without MCP | With MCP |
|---|---|---|
| "How do I lint my playbook?" | AI explains how to install and run ansible-lint | AI finds the ansible-lint MCP tool, executes it, and returns results |
| "Set up my environment" | AI suggests various pip and galaxy commands | AI calls the environment setup tool directly |
| "Create a playbook for..." | AI scaffolds from memory, might hallucinate module names | AI uses ansible-creator through MCP, producing valid scaffolding |
| Quality check | Requires reading logs, fixing manually, re-prompting | AI runs lint, applies --fix, iterates until clean |
MCP adds a layer of abstraction between the AI and the tool, providing context around when, why, and exactly how to execute a particular process. This architecture cuts back on guesswork and non-deterministic behaviors, making AI-driven development reliable.
What the Ansible development tools MCP server can do
The current Ansible development tools MCP server covers the core automation developer workflow across several areas:
- Code quality: Run
ansible-lintagainst playbooks, roles, and collections, with the option to auto-fix violations. - Project scaffolding: Create new collections, playbooks, and roles through
ansible-creator, following organizational templates and standards. - Playbook execution: Run playbooks through
ansible-navigatorwith execution environment support. - Environment management: Set up, inspect, and verify Ansible development environments, including tool versions and dependencies.
- Execution environments: Define and build execution environment (EE) container images from within the conversation.
- Best practices: Surface community and organizational guidelines so the AI generates code that follows your team's conventions.
These aren't wrappers around generic shell commands. Each tool encodes the specific way an Ansible development tool needs to be invoked, with the right flags, the right order, and proper error handling. The AI doesn't figure out how to run ansible-lint on its own; it follows the implementation the Ansible engineering team built.
The engineering team is already expanding the MCP server to add plug-in discovery and documentation lookup across installed collections, Galaxy browsing, task and playbook generation grounded in real module schemas, and tighter integration between the MCP tools and the Visual Studio Code (VS Code) extension user interface (UI). The goal is full parity: anything a developer can do through the extension's interface, an AI agent can do through MCP, and vice versa.
Bring your own model
The Ansible development tools MCP server doesn't require a specific AI provider. It works with any MCP-compatible client, so automation developers and content creators can use the AI assistant they already have:
- GitHub Copilot in VS Code
- Claude Code in the terminal or VS Code
- Gemini CLI for Google's models
- Cursor, Windsurf, or any other MCP-compatible editor
The Ansible VS Code extension makes setup even simpler. The @ansible/ansible-mcp-server package ships bundled inside the extension itself. Set ansible.mcpServer.enabled to true, and the extension spawns the MCP server as a child process using VS Code's built-in Node.js runtime. No separate npm install, no Node.js on your PATH. It's available to any AI chat client in the integrated development environment (IDE) as soon as you enable the setting.
For organizations with specific AI governance requirements, the choice of model stays in their hands. The Ansible engineering team is currently developing a provider-agnostic middleware approach to decouple AI provider logic from the core extension. Users will configure their endpoint and API key in 1 place, enabling a "bring your own model" (model customization) setup working with local instances, air-gapped corporate servers, or any cloud provider.
Developing an Ansible playbook with a deterministic coding assistant
Model flexibility is 1 piece. The harder problem is accuracy. AI-generated Ansible code today often looks correct but fails on execution because the model doesn't know what's installed in the developer's environment.
By feeding the AI real-time context directly from the local workspace, the server prioritizes correctness over raw generation speed:
- Full
ansible-doccoverage via MCP, grounding the AI in authoritative schema data for every installed collection and module version - Environment-aware generation, where the AI won't generate code for missing dependencies and instead offers a path to resolve them (such as
ansible-galaxy install) within the chat interface - A documentation feedback loop, where code generates structured reference guides the AI consumes to ground its future suggestions
The goal: an AI assistant that doesn't hallucinate collection names or guess module parameters, because it knows what's available in your environment.
This solves a long-standing challenge for automation architects attempting to standardize practices across distributed engineering teams. Today, enforcing naming conventions, lint profiles, and approved patterns means writing a wiki and hoping everyone reads it. The MCP server includes a documentation and knowledge layer surfacing best practices, module documentation, and organizational guidelines directly into the AI conversation. Every developer's AI assistant follows the same standards because the MCP server injects local lint rules and schemas directly into every prompt interaction.
This layer is expanding in the next generation of the server, with deeper coverage of collection docs, plug-in schemas, and community guidance. While Ansible development workspaces keep your local tools and versions consistent, the MCP server keeps your playbooks aligned with team standards.
Note
Ansible development workspaces deliver consistent, browser-based environments with Red Hat OpenShift Dev Spaces, so every developer's AI assistant runs against the same toolchain.
What the Ansible MCP server looks like in practice
Integrating Ansible development tools with MCP simplifies both day-to-day content creation and broader operational management.
Inner loop: content development
Imagine you are building a new network automation collection and want to go from zero to clean, tested code without leaving your editor. You can ask your AI assistant:
"Scaffold a network automation collection, add a backup role, lint it, write Molecule tests, fix all violations."
The AI calls ansible-creator to scaffold the project, generates role defaults and tasks, runs ansible-lint against the team's profile, applies fixes, and presents the result for review. 1 context. No tab switching.
Outer loop: operational integration
While developers benefit from immediate local assistance in VS Code, platform engineers can provide governed MCP endpoints that safely connect content authoring to non-production execution environments. Available starting with Ansible Automation Platform 2.5 and generally available in Ansible Automation Platform 2.7, the Ansible Automation Platform gateway exposes MCP endpoints for job management, inventory queries, system monitoring, and more.
A platform engineer can ask:
"Show me failed jobs in the last 24 hours, check inventory for hosts missing the security baseline, launch the remediation template."
The AI queries the Ansible Automation Platform controller API for failed jobs, cross-references inventory data, and launches a job template, all through structured MCP calls with the user's role-based access control (RBAC) permissions. You can scope tokens as read-only for querying or read-write when job launching is needed.
Warning
Use development or staging Ansible Automation Platform instances for AI-assisted workflows.
AI assistants can launch jobs and modify platform state through the Ansible Automation Platform MCP server. Always point MCP configurations at non-production instances during development, and use a read-only token unless you specifically need the AI assistant to launch jobs.
Together, the Ansible development tools MCP server and the Ansible Automation Platform MCP server connect the inner loop (content creation) with the outer loop (content execution) through the same AI interface. Write a playbook, push it to a development Ansible Automation Platform instance, run it, troubleshoot failures. 1 conversation.
Getting started with the Ansible MCP server
In the VS Code extension: Install the Ansible extension for VS Code, then enable ansible.mcpServer.enabled in your settings. The MCP server starts automatically and is available to any AI chat client in VS Code.
With Claude Code:
claude mcp add ansible -- npx -y @ansible/ansible-mcp-server --stdioWith any MCP client (such as VS Code Copilot Chat or Cursor): Add to your MCP configuration:
{
"mcp": {
"servers": {
"ansible": {
"command": "npx",
"args": ["-y", "@ansible/ansible-mcp-server", "--stdio"],
"env": {
"WORKSPACE_ROOT": "${workspaceFolder}"
}
}
}
}
}As a container:
podman run --rm -i \
-v /path/to/your/ansible/project:/workspace \
-e WORKSPACE_ROOT=/workspace \
ghcr.io/ansible/devtools-mcp-server:latest --stdioThe Ansible development tools MCP server is available as a Technology Preview. For the full setup guide, including Ansible Automation Platform MCP server configuration, see the MCP server documentation.
Beyond development: Using the Ansible MCP server in execution environments
The Ansible development tools MCP server covers the development side, but the Ansible ecosystem is also exploring MCP at runtime. The ansible.mcp collection (available as a Technology Preview) lets you invoke MCP servers directly from playbooks using native Ansible module syntax inside execution environments. That's a topic for another post, but the direction is worth noting: MCP is becoming an integration layer across the Ansible platform, from development through execution.
Additional resources
Ready to bring deterministic AI into your Ansible workflow? Enable ansible.mcpServer.enabled in your VS Code settings today to try the Technology Preview and transform your AI assistant from a passive advisor into an active development tool.
- Solution guide: Complete technical walkthrough covering both Ansible development workspaces and MCP server configuration.
- Documentation: Create, test, and deploy automation content with Ansible development tools.
- Video: ansible-lint walkthrough
