Loading ToolBench
MCP server that manages RooCode rules for code generation, analyzing files and code patterns, and applying coding standards through an AI gateway
This MCP server has 10 tools with inconsistent quality. All tools have descriptions and registered schemas via Zod, but several critical gaps emerge: (1) Tool naming includes ambiguous verbs (apply_rule, process_message, ai_gateway are unclear about what they do or when to use them vs similar tools). (2) Parameter descriptions are minimal or missing context on constraints and relationships. (3) Output schemas are completely undocumented, responses are generic text strings with no structured field definitions, forcing LLMs to parse unstructured text. (4) No input validation guidance, no enums for constrained parameters, no pagination support for list tools. (5) Error handling returns bare error messages without recovery guidance. (6) Overly broad catch-all tools (ai_gateway, ai_gateway_handler) combine multiple responsibilities. (7) No distinction between similar tools (e.g., apply_rule vs apply_rules). The codebase shows effort but lacks the rigor expected of production-grade agent tools.
Execute AI gateway actions including file operations, rule management, project file listing, and conversation processing
Process multiple AI gateway inputs with various actions (file operations, rule management, code analysis) in batch
Analyze code from a file within a conversation context, sending code content to the AI service for analysis
Analyze a file (documentation, guides, or standards) to extract coding rules in structured JSON format
Apply a coding rule to the workspace or global scope with specified language, description, and rule content
Apply multiple rules to the workspace or global scope in batch
Output schemas completely undocumented. All tools return generic `{ content: [{ type: 'text', text: result }] }` with no structured field definitions. LLMs must parse free-form text, wasting tokens and inviting misinterpretation.
Ambiguous tool naming: 'process_message', 'ai_gateway', and 'ai_gateway_handler' lack clear action verbs. 'process_message' could mean send, store, analyze, or moderate. 'ai_gateway' is a system component name, not a user action. LLMs cannot distinguish when to call which.
Duplicate/overlapping responsibilities: 'apply_rule' and 'apply_rules' do nearly the same thing (singular vs batch). 'ai_gateway' and 'ai_gateway_handler' both invoke the AI backend. 'list_rules' and 'list_rules_db' both list rules from different sources. LLM reasoning is wasted on choosing between near-duplicates.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 45 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 32 | - | v1 |
Delete a rule from the filesystem by rule file name and scope
List all rules from the filesystem across global and workspace scopes
List rules from the PostgreSQL database filtered by level (1-3), with optional scope and language filters
Process a message within a conversation, updating conversation history and interacting with the AI gateway
Parameter descriptions lack constraint and relationship documentation. E.g., 'scope' parameter in apply_rule accepts 'global', 'workspace', or 'mode-<name>' but description does not specify format. 'language' parameter has no enum and no documented valid values (js, html, css, general, inferred from description only).
No pagination support on list tools. 'list_rules', 'list_rules_db' accept no offset, limit, or cursor parameters. If a workspace has hundreds of rules, a single call returns all at once, potentially exhausting context.
Error handling is generic. All tools return isError: true with a text message, but no guidance on what the LLM should do next. Should it retry? Ask the user? Or is this unrecoverable? E.g., 'Error applying rule: ENOENT' tells the agent nothing actionable.
'ai_gateway_handler' accepts an 'inputs' array with wildcard object schemas: rules, project_meta, and additional_context are `z.object({}).passthrough()`. No validation of what goes inside. This defeats schema safety and makes the tool self-documenting impossible.
No input validation or constraint documentation. 'rule_name' and 'ruleFile' parameters have no length limits, character restrictions, or format specifications. 'conversation_id' is a string with no documented format. LLMs can pass arbitrary values that may fail inside the tool.
No recovery guidance for destructive operations. 'delete_rule' has risk=DESTRUCTIVE but no confirmation step, no dry-run mode, and error message 'Rule deleted successfully' offers no undo path if deletion was a mistake.
'ai_gateway' description lists 10 actions but provides no guidance on when to use which. The parameter 'action' is a free-form string with no enum. LLM must guess valid action names from the description text.