Loading ToolBench
MCP server that provides insightful feedback and guidance on various types of user requests
mentor-mcp-server provides 5 tools with clear naming conventions and present descriptions, but exhibits critical gaps in parameter documentation, schema completeness, and error handling guidance. Tools follow verb_noun naming (e.g. 'second_opinion', 'code_review'), which is good, but descriptions are minimal and parameter documentation is inconsistent. Most critically, parameters lack type information in descriptions, and error responses provide no recovery guidance. The code_review tool has oneOf schema structure which is valid but complex; others have simpler schemas. No tool annotations (readOnlyHint, destructiveHint) are present despite all tools declaring READ_ONLY risk. Error handling exists but is generic, catching McpError and InternalError without actionable guidance for LLMs. Output schemas are not documented in source code visible here. This server falls into the 'Fair' category with significant documentation and error-handling gaps.
Generates creative ideas for improving a given concept, product, or feature, focusing on innovation, feasibility, and user value.
Provides a code review for a given file or code snippet, focusing on potential bugs, style issues, performance bottlenecks, and security vulnerabilities.
Offers a critique of a design document, UI/UX mockup, or architectural diagram, focusing on usability, aesthetics, consistency, accessibility, and potential design flaws.
Provides a second opinion on a user's request by analyzing it with an LLM and listing critical considerations.
Provides feedback on a piece of writing, such as an essay, article, or technical documentation, focusing on clarity, grammar, style, structure, and overall effectiveness.
Parameter descriptions lack format specifications and constraint guidance. For example, 'file_path' in code_review has no specification for what format/relative vs absolute paths are accepted, or whether symlinks are followed. 'design_document' accepts either description OR URL but description does not clarify which or how URLs are validated.
No recovery guidance in error responses. The server catches errors and returns generic ErrorCode.InternalError with message 'Internal server error while executing tool X'. LLMs receive no actionable guidance on what went wrong or how to retry. Should include specific constraint violations (e.g. 'file_path must be readable; check permissions') and recovery steps.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 40 | - | v1 |
Tool annotations missing despite all tools being marked READ_ONLY. None of the tool definitions include readOnlyHint, destructiveHint, or idempotentHint in their registration. This prevents clients from optimizing caching and planning. All tools should declare readOnlyHint: true since they perform analysis without state modification.
Parameter descriptions for 'language' in code_review and 'writing_type' in writing_feedback do not enumerate valid values. Description says 'The programming language of the code' and 'The type of writing (e.g. essay, article, documentation)' but provides no enum constraint or list of supported languages/types. This forces LLMs to guess valid inputs.
Output schemas are not documented in visible source code. While the server converts responses via toolResponseToServerResult(), the expected return structure for each tool is not declared in tool definitions or in handler function signatures shown. LLMs cannot plan downstream operations without knowing what fields are returned.
Missing parameter descriptions. code_review's 'language' parameter lacks detail on what formats are accepted (e.g. 'javascript' vs 'JavaScript' vs 'js'). code_review's oneOf constraint is valid JSON Schema but the description does not explain the mutual exclusivity clearly to LLMs, description should state 'Provide either file_path OR code_snippet, not both.'
brainstorm_enhancements has a minimal description ('Generates creative ideas for improving a given concept, product, or feature, focusing on innovation, feasibility, and user value.') that lacks guidance on when to use it vs second_opinion. Both tools analyze requests, the distinction is unclear to LLMs. Description should clarify: second_opinion critiques a specific user request for correctness; brainstorm_enhancements generates alternative ideas for enhancement.