Loading ToolBench
This server has moderate structural issues that prevent higher scoring. All four tools are explicitly registered via @mcp.tool() decorator with descriptions and input schemas visible in bio_engine_server.py. However, descriptions are generic and lack actionable detail for LLM tool selection. Parameter descriptions are minimal. Output schemas are not documented, return types are inferred from code (Dict[str,Any]) but no structured schema is declared. Error handling is minimal: no error classification, no recovery guidance, no validation feedback. Tools 1-3 are read-only web search wrappers (low complexity), while tool 4 performs database writes with no transaction safety or confirmation pattern. STDIO-only transport prevents remote access and caps protocol readiness at 50, directly limiting the server's production applicability.
Generates diverse biological search queries based on problem keywords and an optional summary, then performs web searches to find distinct, initial related biological concepts/themes.
Performs a targeted web search for a specific biological concept/system and returns a Markdown formatted overview.
Researches the users problem description using web search to gather initial context, extract keywords, and provide relevant links
After research, the client should store their findings in a key-pair match style where it stores the topic as the key and the value is the findings stored as a JSONB. If key exists, it updates the value.
Output schemas are not documented. All tools return Dict[str,Any] with no structured schema declaration visible. LLMs cannot infer which fields to extract from responses, making downstream tool chaining error-prone.
Descriptions are generic and do not answer WHEN to use each tool or distinguish it from similar tools. E.g., tool_research_user_problem and tool_find_initial_bio_concepts both search the web but serve different phases; the distinction is not explicit in descriptions.
tool_store_finding performs database writes (WRITE risk) with no confirmation pattern, transaction safety, or explicit error recovery. Agents have no way to preview or confirm mutations before executing. No dry-run option.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
No error handling or recovery guidance in tool implementations. perform_search() catches exceptions and logs them but returns None. Agents receive no actionable error messages, e.g., 'API key invalid' or 'Search engine quota exceeded', only silence.
Parameters in tool_find_initial_bio_concepts accept only [str] for problem_keywords and Optional[str] for problem_summary, but descriptions do not specify constraints (e.g., max keywords, max summary length, required formats). Agents may pass invalid inputs without guidance.
tool_store_finding parameter 'finding_data' accepts type:object with no schema. Agents do not know what structure the database expects. Is it free-form? Are there required fields? Optional fields?
No pagination support in search tools. If perform_search returns many results, the full list is returned without limit. This risks context window exhaustion and LLM reasoning degradation.
API credentials (GOOGLE_API_KEY, SEARCH_ENGINE_ID, database credentials) are loaded from environment variables, which is correct. However, no evidence of validation or rate-limiting to prevent runaway agent calls.