Five tools with basic schemas and descriptions, but significant gaps in parameter documentation and output schema clarity. Tool names follow verb_noun convention (scan_, audit_, explain_, generate_, list_) which is good. However, descriptions are terse (10-50 chars), parameter descriptions are minimal or absent, and output schemas are not formally documented. No error handling guidance. All tools are READ_ONLY which is safe, but the server lacks sophistication in composition and chaining support.

• Expand tool descriptions to 100-200 chars. For scan_agent_stack: 'Scan the workspace for MCP server configurations across Claude Desktop, Cursor, VSCode, and Roo. Returns discovered servers and their locations. Use this first to see what's installed; use audit_agent_stack to run validation checks.'
• Document output schemas explicitly. E.g., scan_agent_stack returns {servers: [{id, name, type, path, config}], errors: [{path, message}], summary: {total, valid, invalid}}. Include this in the tool description or as a separate schema annotation.
• Attach parameter descriptions to the FastMCP schema. Use @mcp.tool() with explicit parameter metadata or update the schema after registration to include descriptions for root_path, rule_id, server_id, and client.
• Add error recovery guidance. When explain_finding returns {'found': False}, append 'Available rule IDs: APD001, APD002, ... Call list_rules() to see all.' When generate_client_config fails, suggest 'Call list_supported_clients() to see valid options.'
• Constrain the 'client' parameter to an enum in generate_client_config. Extract SUPPORTED_CLIENTS keys and declare them as allowed values in the schema, not just in the description.