Loading ToolBench
ClawdPay has 3 tools with visible schemas and descriptions, but critical security and design issues significantly reduce quality. Tool naming is mostly clear (verb-driven: create_, secure_, get_), but parameter descriptions are minimal or absent, and the secure_auto_fill tool conflates PAN/CVV transmission with browser automation. Input schemas are present for all tools but lack descriptions on individual parameters (e.g., merchant, amount_cents, pan, cvv have no descriptions in the visible schema object). No output schemas are documented. Error handling is absent, tool implementations would fail silently or throw generic errors without recovery guidance. The secure_auto_fill tool exposes card credentials as required parameters, violating the secret-injection pattern. Overall, this reads as an experimental/prototype tool rather than production-grade.
Create a single-use virtual card via Privacy.com. Returns secure card details.
List available funding accounts connected to Privacy.com
Intelligently finds and fills payment fields on the current page using robust heuristics.
secure_auto_fill exposes PAN, CVV, expiration month/year as required parameters. Card credentials must NEVER appear in tool parameters, they are logged, traced, and entered into prompt history. This violates pattern:secret-injection and creates a critical security vulnerability.
Input schema properties lack descriptions. The schema object for all three tools lists properties (merchant, amount_cents, pan, cvv, exp_month, exp_year, url) without parameter descriptions. LLMs cannot infer meaning from names alone (e.g., 'merchant' could mean merchant name, merchant ID, or merchant code).
No output schemas documented. The source code returns untyped responses (JSON.stringify for cards/sources, plain text for auto-fill). LLMs cannot plan downstream operations without knowing response structure. No documentation of returned fields (e.g., card_number, pan, expiry, funding_source_type, balance).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 0 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 39 | - | v1 |
No error handling or recovery guidance. CallToolRequestSchema handler has default case throwing 'Unknown tool' with no actionable guidance. Tool implementations (privacy.createCard, browser.smartFillPayment, privacy.getFundingSources) are not visible, so error messages and failure modes are unknown. Per pattern:recovery-guide, error responses must tell LLMs what to do next.
secure_auto_fill description is vague and doesn't explain side effects. 'Intelligently finds and fills payment fields on the current page using robust heuristics' does not explain that the tool launches a headless browser, navigates to a URL, and injects card data into DOM fields. Agents need to understand the destructive nature of this operation (state modification, external navigation).
Parameter type mismatch in secure_auto_fill schema. exp_month and exp_year are declared as strings but represent numeric values (01-12, 2024 or 24). No format constraints (e.g., pattern regex) visible in schema. LLMs may pass invalid formats like 'January' or '2024-01-31'.
Naming ambiguity: secure_auto_fill suggests autofill is the primary action, but the tool also requires navigation (url parameter). The name doesn't reflect the full scope. Consider 'fill_payment_form' or 'navigate_and_fill_payment' for clarity.