Loading ToolBench
Model Context Protocol server for the DRAIN payment protocol. Agents discover providers, open USDC payment channels on Polygon, and call any service — LLM, image generation, web scraping, VPN, and more. Pay per use, no API keys.
The DRAIN MCP server has 13 tools covering blockchain payments, provider discovery, and AI service orchestration. Tool definitions are present with names, descriptions, and parameter schemas. However, the server has significant quality gaps: (1) parameter descriptions are minimal or missing details about constraints, formats, and valid ranges; (2) output schemas are not documented in the source; (3) error handling and recovery guidance are not evident in the tool definitions; (4) descriptions are brief and lack context about when/why to use each tool or dependencies between tools. Tool names follow a consistent 'drain_*' or 'mpp_*' pattern with action verbs, which is good. The server manages blockchain transactions (approve, open_channel, close_channel, cooperative_close) and AI service calls (drain_chat, mpp_chat, mpp_request), creating a composition risk if errors mid-pipeline leave channels open or payments stranded. Per-tool analysis: most tools have 50-65 individual scores due to present-but-sparse documentation.
Approve USDC spending for the DRAIN contract
Check wallet USDC balance and allowance
Check channel status and balance
List all known channels with status
Send a paid request via DRAIN channel
Close expired channel and reclaim funds
Close channel immediately (provider co-signs)
Report quality feedback (success/failure)
Output schemas not documented in tool definitions. Users/LLMs cannot predict what fields to expect from tools like drain_balance, drain_providers, drain_channel_status, or drain_chat. This breaks downstream composition and forces agents to inspect responses blindly.
Parameter descriptions lack constraint details. 'amount' in drain_approve has no mention of USDC units, decimal precision, or minimum/maximum values. 'duration' in drain_open_channel is undescribed, does it accept seconds, days, a string format? 'messages' in drain_chat and mpp_chat are described as 'Chat messages with role and content' but lack field-level schema (role enum values? content string limits?). LLMs will guess at valid formats.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 47 | - | v1 |
Open a payment channel with a provider
Provider details + usage instructions (docs)
List service providers (filter by model, category, protocol)
Chat with MPP LLM provider (auto-pay via Tempo)
Call MPP REST API (auto-pay via Tempo)
No error handling or recovery guidance. Tools like drain_approve, drain_open_channel, drain_close_channel, and drain_chat perform blockchain transactions and LLM API calls. The tool definitions do not describe failure modes, which errors are retryable, or what the LLM should do if approval fails or a channel close times out. This is especially dangerous for financial operations.
No tool composition or dependency documentation. drain_chat requires a channelId, which must exist and have balance. drain_open_channel is a prerequisite. But the description of drain_chat does not mention 'first open a channel with drain_open_channel'. drain_cooperative_close requires provider co-signature, but this precondition is not stated. Agents will attempt invalid call sequences.
No pagination or result-limiting documented. drain_providers and drain_channels have no stated limit on result count. If a provider registry contains hundreds of entries, returning all of them could blow the context window. No mention of pagination parameters (limit, offset, cursor) or maximum result sizes.
mpp_request is overly generic. Described as 'Call MPP REST API (auto-pay via Tempo)' with body, method, and url as free-form inputs. No validation examples, no list of supported endpoints, no error handling. This invites LLMs to hallucinate API calls to non-existent endpoints or malformed URLs.
Tool names and parameter names are inconsistent with naming conventions. drain_cooperative_close uses 'cooperative' (adjective) instead of a verb. Parameter 'providerId' and 'provider' are interchangeable but not consistently documented, drain_open_channel accepts 'provider' (name or ID), but drain_provider_info accepts both 'provider' and 'providerId' as separate optional fields. LLMs will be confused about which to use.
Sensitive parameter handling unclear. drain_approve accepts an 'amount' parameter. USDC uses 6 decimal places on Polygon. No documentation of whether LLM should pass '1000000' (1 USDC in base units) or '1.0' (1 USDC as float). Misunderstanding could approve 1,000,000 USDC instead of 1 USDC, a financial disaster.