LCP server has well-structured tool definitions with consistent naming (verb_noun pattern: resolve_library, list_libraries, get_symbol, search_symbols, get_module_symbols, get_class_members, get_return_type, get_parameter_type). All 8 tools have descriptions (avg ~80 chars, within 10-1024 range). Input schemas are present with typed parameters and descriptions. However, output schemas are not documented in the visible code, LLMs cannot predict return structure. Parameter descriptions are adequate but lack format constraints (e.g., symbol_id format 'module:entity' is stated but not formalized as a pattern). No error handling guidance visible. All tools are READ_ONLY, which is good for safety but limits utility. Missing pagination/limit parameters on list-returning tools (list_libraries, search_symbols, get_module_symbols, get_class_members) despite DEFAULT_MAX_RESPONSE_BYTES constant suggesting truncation is expected.

• Document output schemas for all tools. Specify fields, types, and nesting. Example: 'Returns {symbols: [{id: string, kind: string, module: string, description: string}], total: number, truncated: boolean}'.
• Add limit and offset parameters to list_libraries, search_symbols, get_module_symbols, and get_class_members. Default limit=20, max=100. Return total_count and has_more flag to enable pagination.
• Enhance error descriptions: 'Symbol not found. Try search_symbols(query=<name>) to find available symbols.' 'Invalid symbol_id format. Use module:entity or module:Class#member.'
• Formalize symbol_id constraint as a regex pattern in schema: '^[a-zA-Z0-9_.]+:[a-zA-Z0-9_#]+$' and reference it in parameter description.
• Clarify library parameter behavior: 'If omitted and exactly one library is loaded, that library is used. If multiple libraries are loaded, library is required. Returns error if library not found.'