Loading ToolBench
MCP server for ScuttlePay - a platform for managing crypto payments, wallets, and merchant transactions
ScuttlePay MCP server has 6 tools with mixed quality. Tool naming follows verb_noun conventions (list_, search_, get_, buy_) which is good. However, descriptions are inconsistent in depth and detail. Most parameters have type definitions and basic descriptions, but several critical gaps exist: the 'buy' tool lacks output schema documentation, error handling guidance is minimal, and parameter constraints (e.g., limits, formats, required fields for address object) are either missing or vague. The server demonstrates basic structure but lacks the LLM-optimized descriptions (50-200 chars) and comprehensive parameter documentation expected of production-grade tools. No visible schema for the shipping address object in 'buy' tool. Overall, this is a fair but incomplete implementation, most tools are under-documented for LLM reasoning.
Purchase a product from a merchant
Get the balance of a wallet
Get details for a specific product by ID
Get transaction history for a wallet
List all active merchants
Search products from a merchant's storefront
buy tool lacks output schema documentation. No visible documentation of what fields the response contains (order_id, transaction_id, status, etc.). LLM cannot infer success conditions or extract needed IDs for follow-up operations.
shipping address parameter in 'buy' tool is declared as type 'object' with description 'Shipping address details' but has no schema for the nested fields (street, city, state, zip, country, etc.). LLM cannot construct valid payload.
No error handling guidance in any tool. Error responses must tell LLM what to do next (e.g., 'Merchant not found. Try list_merchants() first'). Currently missing for all tools.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 11 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 46 | - | v1 |
buy tool description (Execute a purchase transaction) is too generic. Does not state prerequisites (is inventory checked? is payment required upfront?), does not clarify what happens on failure (partial order), and does not explain when to use vs alternatives. Should be 50-200 chars with WHAT, WHEN, and dependencies.
list_merchants has no parameters but description does not explain pagination, filtering, or how many results to expect. Does it return all merchants? How many? Undocumented.
variantId and other product parameters in 'buy' tool lack examples or format guidance. LLM cannot infer what valid values look like (UUID? string slug? integer?). Needs format constraint in description.
get_balance and get_transactions accept walletId parameter but no guidance on format (is it a hex address? a user UUID? an account name?). LLM must guess.
search_products and get_transactions have limit parameters capped at 50 and 100 respectively, but descriptions do not explain why these limits exist or what happens if the user needs more results (must use pagination). Pagination hint missing.
buy tool is marked IRREVERSIBLE but no confirmation step, dry-run option, or undo mechanism documented. Agents will blindly execute purchases without review.