Loading ToolBench
An MCP server that implements a meta-prompting system enabling collaboration with multiple experts to tackle complex problems through coordinated expert consultation and solution verification
This server exhibits critical definition quality gaps across both tools. The tool naming lacks action verbs (ready_to_answer, expert_model are vague/ambiguous). Parameter descriptions are present but insufficient, the expert_model tool requires an 'output' parameter which is fundamentally flawed: it asks the user to provide the expert's answer upfront, defeating the purpose of calling an expert. Schema definitions exist but are incomplete: the 'output' parameter has no validation constraints, and there is no documented return schema structure. The ready_to_answer tool has an empty input schema ({}), which is correct for a parameterless tool, but the descriptions lack actionable guidance on when/why to call these tools vs alternatives. Error handling is absent, no guidance on what happens if sampling fails, no recovery strategies. The prompt definition is extensive but does not substitute for proper tool definition quality.
Use this tool to communicate with an expert.
Use this tool when you already obtained or verified the final solution with at least two independent experts and are ready to present your final answer.
expert_model has a fundamentally broken 'output' parameter: it requires the user/LLM to provide the expert's answer as input, rather than generating it. This violates the tool contract, tools should produce outputs, not accept them as inputs. This parameter should be removed entirely and the tool should return the expert's response.
Tool names lack action verbs. 'ready_to_answer' and 'expert_model' are ambiguous descriptors, not clear action names. Should be verbs like 'submit_final_answer', 'consult_expert', or 'request_expert_opinion'. LLMs rely on verb-noun naming to infer intent.
expert_model parameter descriptions are generic and lack constraint information. 'name' has no enum of available experts. 'instructions' has no guidance on format or length limits. 'iteration' has no explanation of how it affects behavior. These gaps force the LLM to guess at valid inputs.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 38 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 42 | - | v1 |
No documented return schemas. ready_to_answer returns a plain string with no structured format. expert_model returns a string with no documented structure. LLMs cannot plan downstream steps without knowing what fields to extract.
Error handling is absent. The expert_model tool catches a generic Exception when sampling fails ('Client doesn't support sampling') but provides no recovery guidance. LLMs cannot determine if they should retry, ask the user, or proceed differently.
No input validation or constraints on parameters. expert_model accepts arbitrary strings for 'name' and 'instructions' with no validation. 'iteration' is numeric but has no bounds checking (could be negative, zero, or absurdly large).
ready_to_answer provides no input validation and its description does not clarify its role. It is unclear whether this tool is a gate (blocks until verification complete) or merely a signal. The return message 'ask the user how they want you to present the final answer' is instruction text, not tool output.