Loading ToolBench
MCP server for Claude agents to execute USDC payments directly on the Base network via the Rosud API
Rosud MCP Server provides 4 well-defined payment tools with clear naming, comprehensive parameter descriptions, and structured schemas. Tool names follow verb_noun convention (create_payment, get_balance, list_payments, get_payment). All tools have descriptions in the 100-200 character range, appropriate for LLM selection. Input schemas are complete with type definitions and constraints. However, output schemas are not explicitly documented in the source, and error handling lacks actionable recovery guidance. Tool composition is sound, each performs a single responsibility. No security vulnerabilities detected (no secrets in params). The server targets a narrow, well-scoped domain (USDC payments), which reduces complexity but limits versatility.
Create a payment using USDC stablecoin. Use this when an AI agent needs to autonomously pay external services for API call fees, service charges, data purchases, etc. It is recommended to check the balance with get_balance before making a payment. Examples: 'Pay $5 for this API usage', 'Pay the AI service fee'
Query the current USDC balance. Use this to check the balance before making a payment, or to determine the agent's available funds. Examples: 'What is my balance?', 'How much can I pay?'
Query the status and details of a specific payment. Use this to check payment completion, track transactions, or review payment details. Examples: 'Was payment pay_xxx processed?', 'Check this payment for me'
Query recent payment history. Use this for checking payment records, tracking payments by status, or analyzing spending. Examples: 'Show me recent payments', 'Are there any failed payments?', 'How much did I spend today?'
Output schemas not documented. Tool responses are formatted as JSON strings via _format_result(), but the structure of payment, balance, and history objects is not declared in the tool definitions. LLMs cannot plan multi-step operations without knowing what fields to expect.
Error responses lack actionable recovery guidance. The _format_error() handler returns error messages (e.g. 'Payment API error [400] invalid_amount: Amount must be >= 0.01'), but does not guide the LLM on what to do next, e.g. 'Check balance with get_balance before retrying' or 'Try a different recipient address'.
No idempotency enforcement for create_payment. While the schema accepts an optional idempotency_key parameter, there is no visible server-side deduplication logic to guarantee idempotent retries. Payment creation is irreversible, duplicate charges are catastrophic.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 62 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 59 | - | v1 |
Pagination support incomplete. list_payments accepts limit and default=10 but does not explicitly document a cursor or offset mechanism for handling >100 results. The baseline rubric recommends returning a total_count or next_cursor when results may be paginated.
No confirmation step for irreversible operations. create_payment immediately charges USDC and cannot be undone by the LLM. A confirmation_required step or dry-run mode would prevent accidental overpayment.
Tool descriptions include literal example values in strings (e.g. 'pay_01HXXX...', 'merchant_123'). LLMs tend to reuse example values literally rather than adapting to actual data. Constraint-based definitions (regex patterns, enums) are more robust.