Loading ToolBench
A scalable MCP (Model Context Protocol) tool framework to serve thousands of biomedical tools for Large Language Models.
The Rhea MCP server exposes only one tool, 'find_tools', with a minimal schema and generic description. The tool name lacks an action verb and is ambiguous about what 'find' means in this context. The description (71 characters) is present but does not explain WHEN to call this tool, WHAT it returns, or HOW it populates tools. The input schema is present but lacks any constraints, examples, or validation guidance. The tool appears designed as a discovery/meta-tool rather than a concrete action tool, which is conceptually unusual for an MCP server, most servers expose domain-specific tools (e.g., search_biomedical_tools, list_available_tools) rather than a generic discovery mechanism. The output schema is not documented in the source. Error handling is not visible. The server's transport is HTTP/Streamable-HTTP (good), but the tool definition quality is significantly below production baseline.
A tool that will find and populate relevant tools given a query. Once called, the server will populate tools for you.
Tool name 'find_tools' lacks action verb clarity. 'find' is vague, does it search, discover, load, or register tools? Recommended names: 'search_tools', 'discover_available_tools', 'list_biomedical_tools', or 'populate_tool_registry'.
Description is 71 characters but lacks WHEN/WHY context. Does not explain: (1) What does 'populate tools' mean, are tools registered dynamically? (2) What query formats does the system accept? (3) What is returned, a list of tool IDs, full schemas, or metadata? (4) How many tools are in the registry? (5) Are results paginated? Current description: 'A tool that will find and populate relevant tools given a query. Once called, the server will populate tools for you.' This is circular and uninformative for LLM tool selection.
Input schema present but severely underdocumented. Parameter 'query' has a description ('Natural language query to find relevant tools') but lacks: (1) Min/max length constraints. (2) Examples of valid queries (e.g., 'protein alignment', 'phylogenetic analysis'). (3) What happens if the query matches zero tools? (4) Is query case-sensitive? (5) Does it support boolean operators or is it free-text semantic search? (6) Does it search tool names, descriptions, or both?
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 36 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 34 | 1.10.1+ | v1 |
Output schema is completely undocumented. The tool description says 'will populate relevant tools' but does not specify: (1) What structure is returned? (2) Is it a list of tool names, IDs, full schemas, or summaries? (3) How many tools are returned? (4) Is there pagination? (5) What fields does each result contain? (6) How should downstream tools (which presumably call the populated tools) reference them? Without documented output, LLMs cannot plan downstream tool chains.
Conceptual design risk: Rhea advertises as 'a scalable MCP framework to serve thousands of biomedical tools' but exposes only a meta-discovery tool ('find_tools'). The actual biomedical tools are not registered with the MCP server, only a dynamic discovery mechanism is exposed. This breaks the MCP contract: clients expect to call list_tools() and get a registry of concrete, documented tools. If tools are truly dynamic and loaded on-demand, this needs explicit MCP documentation (e.g., 'Use find_tools(query) to discover and load tools dynamically; then list_tools() will include them'). Current design leaves clients confused about how to discover and use the 'thousands' of biomedical tools.
No error handling guidance. What happens if: (1) query is empty or null? (2) query matches zero tools? (3) query is malformed or too long? (4) the tool registry service is unavailable? (5) the LLM provides a query in a language other than English? No documentation, no error codes, no recovery hints.