AAP Enterprise MCP Server has 40 tools with broad coverage of Ansible Automation Platform, Event-Driven Ansible, and Red Hat documentation. However, quality is inconsistent. Strengths: all 40 tools have descriptions and clear verb-prefixed names (lint_*, list_*, get_*, create_*, delete_*, etc.); parameter schemas are visible for most tools with type definitions and descriptions. Critical weaknesses: (1) parameter descriptions are generic and often lack constraints/formats ('Inventory description' is provided no guidance on length, format, or examples); (2) output schemas are completely undocumented, no tool states what fields it returns; (3) error handling is absent from descriptions, agents don't know how to recover from common failures; (4) many tools accept 'object' or 'array' with generic 'description' field, offering no guidance on structure (e.g., payload in create_activation is {'type':'object','description':'Activation payload'} with zero clarity on required/optional fields); (5) no tool descriptions mention prerequisites, side effects, or when to use one tool vs. a similar one; (6) security considerations (permissions, scope) are completely absent from tool descriptions; (7) list tools (list_inventories, list_jobs, etc.) lack pagination parameters, no indication they support limit/offset/cursor, risking context window exhaustion with large result sets.

• Add explicit output schemas to every tool description. Example: 'Returns: {"id": int, "name": string, "status": string, "created_at": ISO8601 datetime}'. Document every field the agent will encounter.
• Add pagination to all list_* tools: accept 'limit' (default 20, max 100) and 'offset' or 'cursor' parameters. Return 'total_count' and 'next_cursor' in responses so agents can iterate without exhausting context.
• Replace bare 'payload' and 'update_data' parameters with explicit, required field enumerations. For create_activation, specify the expected structure: '{"name": string (required), "description": string (optional), "enabled": boolean (default true), ...}'.
• Add error recovery guidance to tool descriptions. Example: 'On error: if 'Inventory not found', call list_inventories() to see available options; if 'Unauthorized', verify your AAP credentials; if timeout, retry up to 3 times with exponential backoff.'
• Implement a confirm_before_execute pattern for destructive tools (delete_*). Require a second parameter like 'confirm: bool = false' or provide a separate 'preview_deletion' tool that shows what will be deleted.
• Expand tool descriptions to 80 - 150 characters, clearly stating: (1) what the tool does, (2) when to use it vs. similar tools, (3) any prerequisites or side effects, (4) what it returns. Current descriptions like 'Disable an activation' lack context.
• Add constraint descriptions to all parameters. For numeric fields, specify range (e.g., 'hours: 1 - 24'). For enums, explain each option (e.g., 'profile: basic (checks syntax and common mistakes), moderate (adds best practices), production (strictest)').