CodeBadger defines 5 tools with reasonable naming and partial documentation. Tool names follow verb-first patterns (list_methods, list_calls, find_command_injection_sinks, supported_languages, codebase_overview). Descriptions vary in quality: some are comprehensive with examples and return schemas documented (list_methods, list_calls, find_command_injection_sinks), while others are minimal (supported_languages: 'Languages and recommended workflow supported by CodeBadger.', only 64 chars, under the 194-char baseline). Input schemas are present for all tools and include type definitions and parameter descriptions, meeting JSON Schema standards. However, critical gaps exist: (1) output schemas are described in prose within tool descriptions but not formally documented as response types in the MCP tool registration; (2) error handling is absent, no guidance on retryability, user-fixable errors, or recovery actions; (3) some parameter descriptions lack format constraints and allowed value ranges (e.g., 'page' and 'page_size' in list_methods have no documented bounds, inviting invalid LLM input); (4) the composition of tools is sound (each does one thing), but discovery workflows are not well-supported (supported_languages and codebase_overview lack clear descriptions of when/why to call them); (5) security aspects are not documented (no permission declarations, no audit trail guidance). Overall, the server demonstrates competent baseline engineering but lacks the polish required for production LLM interaction.

• Expand descriptions for supported_languages and codebase_overview to 100+ characters. State WHAT they reveal, WHEN to call them, and how they guide subsequent tool selections. Example: 'supported_languages should be called first to determine which programming languages your codebase contains; this filters applicable analysis tools and narrows sink searches.'
• Document formal response schemas as optional MCP response_schema fields (if supported by fastmcp), or add a 'Response Schema' subsection to each tool description in a structured format like: 'Returns: {success: boolean, methods: Array<{name: string, filename: string, lineNumber: number, ...}>}'
• Add explicit constraints to pagination parameters: 'page (integer, ≥1): Page number, defaults to 1'; 'page_size (integer, 1-100, default 20): Results per page'; 'limit (integer, 1-10000): Maximum results available for pagination'
• Add error handling guidance to each tool description. Example for list_methods: 'On invalid codebase_hash, returns {success: false, error: "hash not found"}. Verify the hash via generate_cpg or codebase_overview. On regex error, returns {success: false, error: "invalid regex pattern"}. Use standard POSIX regex syntax.'
• Declare required permissions (e.g., 'read:codebase' for all tools). Add to description or a separate metadata field if MCP framework supports it.
• For list_methods and list_calls, clarify pagination UX: 'If truncated=true and returned < limit, call again with page+1 to fetch next batch. If total < result_cap, all results are available; if total >= result_cap, the exact total is unbounded and should be treated as 'many'.'

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry