The server defines 8 tools with partial schema information visible in the source code. All tools have names starting with action verbs (identify, index, search, get, analyze, find), which is good for LLM disambiguation. However, critical quality issues significantly reduce the score: (1) All tool descriptions are in Chinese, making them inaccessible to English-speaking LLMs and developers; (2) Parameter descriptions are minimal and inconsistent in language (mixing Chinese and English); (3) Output schemas are completely undocumented, no tool shows what it returns, forcing LLMs to guess at response structure; (4) No error handling guidance is provided; (5) No parameter constraints (enums, min/max, patterns) are defined; (6) The 'language' parameter appears in multiple tools but lacks validation or enumeration of supported languages. These omissions make it very difficult for LLMs to reliably use these tools in production.

• Translate all tool descriptions and parameter descriptions to English. Minimum 15-50 characters per description, clearly stating WHAT the tool does, WHEN to use it, and WHAT it returns. Example: 'Identify a code project by path. Returns project_id (string) and status (active|inactive). Use before indexing. Required if project is not yet indexed.'
• Document output schema for every tool using JSON Schema notation. Specify field names, types, and required fields. Example for search_code: 'Returns {results: [{file_path, line_number, code_snippet, match_score}], total_matches, next_cursor}'. This enables LLMs to plan downstream calls.
• Add enum constraints for the 'language' parameter. List all supported languages explicitly, e.g. 'language: enum [python, javascript, java, go, rust, cpp, c, csharp, ruby, php]'. Include a description: 'Programming language of the code. Determines which parser is used.'
• Add min/max constraints to numeric parameters. Example: 'limit: integer, minimum 1, maximum 100, default 10. Number of results to return per page. Limit enforced server-side to prevent timeout.'
• Add error guidance to tool descriptions. Example for index_project: 'On failure, returns error code and message. Common issues: (1) path not found → verify path exists; (2) unsupported file types → confirm .py, .js, etc. files present; (3) insufficient disk space → check /tmp. Retry after resolving.'
• Clarify parameter relationships. For search_code, add: 'If project_id is omitted, searches across all indexed projects. If provided, searches only that project. To find valid project IDs, call identify_project with a project path.'

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

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