Loading ToolBench
A multi-agent biomedical reasoning system with MCP servers for biomedical research tools, document processing, and knowledge retrieval. Provides interfaces for PubMed article search, clinical trial discovery, genetic variant analysis, and document-based Q&A.
The BioReasoning MCP server exhibits significant definition quality gaps typical of early-stage community implementations. The server defines 11 tools across two MCP servers (biomcp_server.py and docs_server.py), but most tools lack structured input validation and comprehensive parameter documentation. Tool naming follows basic conventions (get_, search_, list_) but descriptions are inconsistent in depth. Parameter schemas are visible and typed for most tools, but descriptions for individual parameters are often generic. The trial_searcher tool exemplifies the issues: 17 parameters with minimal individual documentation and no guidance on which are mutually exclusive or required. Output schemas are largely undocumented, tools return plain strings rather than structured objects, forcing LLMs to parse unstructured text. Error handling is minimal: most tools catch exceptions and return string representations rather than actionable recovery guidance. This falls squarely in the FAIR to POOR range (50 - 60).
Add two numbers.
Search PubMed articles using structured criteria.
Get details of a PubMed article.
This tool is useful to get a mind map.
Get details of a variant.
Return a friendly greeting.
List all available tools.
trial_searcher has 17 parameters with minimal individual parameter descriptions. No guidance on required vs optional, mutually exclusive constraints, or valid value ranges. This violates the parameter documentation requirement and forces LLMs to guess about parameter relationships.
All tools return plain string responses rather than structured JSON objects. This forces LLMs to parse unstructured text, is error-prone, wastes tokens on parsing logic, and prevents typed downstream tool composition. Example: get_article_details returns 'result.content[0].text' instead of {pmid: string, title: string, authors: [...], abstract: string}.
Output schemas are completely undocumented. Tool descriptions mention what they do but never specify what fields the response contains. LLMs cannot plan downstream tool chains or extract specific data without seeing the response structure first.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 51 | - | v1 |
This tool is useful to process files and produce summaries, question-answers and highlights.
Get knowledge from ingested documents in LlamaCloud index.
Subtract two numbers.
Search clinical trials using structured criteria.
Error handling returns generic exception messages (e.g., 'get_article_details: {e}') with no actionable recovery guidance. Exceptions are caught but not categorized as retryable, user-fixable, or fatal. This leaves agents unable to determine next steps on failure.
Tools named with generic suffixes like '_tool' (process_file_tool, get_mind_map_tool, query_index_tool) reduce clarity. The '_tool' suffix is redundant; rename to process_file, get_mind_map, query_index. Tool names should reflect the action and resource, not the fact that they are tools.
Many parameter descriptions are incomplete. Example: trial_searcher 'lat' param has description 'The latitude of the trial' but no units, valid range (e.g., -90 to 90), or guidance on when this is used (e.g., requires 'long' and 'distance'). Parameters like 'distance' lack units (km? miles?).
No pagination support visible. Tools like article_searcher and trial_searcher are likely to return large result sets but have no limit, page, offset, or cursor parameters. Without pagination, large results blow context windows.
process_file_tool description is vague: 'This tool is useful to process files and produce summaries, question-answers and highlights.' Does not clarify: which file types? What formats are accepted? What does 'process' entail? How are q&a generated? Description should be 50 - 200 chars and action-oriented.
Trial_searcher includes numeric parameters (lat, long, distance) with default values of 0.0. A default of 0.0 for latitude/longitude is a valid coordinate (equator, prime meridian) and will silently produce wrong results if not explicitly provided. Defaults must not cause data loss or silent failures.