Loading ToolBench
MCP server for managing cryptocurrency data in Supabase database with CRUD operations
This server has 5 tools with basic schemas and descriptions, but falls short of production quality. Tool naming follows verb_noun convention well (get_, add_, update_, delete_), but descriptions lack depth on when to use each tool and what distinguishes them. Parameter descriptions exist but are minimal. No input validation guidance, no output schema documentation, and no error recovery hints. The server exposes database operations directly without pagination, result limits, or proper error classification. Critical issue: no protection against destructive operations (delete_cryptocurrency has no confirmation or dry-run pattern).
Adds a new cryptocurrency to the database. The 'last_updated' field is handled automatically by the database (as CURRENT_TIMESTAMP).
Deletes a cryptocurrency from the database by its symbol.
Retrieves all cryptocurrency records from the Supabase database. Returns a list of dictionaries, where each dictionary represents a cryptocurrency.
Retrieves a single cryptocurrency record by its symbol.
Updates the price of an existing cryptocurrency identified by its symbol.
No pagination or result limits. get_all_cryptocurrencies returns unbounded list, risking context window exhaustion and token waste.
Destructive tool (delete_cryptocurrency) lacks confirmation, dry-run, or undo capability. No recovery guidance in error responses.
No output schema documentation. Callers cannot know what fields to expect in responses, forcing guesswork for downstream tool chaining.
Error responses return raw exception strings (e.g., 'Error fetching data from Supabase: {e}') without actionable recovery hints or error classification (retryable vs. fatal).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 66 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 44 | - | v1 |
Tool descriptions lack context on when to use each tool vs. alternatives, and do not mention prerequisites or common failure modes.
Parameter 'symbol' is case-sensitive in user input but normalized to uppercase internally (symbol.upper()). No documentation of this transformation, LLMs may pass 'btc' and expect it back unchanged.
No input validation or constraint documentation. E.g., add_cryptocurrency requires 'price_in_usd' > 0, but this is not stated; price_in_usd could be negative without validation.