Critical failures across all dimensions. Tool descriptions are in Chinese and extremely brief (3-10 chars), far below the 10-1024 char baseline. No input schemas visible in source code, only parameter names and types are inferred from the client code. Tool names lack action verbs (e.g., 'add', 'test_tool' are generic). Duplicate tool 'search_bing' suggests poor composition. High-risk tools (exec_js, execute_python_code, run_command) lack any error handling, confirmation, or dry-run patterns. No output schemas documented. No parameter descriptions beyond type hints. Security-critical tools expose arbitrary code execution without validation or audit trails.

• Add explicit, visible input schemas to all tool definitions in the server code. Each tool must register with JSON Schema including type, description, and constraints for every parameter. Example: {'type': 'object', 'properties': {'jscode': {'type': 'string', 'description': 'JavaScript code to execute (max 10KB, no eval() calls)'}}, 'required': ['jscode']}.
• Rewrite all descriptions in English, 50-200 characters, following LLM-optimized format: 'Executes JavaScript code in a sandboxed Node.js environment. Returns stdout, stderr, and exit code. Supports async/await. Max 10KB code size.'
• Implement confirmation-request pattern for irreversible tools: exec_js, execute_python_code, run_command should support a 'dry_run' parameter or return a confirmation token requiring explicit approval before execution.
• Add comprehensive error handling with recovery guidance. Example: 'SyntaxError in line 5: unexpected token. Check your JavaScript syntax and retry.' Include the invalid value and the constraint violated.
• Remove duplicate 'search_bing' tool. If two variants are needed (e.g., different result formats), rename to 'search_bing_web' and 'search_bing_news' with distinct descriptions explaining when to use each.

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

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