The Airbroke MCP server exposes 12 tools for error tracking and project management via HTTP transport. However, the server has critical gaps in definition quality: tool descriptions are present but lack specificity for LLM optimization, parameter schemas are not visible in the provided source code, and error handling guidance is absent. The codebase shows tool definitions split across lib/mcp/tools/* files, but without access to the actual schema registrations, parameter definitions, and output structures, scores are capped conservatively. The server is HTTP-based (good transport), uses @modelcontextprotocol/server 2.0.0 (current), but the tool definitions themselves lack the rigor expected for production agent interaction.

• Audit lib/mcp/tools/*.ts files and explicitly document JSON Schema for every tool parameter. Minimum required: { type: string|number|boolean|object|array, description: '...', enum?: [...], minLength?: N, maxLength?: N, pattern?: '...' }. Tools must declare required fields and nested object schemas.
• Rewrite tool descriptions to follow the 50-200 char LLM-optimized format: '<VERB> <OBJECT> to <OUTCOME>. WHEN: <trigger>. RETURNS: <key fields>.' Example: 'Get error occurrence details by ID. WHEN: viewing a specific error event. RETURNS: error message, stack trace, context, timestamp.'
• For list_* tools, add explicit pagination parameters (limit: 1-100 default 20; offset or cursor: string). Document response format includes total_count or next_cursor.
• Add error recovery guidance to each tool description or a dedicated 'errors' schema field. Example: 'If project not found, call list_projects() to discover available project IDs.' Or return { status: 404, message: '...', suggestion: '...' }.
• Implement confirm_before_execute pattern for delete_project. Require explicit confirmation parameter or return a pending state that requires explicit approval before deletion completes.
• Rename 'search' tool to a specific name like 'search_errors', 'search_occurrences', or 'full_text_search' with clear documentation of what it searches and when to use vs list_* tools.
• Establish parameter naming conventions across all tools. Example: accept both user_id and user_email in tools that reference users; accept both project_id and project_name in tools that reference projects. Document the pattern in server README.