Loading ToolBench
MCP server for Setu — lets any AI agent hold a wallet, pay, and charge on the Setu settlement network. Zero dependencies.
setu-mcp demonstrates solid tool design with clear naming (verb_noun pattern), complete input schemas with type definitions, and good descriptions (avg 150 chars). All 8 tools have descriptions and properly typed parameters. However, output schemas are not formally documented, responses are free-text strings rather than structured objects. Parameter descriptions are present but minimal (avg 40 chars, below the 72-char baseline). Error handling is basic: tools return plain text success messages without recovery guidance or error categorization. No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications. Missing pagination for tools that could return large results (e.g., setu_network). Tool composition is sound, each tool has one responsibility and outputs reference IDs needed by downstream tools (e.g., setu_pay returns certificate for setu_verify_payment).
Get this agent's Setu wallet address (created and stored locally on first use). Share it to receive payments.
Check a Setu balance — your own wallet by default, or any address you pass.
Act as a merchant: issue an invoice for a resource at a price. Return the invoice to the buyer, who pays it with setu_pay using the invoice id as the reference.
Act as a merchant: verify a buyer's payment certificate against an invoice you issued (single-use). Returns whether to deliver the resource.
Request test units from the faucet (testnet only — these are not money).
Report the live Setu network: which authorities are up, and how many payments have settled.
Pay another agent or merchant. Final in one network round trip (~200ms across regions). Optionally include a reference (e.g. an invoice id) that is signed into the payment.
Output schemas not documented. Tools return free-text strings (e.g., 'Your Setu address:\n...' from setu_address, 'Balance of ... : X units' from setu_balance) instead of structured JSON objects. LLMs cannot reliably parse unstructured text or plan downstream tool calls without knowing response field names and types.
Parameter descriptions are minimal (avg 40 chars vs 72-char baseline). E.g., setu_balance 'address' param: 'Optional address; defaults to your wallet' lacks format guidance. setu_verify_payment 'certificate' param: 'A Setu certificate object' does not explain structure or required fields. Descriptions should state format, constraints, and examples.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 50 | 2026-07-28+ | v2 |
Verify a Setu payment certificate offline, using only the committee public keys. Returns whether it is a valid, quorum-signed payment.
No tool annotations despite clear risk classifications. setu_pay, setu_faucet, and setu_collect are WRITE operations that modify state, but lack destructiveHint or idempotentHint annotations. setu_address, setu_balance, setu_verify_payment, setu_charge, and setu_network are READ_ONLY but lack readOnlyHint. Annotations help LLMs reason about retry safety and side effects.
Error handling lacks recovery guidance. Tools return plain success text (e.g., 'Paid X to Y') but do not categorize errors as retryable, user-fixable, or fatal. setu_pay could fail due to insufficient balance, network timeout, or invalid recipient, each requires different recovery. No error messages guide the LLM on next steps.
setu_collect parameter 'certificate' lacks type definition in schema. Schema shows 'type: object' with no properties or required fields documented. LLMs cannot validate certificate structure before passing it. Should define certificate.order, certificate.signatures, or reference a formal schema.