Loading ToolBench
Enhanced AI Expert Workflow MCP Server with structured conversation flow, topic tracking, and optional Task Master integration
This MCP server exposes 2 tools with reasonable names but suffers from significant gaps in schema documentation, parameter descriptions, and error handling. Tool names follow verb_object pattern (consultWithExpert, generateDocument) which is positive. However, input schemas are present in the problem statement but NOT verifiable in the provided source code excerpt, the src/index.ts file is truncated mid-initialization. The expert workflow concept is sound, but the implementation lacks critical production patterns: no output schemas are documented, parameters lack validation constraints, descriptions are generic, and there is no error recovery guidance. The server appears to integrate with OpenRouter API for LLM calls (via consultWithExpert and generateExpertDocument utility functions), but the actual tool implementation details, error handling, and response shaping are not visible in the truncated source.
Consult with an expert (product manager, UX designer, or software architect) on a specific topic
Generate a comprehensive document (PRD, UX Design Document, or Software Specification) based on expert consultation
Input schemas present in rubric specification but NOT verified in source code. src/index.ts is truncated and does not show explicit tool registration with schemas. Per HARD SCORING RULES, if tool definition is inferred rather than directly visible, cap at 50.
No output schemas documented. Tools return responses but the structure LLMs should expect is not defined. According to baseline D (SCHEMAS & OUTPUT), 100% of A+ tools have documented return types. Missing output schemas force LLMs to guess the response shape, risking parsing failures and wasted token usage.
Parameter descriptions are minimal and lack actionable constraints. 'The user's question or input for the expert' does not specify format, length limits, or character restrictions. Example: 'A detailed question (1-500 chars) for the selected expert type.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 35 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 27 | - | v1 |
No enum constraints on expertType parameter. Both tools accept 'productManager', 'uxDesigner', 'softwareArchitect' but these are documented in descriptions, not declared as enums in the schema. Per pattern:constrained-input, free-form strings invite hallucinated values. Schema should declare enum: ['productManager', 'uxDesigner', 'softwareArchitect'].
Tool descriptions under 20 characters are too short to guide LLM selection. 'Consult with an expert (product manager, UX designer, or software architect) on a specific topic' is ~98 chars (acceptable), but does not answer: When should I use this vs generateDocument? What does it return?
No error handling guidance. Tools are marked as READ_ONLY and WRITE risk levels, but there is no documented error classification (retryable, user-fixable, fatal) or recovery suggestions. Per pattern:recovery-guide, errors must tell the LLM what to do next. Missing: timeout handling, API failure recovery, invalid expert type feedback.
generateDocument has a boolean 'saveForTaskMaster' parameter with minimal description. No guidance on what Task Master format means, when to use it, or what side effects occur. Should clarify: 'Save output in Task Master compatible JSON format (default: false). Use when integrating with Task Master workflow automation.'
No confirmation or dry-run pattern for WRITE operations. generateDocument modifies state (writes document files) with no safety gate. Per pattern:confirmation-request, irreversible operations should support confirmation. Agents make mistakes, missing dry-run increases risk of unintended file creation.
OPENROUTER_API_KEY exposed as environment variable injected at runtime. While not a parameter (correct), the error handling in src/index.ts checks 'if (!process.env.OPENROUTER_API_KEY)' but does not handle missing key gracefully. Should fail fast with clear error message. Per pattern:secret-injection, never expose credentials in logs.
No idempotency guarantee documented. generateDocument may create duplicate files on retry if the same projectDescription is passed twice. Per pattern:idempotent-operation, tools must either be idempotent or clearly document when they are not, so agents know whether retry is safe.