Loading ToolBench
MCP server for sending physical mail via Solana payments. Integrates with Lob for mail printing and Solana blockchain for cryptocurrency payments. Supports multiple tiers with Stripe monetization.
Mixed quality across 5 tools. All tools have descriptions and basic schemas present, but many descriptions are vague or missing context. Parameter descriptions are sparse or generic. Tool naming is clear and verb-based. No tool annotations (readOnlyHint/destructiveHint) despite having both read-only and irreversible operations. Schemas are present but incomplete, missing required field specifications and constraint documentation in parameter descriptions. Error handling guidance is absent from all tool descriptions.
Get your SolMail account information including tier, usage, and limits
Get a price quote for sending physical mail. Returns price in USD and estimated SOL amount based on current exchange rates.
Get public address of configured wallet for funding
Check SOL wallet balance of the configured wallet
Send physical mail using Solana cryptocurrency. Composes a letter, creates a Solana payment transaction, and submits to SolMail for printing and mailing. Requires wallet configuration.
Irreversible operation (send_mail) lacks confirmation/dry-run pattern and recovery guidance. Description does not warn about non-idempotence or suggest error recovery paths.
Tool annotations missing for all tools. send_mail should have destructiveHint=true; get_* tools should have readOnlyHint=true. This prevents LLM planners from understanding operation safety.
Wallet-related tools (get_wallet_balance, get_wallet_address) have trivial descriptions ('Check SOL wallet balance...', 'Get public address...') that lack context about prerequisites, use cases, or when to call them.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 47 | 2024-11-25+ | v1 |
Parameter descriptions are minimal or absent. send_mail's 'recipient' parameter has a good nested object schema but 'mailOptions' properties (color, doubleSided, mailClass) lack individual descriptions explaining what they control. get_mail_quote's 'country' parameter lacks description of valid formats.
No error handling guidance in any tool description. Missing recovery instructions like 'If insufficient wallet balance, call get_wallet_balance() first' or 'Provide valid country codes (ISO 3166-1 alpha-2 format) to avoid rejection'.
get_mail_quote and send_mail descriptions do not explain dependencies. An LLM might call send_mail without first checking balance or quote. Descriptions should guide the multi-step workflow.
Wallet configuration is mentioned in send_mail description ('Requires wallet configuration') but no guidance on how to configure or what happens if missing.
Schema for send_mail shows nested recipient object with required fields [name, addressLine1, city, zipCode], but 'state' and 'country' are optional, no description of when they are required (e.g., country mandatory for non-US addresses).