Loading ToolBench
MCP Server for Ansible Automation Platform (AAP), Event-Driven Ansible (EDA), and Red Hat Documentation
This server has fundamental definition quality gaps that would prevent confident production deployment. While 9 tools are present with basic schemas, most descriptions are terse (under 20 chars or incomplete), many parameters lack descriptions entirely, output schemas are not documented, and error handling is minimal. The server prioritizes functional integration with Ansible Automation Platform over LLM-optimized tool contracts. Naming follows verb_noun patterns reasonably well, but descriptions fail to guide LLM selection or explain prerequisites, dependencies, or side effects. No tool annotations (readOnly, destructive) are present despite several tools being write operations. Parameter schemas exist but lack sufficient inline guidance for LLMs.
Get details of a specific inventory by ID.
Return the Template ID for a given job template name.
Give a LLM prompt for solving the event triggerred This function retrieves the stdout from an Ansible job and parses it to find the 'TASK [Show the LLM response text]' section, extracting the 'msg' value.
Return the most recent job id for the Lightspeed Prompt job template.
List the most recent Event.
List all inventories in Ansible Automation Platform.
Descriptions too short and missing selection context. Examples: 'Return the most recent job id for the Lightspeed Prompt job template' (9 words, lacks WHEN/WHY context) and 'List the most recent Event' (5 words, no explanation of what data is returned or when to call it). LLMs cannot distinguish this tool from similar discovery tools without richer guidance.
No output schemas documented. Tools return complex objects (job data, inventory details, YAML playbooks) but consumers cannot predict which fields to extract or pass downstream. This forces LLMs to parse unstructured responses and risks broken chaining.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 20 | - | v1 |
Run a job template by name, optionally with extra_vars.
Run the Lightspeed job template by ID, wait for it to finish, and then give the generated Playbook from the job stdout output (full debug logic included).
Run Remediation Workflow with extra_vars.
Write operations (run_workflow, run_lightspeed_job_and_get_yaml, run_job) lack tool annotations (destructiveHint=true, idempotentHint=false). LLMs cannot distinguish safe from unsafe tools and will retry destructive operations on failure, causing duplicate executions.
Parameter descriptions are sparse or missing. 'extra_vars' parameter in run_workflow and run_lightspeed_job_and_get_yaml has only 'Extra variables for workflow execution', no guidance on structure, valid keys, or format. 'name' parameter in get_job_template_id lacks examples or constraints.
No error handling guidance. Functions like get_recent_prompt_job_id raise ValueError with generic messages ('Could not retrieve recent Lightspeed Prompt job ID') that give LLMs no recovery path. Missing guidance on retryability, user-fixable vs fatal errors, or alternative tools to try.
List tools (list_events, list_inventories) have no pagination support. No limit parameter, no offset/cursor, no total count in schema. Large result sets will blow context windows and degrade reasoning.
Parameter naming ambiguity. 'extra_vars' in three tools is a bare dict with no schema for valid keys, is it Ansible var names? AAP group_vars? No guidance. 'name' parameter in get_job_template_id and run_job does not specify case sensitivity, exact vs fuzzy match, or handling of names with special characters.
No dependency or prerequisite documentation. run_lightspeed_job_and_get_yaml needs a template_id but the description does not suggest calling get_job_template_id first if the user only has a name. Missing guidance on how to compose these tools.