Loading ToolBench
Secure card vault with policy-gated payments for AI agents. Works as MCP server and OpenClaw plugin.
ClawPayer defines 3 tools with explicit schemas and descriptions in src/integrations/mcp-server.ts. Tool naming follows verb_noun convention (request_card, get_payment_policy, check_card_status). Descriptions are present and moderately detailed (140 - 240 chars), meeting the 10 - 1024 char baseline. However, several quality gaps reduce the score: (1) Input schemas lack descriptions for most parameters, only 'amount', 'merchant', 'description', and 'currency' in request_card have descriptive text, but 'currency' default is stated without explaining when to override it. get_payment_policy and check_card_status schemas are empty objects with no parameter documentation. (2) Output schema is NOT documented anywhere, responses are stringified JSON, but the expected fields (approved, reason, cardholderName, number, expMonth, expYear, cvv, billingAddress, etc.) are never formally declared in a schema artifact. LLMs cannot reliably parse or chain these outputs without an explicit schema. (3) Error handling is minimal, no guidance on retryability, user-fixable errors, or recovery paths. (4) No tool annotations (readOnlyHint, idempotentHint, destructiveHint) present. (5) Descriptions lack dependency hints and context on when to call each tool in sequence. Tool descriptions do state WHAT they do and consequences (card returned only if approved), which is good, but lack guidance on prerequisites and error recovery.
Check if a credit card is stored in the vault. Does not return card details.
Get the user's payment policy configuration. Call this to understand spending limits and rules BEFORE attempting a purchase. This helps you know in advance whether a payment will be approved, need human approval, or be blocked — so you can inform the user proactively.
Request stored credit card details to complete a payment. The card will ONLY be returned if the payment passes the user's policy rules. Depending on the amount and configuration, the payment may be auto-approved, require human approval, or be denied outright. IMPORTANT: Always call this BEFORE attempting to fill in any payment form. The user has configured spending rules and must approve payments above certain thresholds.
Output schemas not documented. Tool responses return stringified JSON with fields like 'approved', 'cardholderName', 'number', 'expMonth', 'expYear', 'cvv', 'billingAddress', 'reason', 'cardStored', 'message', but no formal output schema is declared. LLMs cannot reliably parse or chain these responses without explicit field definitions.
Input parameters for get_payment_policy and check_card_status have empty schemas (no properties defined). While these are read-only tools that take no arguments, the schema should still be explicit and include a description explaining why no parameters are needed, or the tools should document why they are parameter-free.
request_card description includes example values ('amazon.com', 'Cool Store', '2x t-shirts, 1x hoodie') which LLMs may reuse literally. Use formal constraints (enums, patterns) instead; replace examples with descriptions of valid formats.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | <=2025-11-25 | v2 |
No error handling guidance. Tools do not document what errors can occur, when they are retryable, or what the LLM should do next if a payment is denied, a card is missing, or a policy violation occurs. 'Reason' field in request_card denial response is not documented with expected values.
No tool annotations. Tools lack readOnlyHint (all three are read-only), idempotentHint (request_card has side effects and is NOT idempotent, it checks policy and may require approval), or destructiveHint. Annotations help LLMs reason about retry safety and composition.
Parameter descriptions are minimal or absent. request_card defines 'amount', 'merchant', 'description', 'currency' with brief descriptions, but does not specify range (amount >= 0?), format, or allowed values (currency should be enum or pattern like ISO 4217). get_payment_policy and check_card_status schemas are empty and undocumented.
Dependency hints missing. Descriptions do not guide agents on call order (e.g., 'Call get_payment_policy first to understand limits, then call request_card with an amount') or recovery (e.g., 'If denied, call check_card_status to verify a card is on file, or ask user to run clawpayer add-card').