Loading ToolBench
MCP Server for tip.md - Payment-enabled agent supporting crypto tipping on Ethereum, Base, and Solana blockchains with x402 HTTP payment protocol integration
This MCP server has 8 tools with moderate definition quality. Most tools have descriptions (7/8), and all have visible input schemas with types. However, there are significant gaps: (1) Parameter descriptions are sparse, many parameters lack detailed context on format, constraints, or usage. (2) Output schemas are not explicitly documented in the visible code; responses are inferred from code comments or return types, not formal schema declarations. (3) Tool naming is inconsistent: 'check_tipping_balance', 'tip_on_base', 'tip_on_solana' mix verb_noun with domain-specific naming. (4) Error handling guidance is minimal, no recovery instructions or actionable next steps for LLMs. (5) Security-sensitive tools (export_tipping_wallet, withdraw_tipping_funds) lack explicit confirmation or dry-run patterns. Most tools land in the 45-55 range; the average is dragged down by missing parameter descriptions and lack of output schema documentation.
Check your tip.md tipping wallet balance and create a new wallet if needed. Returns structured JSON with wallet address, balance information, and new wallet credentials.
Provides details for crypto tipping a tip.md user via blockchain. Supporting Ethereum, Base and Solana.
Export your tipping wallet private key for full control (SECURITY SENSITIVE). Returns structured JSON with wallet data and security warnings. Requires your tip.md user ID. Base network only.
Retrieves a tip.md user's configured wallet types from the database.
Responds with pong, useful for health checks.
Send USDC tips on Base from your personal tip.md wallet using the x402 payment protocol. Returns structured JSON with transaction details. Pays from your dedicated wallet to recipient via x402 protocol and distributed using CDP Wallet API. IMPORTANT: When successful, always show the user the transaction hashes as clickable links using the format: https://basescan.org/tx/{transactionHash} for both recipient and platform transactions.
Output schemas not formally documented. Responses are inferred from code comments (e.g., 'Returns structured JSON with wallet address, balance information') but there is no explicit JSON Schema definition visible in the code showing what fields, types, and constraints the LLM can expect. This forces LLMs to reason about response structure and risks parsing errors.
Irreversible operations lack confirmation/dry-run pattern. Tools like 'export_tipping_wallet', 'tip_on_base', 'tip_on_solana', and 'withdraw_tipping_funds' perform destructive or value-transferring actions but have no confirm_before_execute or dry_run capability. Agents can make mistakes without recourse.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | 2026-07-28+ | v2 |
| 2026-04-07 | F | 15 | - | v1 |
Send USDC tips on Solana from your personal tip.md wallet using the x402 payment protocol. Returns structured JSON with transaction details. IMPORTANT: When successful, always show the user the transaction hashes as clickable links using the format: https://solscan.io/tx/{transactionHash} for both recipient and platform transactions.
Withdraw USDC from your tipping wallet to any Ethereum address. Returns structured JSON with transaction details. Requires your tip.md user ID. Base network only.
Parameter descriptions are incomplete or missing context. E.g., 'destinationAddress' in withdraw_tipping_funds says 'Ethereum address to send funds to' but does not specify format (must be checksummed? 0x prefix required?), constraints (length validation), or examples. 'amount' parameter description lacks clarity on units (decimal places, min/max bounds beyond the numeric minimum).
Error handling provides no recovery guidance. Code comments mention error responses but visible error handling in the tool definitions shows no actionable next steps (e.g., 'User not found. Try search_users() first.' or 'Insufficient balance. Withdraw funds or top up wallet.'). LLMs receive raw error codes or messages without context on what to do next.
'ping' tool is minimal and deprecated in modern MCP. Description is vague ('Responds with pong, useful for health checks'), under 50 characters with no actionable guidance. This tool should be removed or replaced with proper health/status endpoints in the server initialization.
No input validation guidance in parameter descriptions. E.g., username parameters have a regex pattern (^[a-zA-Z0-9_-]+$) visible in the schema, but the description does not explicitly state this constraint in natural language. LLMs cannot read JSON Schema patterns, they rely on text descriptions.
Security-sensitive operations expose private keys. 'export_tipping_wallet' returns a private key in the response, and 'check_tipping_balance' may include 'privateKey' in the returned data for new wallets. These should never be in response bodies, they enter LLM context and risk being logged or echoed to users. Use secure storage patterns instead.
Chaining field names are not guaranteed. E.g., 'tip_on_base' likely returns a transaction hash, but the response schema is not documented, a downstream tool or agent may not know the exact field name to extract. This breaks tool composition and forces extra discovery calls.