Loading ToolBench
Ansible Tower MCP Server for Agentic AI - provides tools for managing Ansible Tower resources including inventories, hosts, groups, job templates, jobs, projects, credentials, organizations, teams, users, ad hoc commands, workflow templates, workflow jobs, schedules, and system operations.
Critical structural failures across all 15 tools. All tools use a generic action-dispatch pattern with free-form JSON parameters, eliminating per-action schema validation. Tool names lack action verbs (e.g., 'ansible_tower_inventory' instead of 'list_inventories' or 'create_inventory'). Descriptions are boilerplate and reference internal concepts ('CONCEPT:AT-OS.config.route-workflow-templates-operations') rather than explaining user intent. The 'params_json' parameter accepts arbitrary JSON with no schema, type validation, or format guidance, LLMs cannot determine valid inputs. Error handling is minimal ('return {"error": "Operation failed"}' with no recovery guidance). No output schemas documented. No pagination support visible. All 15 tools are functionally identical wrappers around a client dispatch mechanism, violating the single-responsibility principle.
Manage ansible tower ad hoc commands operations.
Manage ansible tower credentials operations.
Manage ansible tower groups operations. CONCEPT:AT-OS.config.route-workflow-templates-operations: Route group operations to standard API client methods.
Manage ansible tower hosts operations. CONCEPT:AT-OS.config.route-workflow-templates-operations: Route host operations to standard API client methods.
Manage ansible tower inventory operations. CONCEPT:AT-OS.config.route-workflow-templates-operations: Route inventory operations to standard API client methods.
Manage ansible tower job templates operations. CONCEPT:AT-OS.config.route-workflow-templates-operations: Route job templates operations to standard API client methods.
Generic action-dispatch pattern eliminates per-action schema validation. All 15 tools accept 'action' (string enum) + 'params_json' (free-form JSON). LLMs cannot validate inputs before calling; invalid JSON or unknown actions fail at runtime with no recovery guidance.
Tool names lack action verbs. 'ansible_tower_inventory' does not indicate whether it lists, creates, updates, or deletes. LLMs cannot infer intent from the name alone and must read descriptions (which are boilerplate). Violates verb_noun naming convention.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 31 | <=2025-11-25 | v2 |
Manage ansible tower jobs operations. CONCEPT:AT-OS.config.route-workflow-templates-operations: Route jobs operations to standard API client methods.
Manage ansible tower organizations operations.
Manage ansible tower projects operations. CONCEPT:AT-OS.config.route-workflow-templates-operations: Route projects operations to standard API client methods.
Manage ansible tower schedules operations.
Manage ansible tower system operations.
Manage ansible tower teams operations.
Manage ansible tower users operations.
Manage ansible tower workflow jobs operations.
Manage ansible tower workflow templates operations.
Descriptions are boilerplate and reference internal concepts ('CONCEPT:AT-OS.config.route-workflow-templates-operations') instead of explaining user intent. No guidance on when to use each tool, what it returns, or how to recover from errors. Descriptions fail to meet 10 - 1024 character guideline with meaningful content.
No output schemas documented. LLMs cannot plan downstream tool calls or extract required fields (e.g., inventory_id for chaining). Responses are opaque to the agent.
Error handling is minimal and non-actionable. Generic 'Operation failed' response with no indication of what went wrong, whether to retry, or how to recover. No error classification (retryable vs. fatal).