Loading ToolBench
MCP server that lets AI agents pay on the Canton Network through a human's mobile wallet: the agent asks, the human approves on their phone, hardware signs.
Canton Agent MCP demonstrates solid tool design with clear naming conventions (all tools start with 'canton_' prefix and action verbs), comprehensive descriptions (avg 180 chars, well within 10-1024 range), and explicit input schemas with type definitions and constraints. All 7 tools have descriptions and schemas. However, parameter descriptions are sparse, most parameters lack inline descriptions explaining their purpose, format, or constraints. Output schemas are not documented. Error handling is present but generic ('Error: {message}'). Risk annotations (READ_ONLY, WRITE, IRREVERSIBLE) are declared but not exposed as tool annotations in the MCP schema. Tool composition is clean: each tool has one responsibility, and canton_request_payment correctly includes all chaining IDs (to, amount, instrument, memo).
The Canton parties the wallet has granted this agent, with their public keys. The first call prompts the human to approve the connection on their phone.
Starts pairing with the human's Canton mobile wallet. Returns a QR code and a wc: URI; the human scans it from their wallet's Connect tab and approves on the phone. Poll canton_wallet_status until connected.
Ends the WalletConnect session with the wallet.
Mints test funds into the embedded wallet's allowance. Only available on test networks (LocalNet/DevNet); on real networks the human funds the allowance with a transfer from their own wallet.
Asks the wallet to pay: builds a Canton Token Standard transfer and pushes it to the phone, where the human reviews and approves it and the device key signs. Blocks until the human decides (they may take a while), then returns the result.
Proves the human controls their Canton party: the wallet signs a structured Sign-In with Canton challenge (approved on the phone) and the signature is verified against the party's published key. Returns the verified party id.
Parameter descriptions missing or minimal. 'statement' in canton_sign_in has a description, but 'to', 'amount', 'instrument', 'memo' in canton_request_payment lack inline descriptions in the schema, only visible in the code comment. LLMs cannot read code comments; they need descriptions in the inputSchema object.
Output schemas not documented. Tools return text responses, but the structure (e.g., canton_accounts returns a list of DappAccount objects with partyId, hint, status, networkId) is not declared in the tool definition. LLMs cannot plan downstream calls without knowing what fields are returned.
Risk annotations (READ_ONLY, WRITE, IRREVERSIBLE) declared in code but not exposed as MCP tool annotations. The MCP spec supports readOnlyHint, destructiveHint, and idempotentHint in tool definitions, these should be added to help agents reason about side effects.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 73 | <=2025-11-25 | v2 |
Whether a mobile wallet is connected over WalletConnect, and on which Canton network. Call after canton_connect_wallet to see if the human has approved the pairing.
Error handling is generic. All errors return 'Error: {message}' without recovery guidance. Per pattern:recovery-guide, errors should suggest next steps (e.g., 'Wallet not connected. Call canton_connect_wallet first.').
No confirmation step for irreversible operations. canton_request_payment is marked IRREVERSIBLE but does not support a dry-run or confirmation pattern. Agents should be able to preview the payment before committing.