Loading ToolBench
This server exposes OpenBB documentation as structured, callable tools through the Model Context Protocol. It provides documentation discovery and content fetching capabilities.
Server provides 2 tools with complete descriptions and reasonable parameter schemas. Both tools follow a logical discovery → fetch workflow. However, parameter descriptions lack specificity around constraints and formats, output schemas are not formally documented, and error handling guidance is minimal. Tool names use verbs (identify_, fetch_) which is good. Descriptions are verbose but provide context. The identify_ tool's description (337 chars) exceeds the recommended 10 - 200 char range for LLM parsing efficiency, though it does contain useful intent guidance. The fetch_ tool description (446 chars) similarly is overly long. Parameter descriptions exist but lack constraint details (e.g., 'list of exact section titles' does not specify max length, format, or validation rules). No output schema is documented despite verbose prose explanation in the fetch_ tool docstring.
Fetch specific documentation content from OpenBB docs based on section titles. You MUST call 'identify_openbb_docs_sections' first to obtain the exact section titles before calling this tool.
Identify the most relevant OpenBB documentation sections based on a user's query. This tool provides the COMPLETE table of contents from OpenBB documentation and expects the LLM to analyze it intelligently to select the most relevant sections.
Tool descriptions exceed recommended length (337 and 446 chars vs. 10 - 200 char baseline). While detailed, verbose descriptions waste LLM tokens and bury key selection criteria. Descriptions should concisely state WHAT, WHEN, and WHY, not provide lengthy instructions that belong in documentation.
Output schemas are not formally documented. fetch_openbb_content docstring describes return values in prose ('extracted_content', 'user_query', 'sections_found'), but no JSON Schema is provided. LLMs cannot validate or chain responses without explicit schema definitions.
Parameter descriptions lack constraint specifications. 'section_titles' is described as 'List of exact section titles' but does not specify max array length, max string length per title, character restrictions, or validation rules. 'user_query' lacks length constraints or format guidance.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 68 | <=2025-11-25 | v2 |
Error handling lacks recovery guidance. Server catches exceptions and logs them, but LLM receives only generic error responses. No guidance on retry eligibility, user-fixable vs. fatal errors, or next-step recommendations. E.g., 'Failed to fetch URL' should suggest 'Check internet connectivity and retry' or 'Contact support if problem persists.'
Tool descriptions contain procedural instructions meant for the LLM (6+ paragraphs in fetch_openbb_content), not concise tool-selection guidance. The 'RESPONSE GUIDELINES FOR THE LLM' section is meta-level direction about how to use the tool, not a tool description. This inflates token cost and obscures the core purpose.