Loading ToolBench
MCP Server for 6-stage Thinking Protocol Framework
This MCP server defines 5 tools with explicit schemas and descriptions, but has significant quality gaps. All tools are registered with input schemas and basic descriptions, but most descriptions are vague or incomplete. The `thinking_execute_stage` tool has an overly broad 'data' parameter with all possible keys listed as optional properties rather than stage-specific required keys. Parameter descriptions are minimal or absent (e.g., the 'data' object description says 'check protocol documentation' instead of specifying constraints). Error handling is not visible in the provided code. The tool design violates the single-responsibility principle: `thinking_execute_stage` tries to handle 6 different stage types with different required fields in one generic tool, forcing the LLM to infer which keys apply to which stage. No output schemas are documented. The naming is verb-based (thinking_*) which is good, but the descriptions lack guidance on WHEN to use each tool vs alternatives, which breaks the intent-inference pattern.
Execute a specific stage of the thinking protocol. Stages must be executed in order: observe → analyze → root → act → validate → improve
Get the complete thinking protocol configuration including all stages and their required keys
Get current status of a thinking session including completed stages and next required stage
Start a new thinking protocol session for complex problem-solving. Returns a session ID to track progress through the 6 stages.
Validate if all stages have been completed correctly with all required keys filled
thinking_execute_stage has an overly permissive 'data' parameter schema. All possible keys (facts, signals, state, patterns, assumptions, context, primary_cause, supporting_factors, core_issue, main_action, alternatives_risks, execution_priority, success_metrics, failure_signs, evaluation_method, system_change, rules_sop, long_term_prevention) are listed as optional properties with no type or per-stage constraints. The description defers to 'protocol documentation' instead of specifying which keys are required per stage. This forces the LLM to guess which keys apply to which stage and violates the JSON Schema pattern of declaring required fields per object.
Output schemas are not documented for any tool. The descriptions state what the tools return (e.g., 'Returns a session ID') but there is no formal response schema showing structure, field types, or pagination. LLMs cannot reliably extract data or plan chained calls without knowing the exact response shape.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 53 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
The tool design violates single-responsibility principle. thinking_execute_stage accepts a 'stage' enum with 6 values (observe, analyze, root, act, validate, improve) and uses a single generic 'data' object for all. Stage-specific required keys are not enforced at the schema level. The protocol specifies different required keys per stage (observe needs facts/signals/state; analyze needs patterns/assumptions/context; etc.) but the schema treats all keys as optional. This forces the LLM to infer the stage-to-keys mapping instead of having it enforced by the schema.
Parameter descriptions are minimal or missing. The 'data' parameter in thinking_execute_stage says 'Stage data with required keys. Each stage has specific required keys - check protocol documentation.' This defers to external documentation instead of being self-contained. Parameters should specify format, constraints, and examples inline. Most other parameters have single-phrase descriptions (e.g., 'Session ID from thinking_start_session') that lack context on valid formats or constraints.
No error handling guidance visible in provided code. Error responses should tell the LLM what to do next (e.g., 'Session not found. Call thinking_start_session to create a new session'). Raw error codes or generic failures give the agent nothing actionable. The CallToolRequestSchema handler code is incomplete in the provided excerpt.
Tool descriptions lack intent-guidance. Descriptions state WHAT the tools do but not WHEN to use them or how they differ from similar tools. For example, thinking_get_status and thinking_validate_session both inspect a session, what's the difference? When should the LLM call each? The descriptions don't explain.
The 'data' parameter in thinking_execute_stage lists all 18 possible keys with type 'string' but provides no validation that the correct keys are present for the selected stage. The THINKING_PROTOCOL constant defines stage-specific required keys, but this is not reflected in the input schema. LLMs cannot validate against stage-specific constraints and may pass incomplete data.