Loading ToolBench
Collection of MCP servers for MLB draft automation, including draft player selection, knowledge base search, team management, push notifications, and RAG search capabilities
Server has 9 tools with mixed quality. Most tools have descriptions (7/9), but descriptions are often generic or incomplete. Input schemas are present but lack proper type definitions and parameter descriptions in several cases. Tool naming is inconsistent: some follow verb_noun pattern (draft_specific_player, read_draft_player_pool_resource) but others are unclear (push, read_account_resource). No output schemas documented. Error handling is minimal, most tools return JSON strings without structured error guidance. The draft_specific_player tool shows detailed logging but lacks actionable error messages for LLM recovery.
Draft a player for a team (synchronous - waits for completion). This is the CRITICAL function that updates the draft history in PostgreSQL. When this completes successfully, the status endpoint should return "completed".
Get current roster status for a specific team. Shows filled positions and needed positions.
Send a push notification with this brief message
Get the roster for a team
Get available (undrafted) players for a draft (returns JSON string)
Get the full player pool for a draft (returns JSON string)
Inconsistent tool naming convention. Tools like 'read_draft_player_pool_resource', 'read_strategy_resource', 'read_account_resource' use 'read_*_resource' pattern which is vague. LLMs cannot distinguish between 'read_strategy_resource' (get team strategy) and 'read_account_resource' (get team roster) without reading full descriptions. Recommend: 'get_team_strategy', 'get_team_roster', 'get_team_needed_positions'.
Missing output schemas for all tools. Tool descriptions state what they return (e.g., 'returns JSON string') but do not document the structure of that JSON. LLMs cannot plan downstream calls or extract fields without knowing response structure. Example: draft_specific_player returns JSON but schema of {status, error, ...} is undocumented.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 42 | <=2025-11-25 | v2 |
Get the needed positions for a team
Get the strategy for a team
Search the MLB Draft Oracle knowledge base for relevant information. Args: query: The search query (e.g., "Bryce Harper recent performance", "top catchers 2025", "injury reports pitchers") top_k: Number of results to return (default: 5, max: 10) Returns: JSON string containing search results with relevance scores and content
Minimal parameter descriptions. Parameters like 'id', 'name', 'message' lack context. Example: 'push' tool has parameter 'message' with description 'A brief message to push', does not explain what 'push' means (notification? queue? broadcast?). Parameter descriptions should explain format, constraints, and purpose.
Error handling lacks recovery guidance. draft_specific_player logs errors to stderr but returns generic JSON error strings. LLMs receive 'Player not found' but no guidance on next steps (e.g., 'Call read_draft_player_pool_available_resource to see available players'). Errors should be actionable.
Tool 'push' has ambiguous naming and minimal description. Does not clarify what 'push' means (push notification? push to queue? push to database?). Verb is too generic. Recommend: 'send_notification', 'send_push_notification', or 'enqueue_message' depending on actual behavior.