Loading ToolBench
Unofficial MCP server for Telegram Wallet P2P market data analytics
Three tools with good naming (verb-noun pattern: get_p2p_ads, get_market_summary, get_best_price) and solid descriptions (120-180 chars each, above the 34-char minimum). All parameters have type definitions and descriptions. However, output schemas are not documented in the source code, only input schemas are visible. The tools accept appropriate enums for 'side' parameter. Error handling exists but is basic (API errors are caught and re-thrown; no recovery guidance provided to LLMs). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present. The server correctly identifies itself as UNOFFICIAL and clarifies the read-only risk profile, which is good for transparency. Schema completeness is moderate: input validation is reasonable, but return value documentation is missing, forcing LLMs to infer output structure.
Find the best available price for buying or selling crypto on the P2P market. Returns the top ad with the most favorable price. This is an UNOFFICIAL tool.
Get aggregated market analytics for a cryptocurrency/fiat pair including price statistics, payment method distribution, merchant levels, and trader metrics. This is an UNOFFICIAL tool.
Fetch active P2P market ads filtered by cryptocurrency, fiat currency, and trade side. Returns detailed ad data including price, quantity, payment methods, and trader info. This is an UNOFFICIAL tool — not affiliated with Telegram or Wallet.
Output schemas are not documented. The source code shows input schemas with Zod types, but return value structure for each tool is not specified. LLMs cannot predict what fields (price, quantity, merchant info, spread statistics, etc.) will be in the response, forcing them to reason inductively and risking misuse of returned data.
Error handling provides no recovery guidance. When the API returns a 4xx or 5xx error, the server throws a generic error message like 'API error 400: [InvalidParam] cryptoCurrency not supported'. The LLM receives no hint about what to try next (e.g., 'Try a different cryptocurrency code like USDT or BTC'). This violates the recovery-guide pattern.
No tool annotations. The tools are read-only (GET semantics, no side effects) but lack readOnlyHint: true annotations. This prevents clients from optimizing caching, replay, or concurrency strategies. All three tools are also idempotent (same input → same output), but this is not declared.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 44 | - | v1 |
Parameter 'pageSize' in get_p2p_ads lacks range constraints in the description. The schema comment states 'max: 50', but this is not reflected as a maxItems constraint or clearly stated in the parameter description. LLMs cannot reliably enforce this limit and may pass invalid values.
API key is stored in environment variable WALLET_P2P_API_KEY and accessed at startup. This is correct secret injection, but the server does not validate that the key is non-empty or present until runtime (via getApiKey() which calls process.exit(1) if missing). While this prevents accidental exposure in tool parameters, it could be documented more clearly in the tool descriptions (e.g., noting that the server requires authentication).