Loading ToolBench
Multi-language MCP server with Go-based XBrain server providing stock analysis tools, prompts, and resources; plus Python FastMCP servers for Pokemon API and XNO API checking
This server has severe definition quality issues across nearly all dimensions. Of 7 tools, only 2 (hello_world, get_pokemon_info) have visible input schemas; the other 5 have empty input objects or no visible schema definition. Tool descriptions are present but generic and lack depth. No parameter descriptions exist for tools with parameters. Multiple tools have zero-parameter signatures despite performing complex operations (get_stock_recommend, create_tournament_squad, check_all_private_apis, count_private_api_status), making their intended behavior ambiguous. Error handling is minimal, handlers return generic error strings without guidance on recovery or next steps. No output schemas are documented. The codebase mixes two different frameworks (mcp-go in Go and fastmcp in Python) without clear architectural rationale, suggesting incomplete implementation or abandoned portions.
Login and check all private APIs.
Login and count OK/FAIL APIs.
Create a powerful squad of Pokémon for a tournament.
Get detailed info about a Pokémon by name.
Fetch stock recommendations from XNO Trading Map
Say hello to someone
List popular tournament-ready Pokémon.
Five tools (get_stock_recommend, create_tournament_squad, list_popular_pokemon, check_all_private_apis, count_private_api_status) declare empty input schemas ({}), making parameter requirements completely opaque to LLMs. This violates the foundational pattern:tool principle that all inputs must be documented.
No output schemas are documented for any tool. LLMs cannot plan downstream tool calls or extract fields without knowing what structure each tool returns. This violates pattern:tool requirement for documented return types (100% of A+ tools have these).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 41 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 29 | - | v1 |
Tool descriptions are generic and lack actionable context. 'Fetch stock recommendations from XNO Trading Map' and 'Login and check all private APIs' do not explain WHEN to use these tools, WHAT they return, or what prerequisites exist (e.g., credentials). Baseline for A+ tools is 194 chars average; these average ~60 chars with minimal substance.
Credentials (XNO_EMAIL, XNO_PASSWORD) are loaded from .env in mcp_server_test/xno.py but exposed to tools. If these are passed as parameters or logged, they violate pattern:secret-injection. Even if not passed as params, the architecture risks secrets in traces.
Error handling is minimal. GetStockRecommendHandler returns bare error strings like 'Failed to fetch stock data: <error>' without guidance on recovery. No distinction between retryable, user-fixable, or fatal errors. Baseline pattern:recovery-guide requires actionable next steps.
Schema format inconsistency. Go implementation (hello_world, get_stock_recommend) uses mcp-go's fluent API; Python implementations use FastMCP decorators. No consistent JSON Schema validation visible. Parameter 'name' in hello_world has type and description, but this is exception, most tools lack any schema.
Tool naming inconsistencies. 'check_all_private_apis' uses imperative verb but is read-only; 'count_private_api_status' is vague (count what? return format?). Baseline naming convention (verb_noun) is mostly followed but descriptions do not clarify intent. LLM may confuse 'check' and 'count' variants.