AI Coding MCP Server provides structured data for coding tasks including project context analysis, external knowledge retrieval, workflow management, and specification handling
Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
This server has significant structural issues affecting definition quality. Of 26 tools, only tools 1-21 have explicit schema visible in server.py; tools 22-26 (in main.py) are inferred from code snippets without visible registration or explicit schema binding. Many tools lack substantive descriptions: 'Health check endpoint' (tool 1) is under 20 chars; 'Get git status', 'Get CI status', etc. are minimally descriptive. Tools 22-26 have Chinese descriptions which, while detailed, create a UX problem for English-speaking LLM agents. Parameter schemas are present but inconsistent, some tools lack descriptions of parameters (e.g., tool 1 'health_check' has empty input). Several tools combine related concerns (e.g., 'tool_git_history' accepts optional file_path, author, since filters suggesting parameter entanglement). Error handling code in base_tool.py is present but no tool-specific recovery guidance is visible. The codebase shows good infrastructure (BaseTool abstraction, execution context, statistics tracking) but the actual tool definitions fall short of production grade. Conservative estimate reflects unverified tool registration for tools 22-26 and pervasive description deficiencies.
Tools 22-26 (analyze_codebase, generate_code, diagnose_error, generate_tests, generate_docs) exist in main.py but explicit registration and schema binding are not visible in provided source. Per hard scoring rules, tools inferred rather than explicitly registered must be capped at 50 overall.
Tool 'health_check' has description '"Health check endpoint."' (21 chars) which is marginally above the 20-char threshold but lacks context on what a successful response contains, what failure means, or when to call it. Descriptions should be 50-200 chars with clear intent.
Many tools have minimalist descriptions (30-40 chars): 'Get git status', 'Get CI status', 'List issues', 'Get PR summary', 'List specs', 'Get spec file content', 'Get git history', etc. These are procedurally correct but lack actionable context: When should an LLM use get_git_status vs get_git_history? What's the difference between tool_get_spec and tool_search_specs? What do they return? Per pattern:tool-description, descriptions must answer WHAT, WHEN, and WHAT it returns.
Recommendations
Rewrite all tool descriptions to 50 - 200 chars, explicitly answering: (1) What does this tool do? (2) When should an LLM use it instead of similar tools? (3) What does it return? Example: 'Get git_status → fetch HEAD commit, branch, uncommitted changes, untracked files. Use to understand current repo state before actions.' Current 'Get git status' is insufficient.
Translate tools 22-26 from Chinese to English. Standard MCP servers use English descriptions to avoid localization mismatches with LLM agents.
Document output schema for every tool. Add a 'Returns' section to each description: 'Returns object: {symbol_name: str, file_path: str, type: str, line_number: int, docstring: str | null}' so LLMs know what fields to expect.
Add pagination parameters (limit: 1 - 100, offset/cursor) to all list/search tools (tool_issue_list, tool_search_code_examples, tool_search_docs, tool_search_specs, tool_git_history, tool_git_branch_analysis). Cap default and max results (e.g., default=20, max=100) per pattern:paginated-result.
Verify tool registration in main.py for tools 22-26. If they are NOT explicitly registered with @mcp.tool() decorator or equivalent, move them into server.py or add explicit registration with full schema.
Add tool annotations (tool_annotations) to the server: mark read-only tools with readOnlyHint=true and write tools with destructiveHint=true. This helps agents understand side effects.
Enhance parameter descriptions to include constraints and formats. E.g., 'language (string, required): Programming language name, one of: python, javascript, java, cpp, go, rust. Defaults to python.', this prevents LLM hallucination of unsupported languages.
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Tools 22-26 use Chinese descriptions ('代码库深度分析工具', '智能代码生成工具', etc.), which is non-standard for MCP servers consumed by English-speaking LLM agents. This creates a UX/localization mismatch, LLMs will receive tool descriptions in Chinese but interact with English parameter names and return fields.
Tool 'health_check' has input schema {} (empty object), which is correct for a no-arg tool, but the description provides no information on success vs failure indicators or when an agent should call it.
No tool explicitly declares output schema or return value structure. Base code shows tools return ToolExecutionResult (success, data, error, execution_time, metadata), but actual data field content is undocumented for each tool. Per pattern:response-shaper, LLMs need documented output schemas to plan downstream calls and extract fields correctly.
No pagination parameters (limit, page, offset, cursor) visible on list/search tools (tool_issue_list, tool_search_code_examples, tool_search_docs, tool_search_specs, tool_git_history). Per pattern:paginated-result, list tools must accept pagination to avoid context explosion. Returning unbounded lists will exhaust agent context.
Error handling code in base_tool.py catches exceptions generically and returns ToolExecutionResult with error string, but no tool-specific error recovery guidance is visible. Per pattern:recovery-guide, error responses must guide the LLM: 'Try X instead' or 'This is retryable'.
Destructive/write tools (tool_create_spec, tool_scaffold_project, generate_code, generate_tests) lack visible confirmation or dry-run patterns. Per pattern:confirmation-request, irreversible operations should support a confirmation step or dry-run mode.
Add error recovery guidance to tool descriptions and error responses. E.g., 'If repo_path is invalid, call tool_git_status with a different path or ask the user for the correct path.' This guides agent recovery.
For write tools (tool_create_spec, tool_scaffold_project, generate_code, generate_tests, generate_docs), add a dry_run parameter (boolean, default=false) so agents can preview changes before committing. Per pattern:confirmation-request.
Document what happens when optional parameters are omitted. E.g., 'If library is omitted, search returns results across all libraries. If version is omitted, latest stable version is assumed.' This prevents ambiguity.
Add human-readable resource names in addition to IDs. E.g., tool_get_symbol_info should return {symbol_name, file_path, ...} not just {symbol_id, file_id, ...}. Per mxe:natural-identifiers, agents operate with names.
Ensure each tool's output includes IDs/references needed by downstream tools. E.g., if tool_issue_list returns issues, each issue must include issue_id, project_id, repo_url so downstream tools (e.g., tool_pr_summary) have what they need without extra lookups.