Loading ToolBench
MCP server for crypto portfolio using KuCoin + Notion
This server has 4 tools with basic definitions present, but significant quality gaps prevent it from scoring higher. All tools have descriptions (10-50 chars, short but present), and input schemas are partially defined for 2 of 4 tools. Tool naming follows verb_noun convention (health, get_balances, upsert_holdings, portfolio_report), which is good. However, parameter descriptions are absent or minimal, output schemas lack explicit documentation in the code, and error handling is missing guidance for LLMs. The definitions are adequate for basic understanding but fall short of production-grade quality expected in pattern:tool and pattern:tool-description.
Fetch KuCoin balances from both 'main' and 'trade' accounts. Requires KUCOIN_* env vars to be set inside the container.
Basic health check for the MCP server.
First-pass heuristic report (no USD prices yet): - Flags concentration - Notes dust - Checks stablecoin mix
Aggregate balances and write one row per (asset, account, date) to Notion.
Input parameter descriptions are missing or absent. Parameters like 'date_iso' in upsert_holdings have minimal guidance ('ISO date, e.g., 2025-09-25'), and tools like get_balances and portfolio_report have no input schema at all. LLMs cannot infer parameter meaning from names alone.
Output schemas are not explicitly documented in the code. While Pydantic models (HealthOut, GetBalancesOut, UpsertHoldingsOut, ReportOut) define return types, these are not attached to tool definitions with descriptions of what each field means. An LLM cannot understand what fields the response contains without reading Python code.
Error handling and recovery guidance are completely absent. Tools fail silently with exceptions (missing env vars, API errors, Notion DB errors) but do not return structured error messages or suggest next steps. An LLM encountering 'Missing required environment variable: KUCOIN_API_KEY' has no actionable recovery path.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 69 | 2026-07-28+ | v2 |
| 2026-03-09 | C | 60 | - | v1 |
No tool descriptions explain WHEN to use each tool instead of alternatives, or what prerequisites exist. For example, get_balances and portfolio_report both fetch balances but have different purposes, this distinction is not explained. A description of 'Fetch KuCoin balances from both main and trade accounts' alone does not guide LLM tool selection.
Tools handling side effects (upsert_holdings) lack confirmation or dry-run support. An agent could accidentally write incorrect portfolio data to Notion without any warning or undo mechanism. The 'note' parameter is nullable but the tool provides no way to validate the write before committing.
Tool descriptions are too brief (10 - 50 chars) and lack context on use cases, constraints, or dependencies. These descriptions fall at p10 and below, offering minimal guidance for LLM tool selection.