Loading ToolBench
An MCP server that orchestrates complex queries across multiple specialized agents (research, math, finance, analytics) using FastMCP
Server has 5 tools with basic descriptions but critical gaps in schema documentation, parameter clarity, and error handling. Tool names lack action verbs (orchestrator_main, research_agent, math_agent, audit_tool, finance_agent are descriptive but not verb-noun patterns). Descriptions exist but are generic and lack WHEN/WHY guidance. Input schemas visible but parameters lack type constraints and validation rules. No output schemas documented. Error handling returns raw exception strings instead of actionable recovery guidance. Session_id parameter appears in all tools but its purpose and lifecycle are undocumented. Mock data in finance_agent (random.uniform) signals incomplete implementation.
Specific Tool: Retrieves system logs and interaction history. Useful for 'show me what happened' queries.
Get stock market data. Input should be a ticker symbol (e.g., AAPL, TSLA).
Specific Tool: Solves Physics and Math problems. Input must be a mathematical expression (e.g., '5.972e24 / 2' or 'sin(pi/4)').
MASTER AGENT: Use this for complex or ambiguous queries. It automatically plans steps, decides whether to use research or math, and synthesizes the final answer.
Specific Tool: Performs RAG-based research. Use this when you ONLY need to search documentation or facts without any calculation or complex planning.
Tool names lack action verbs. Names like 'orchestrator_main', 'research_agent', 'math_agent' are descriptive but do not follow verb_noun pattern (get_, create_, search_, etc.). LLMs infer intent from verb-first names; these names obscure the action.
No output schemas documented. Tools return raw strings (str(result)) with no structure. LLMs cannot parse results or chain downstream calls. E.g., orchestrator_main returns a string but downstream tools may need structured fields like status, data, errors.
Error handling returns raw exception strings ('Research Error: {str(e)}') instead of actionable recovery guidance. LLMs cannot determine if error is retryable, user-fixable, or fatal. No error classification or next-step hints.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 41 | <=2025-11-25 | v2 |
session_id parameter present in all tools but undocumented. Purpose (tracking, audit, state management?) is unclear. Lifecycle and default behavior ('default' string) not explained. LLMs cannot reason about when to pass custom vs default session IDs.
finance_agent uses mock data (random.uniform(100, 500)) instead of real API. Descriptions claim 'Get stock market data' but implementation is a stub. Misleads users and agents about tool capability.