Loading ToolBench
MCP server for managing Roo custom modes. Handles creation, updating, deletion, and validation of mode configurations, with support for schema validation using Zod, file system watching for config changes, atomic file operations, and error handling with standard MCP error codes.
Modes MCP Server presents a moderately functional tool set with acceptable naming conventions and reasonable parameter schemas, but lacks critical error guidance, output documentation, and parameter validation details. All 6 tools are explicitly registered with input schemas visible in src/index.ts. Descriptions are present but generic (avg ~50 chars, below the 194-char baseline). Parameter descriptions exist but lack format constraints, valid ranges, and recovery hints. No output schemas are documented. Error handling uses standard MCP error codes but provides no actionable recovery guidance (pattern:recovery-guide violated). The groups parameter uses a complex union type that is well-defined in schema but poorly explained in natural language.
Create a new custom mode
Delete a custom mode
Get details of a specific mode
List all custom modes
Update an existing custom mode
Validate a mode configuration without saving it
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields (e.g., after create_mode, what fields are returned? What is the mode object structure?). Users will not know what data they receive.
Error handling provides no recovery guidance. When a mode creation fails (e.g., slug already exists, invalid regex in groups), the code throws McpError with a generic message but does not tell the LLM what to try next (pattern:recovery-guide). For example, 'Slug already exists' should suggest 'Use list_modes() to see existing slugs and pick a unique one.'
Destructive operation (delete_mode) lacks confirmation/dry-run safeguard. The tool deletes immediately with no chance for the agent to preview what will be deleted or confirm. Pattern:confirmation-request recommends a --dry-run or confirmation step for irreversible ops.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 65 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 48 | - | v1 |
Parameter 'slug' in create_mode and update_mode accepts free-form string with regex constraint in schema but no clear description of the format. The description says 'lowercase letters, numbers, and hyphens' but does not specify length bounds, starting/ending character rules, or reserved slugs. Leads to invalid attempts like 'Slug-Name' (capitals) or '--invalid' (leading dashes).
The 'groups' parameter in create_mode and update_mode has a complex oneOf union (string vs [string, object]) with fileRegex constraint, but natural-language description is minimal ('Array of allowed tool groups'). LLMs cannot infer that groups can be simple strings like 'read' OR tuples like ['edit', {fileRegex: '*.md', description: '...'}]. Needs clear examples in description.
Descriptions are too short (avg 50 chars; baseline is 194 chars). They lack context on WHEN to use the tool, its preconditions, and what it returns. E.g., 'List all custom modes' does not explain: What is returned in the list? Are modes paged? Can the agent chain list_modes into get_mode?
No parameter has type hints in natural-language description. E.g., slug parameter should state 'String, 1-50 characters, matching /^[a-z0-9-]+$/' in the description text. Zod enforces this in schema but LLMs may not parse JSON Schema pattern fields.
create_mode and update_mode lack guidance on mutually exclusive or dependent parameters. E.g., if groups=[string] vs groups=[[string, object]], when should each be used? When is customInstructions needed vs optional? Undocumented dependencies cause silent misuse (pattern:tool-description).