Ansible Lint Operations
MCP Server
- Repository: sibilleb/AAP-Enterprise-MCP-Server
- Transport: stdio (Python via
uv run ansible-lint.py) - Install:
git clone+uv sync(orpip install -e .) - Requires:
ansible-lintinstalled
Available Tools (9)
| Tool | What It Does |
|---|---|
lint_playbook |
Lint playbook content with configurable profiles and output formats |
lint_file |
Lint a specific Ansible file at a given path |
lint_role |
Comprehensive linting of an Ansible role directory |
list_rules |
Display available ansible-lint rules with optional tag filtering |
list_tags |
Show all tags for categorizing lint rules |
validate_syntax |
Quick syntax validation using syntax-specific rules |
check_best_practices |
Evaluate content against best practices with severity categorization |
analyze_project |
Comprehensive report on an entire Ansible project structure |
get_ansible_lint_version |
Return installed ansible-lint version |
Key Concepts
| Concept | What It Means |
|---|---|
| Profile | Lint strictness level (min, basic, moderate, safety, shared, production) |
| Rule | Individual lint check (e.g., yaml[truthy], no-changed-when, fqcn) |
| Tag | Rule category for filtering (e.g., command-shell, formatting, idiom) |
| FQCN | Fully Qualified Collection Name — required in production profiles |
Workflow: Pre-Deployment Playbook Validation
- Syntax check:
validate_syntax— catch YAML and Ansible syntax errors - Best practices:
check_best_practices— evaluate against standards - Full lint:
lint_playbookwith production profile — comprehensive check - Review rules:
list_rules— understand which rules triggered violations - Report: Pass/fail with specific violations and remediation guidance
Workflow: Project-Wide Quality Audit
- Analyze project:
analyze_project— scan entire Ansible project structure - Review findings: Group violations by file, rule, and severity
- Check roles:
lint_rolefor each role directory - Report: Project quality scorecard with violation counts and trends
Integration with Other Skills
| Skill | How They Work Together |
|---|---|
aap-automation |
Validate playbooks before running them through AAP job templates |
aap-eda |
Lint rulebook playbook actions before EDA activation |
github-ops |
CI/CD lint checks on PR playbook changes |
gait-session-tracking |
Audit trail for lint results and quality gate decisions |
Important Rules
- Lint before deploy — always validate playbooks before AAP job execution
- Profile selection — use
productionprofile for production deployments,basicfor development - No credentials in playbooks — lint catches hardcoded secrets; use AAP credential management instead
Failure Behavior
- On a tool error (timeout, unreachable host, malformed response), report the failure and its error message directly to the user rather than fabricating or guessing at results.
- For a confirmed read-only call, check connectivity and retry once if appropriate. For any call that changes state or sends a message, a timeout does not prove the action failed: inspect current state or delivery status before retrying, preserve the required approval/change gates, and do not repeat an action whose outcome is unknown.
