This MCP server exhibits critical definition quality gaps across nearly all 45 tools. Evidence: (1) Tool definitions are inferred from test files (malong/tests/test-tool-registry.js) rather than explicitly visible in registration code, tools like 'read_symbol', 'write_symbol', 'edit_batch' have descriptions and Risk labels listed in test assertions, but the actual tool schema definitions are not provided in the source snippet. Per HARD SCORING RULE, inferred tools cap at 50 per-tool. (2) Of the few tools with visible schemas (health, reindex, code_search, read_outline), most lack complete parameter descriptions. For example, 'health' shows only {'type':'object','properties':{'action':{'type':'string','description':'check action'}}}, vague parameter description ('check action' is not actionable). (3) No output schemas are documented anywhere in the provided source. The absence of documented return types violates baseline requirement: '100% of A+ tools have documented return types.' (4) 40+ tools listed with only brief one-line descriptions (e.g., 'Read symbol definitions and outlines from source files', 'Execute tests and analyze test results'), many fall below the 50-character minimum useful description length and fail to state WHAT, WHEN to use, and what it RETURNS. (5) No evidence of error handling patterns, recovery guidance, or actionable error messages. (6) Tool names use inconsistent verb patterns: some follow verb_noun (read_symbol, write_file), others are noun-heavy (repo_map, config_drift, workflow_closure). Names like 'sweep_dead_code' vs 'dead_code_sweeper' show inconsistency. (7) No parameter validation rules, enums, ranges, or defaults documented. For destructive tools like delete_files, execute_shell, git_operations, no dry-run or confirmation patterns are evident. (8) No evidence of IDs/references matching between tool outputs and inputs (e.g., does rename_symbol return a symbol_id that other tools accept?). (9) Security-critical tools (execute_shell, delete_files, git_operations) have no visible permission gates, scope declarations, or audit trail patterns.

• IMMEDIATE: Provide explicit tool registration code showing full input schemas (type, properties, required, description for each param) and documented output schemas (return type, field descriptions, example responses). Use JSON Schema with proper type definitions.
• IMMEDIATE: Expand descriptions to 100-200 characters. For each tool, answer: WHAT does it do? WHEN should the LLM call it? WHAT does it return? Example format: 'List all files in a directory. Use this after reindex to see the code structure. Returns array of {path, type, size, modified_at}.'
• HIGH: Add parameter constraints (enums, min/max, regex patterns, format) and document them in descriptions. Example: 'status (string, enum: open|in_progress|closed): The current ticket status. Defaults to open.'
• HIGH: Implement error handling pattern. Each tool should return structured errors with: (1) error category (retryable|user_fixable|fatal), (2) actionable message ('User not found. Try search_users() with a partial name.'), (3) invalid value if applicable.
• HIGH: Add permission gates and scope declarations to destructive tools. Examples: delete_files requires 'write:filesystem'; execute_shell requires 'write:shell'; git_operations requires 'write:vcs'. Gate execution with permission checks; return 403 if unauthorized.
• HIGH: Implement confirmation/dry-run pattern for irreversible operations. For delete_files, execute_shell, git_operations: add optional 'dry_run: boolean' parameter. When true, simulate the operation and return what would happen without executing.

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

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