Loading ToolBench
Dual-protocol server for managing Privacy.com virtual cards, transactions, and funding sources. Provides both FastMCP streamable-HTTP endpoints and plain REST endpoints.
Strong foundation with all 6 tools properly named with action verbs (list_, get_, create_, update_). All tools have descriptions exceeding the 20-character minimum. Comprehensive parameter schemas with types and descriptions present for all tools. Tool annotations (readOnlyHint, destructiveHint, idempotentHint) correctly applied. However, output schemas are not explicitly documented in the code, responses are JSON-stringified API responses without a formal output spec. Error handling lacks recovery guidance for LLMs. No batch operations or natural-identifier support (e.g., accepting card names alongside tokens). Inline API responses could be stripped for signal clarity per mxe:strip-api-responses pattern.
Create a new virtual card (requires Issuing access).
Return details for a single virtual card.
Return all virtual cards on the account.
Return all funding sources (bank accounts) linked to the Privacy.com account.
Return transactions across all cards or for a specific card.
Update an existing virtual card — pause, resume, close, or change limits.
Output schemas not documented. Tools return raw JSON-stringified API responses without a declared response schema. LLMs cannot infer what fields to expect for downstream tool chaining or data extraction.
Error handling lacks recovery guidance. Tools call resp.raise_for_status() and return generic error messages. No actionable error classification (retryable vs user-fixable vs fatal) or suggestions for recovery (e.g., 'Try listing cards first' if a card_token is invalid).
No natural identifiers or batch operations. Tools accept only system IDs (card_token) and return all API fields without filtering. No support for passing card names, accepting arrays of card tokens for bulk updates, or stripping irrelevant metadata.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 67 | <=2025-11-25 | v2 |
| 2026-03-09 | C | 65 | - | v1 |
Parameter descriptions contain example values (e.g., 'e.g., 1000 = $10.00') rather than formal constraints. LLMs may reuse examples literally. Should use enum constraints for card types and limit durations, and explicit numeric ranges for spend_limit.
list_funding_sources has no input parameters. Description is sparse (75 chars). No documentation of return structure or when to call it relative to create_card.
Response formatting. All tools return _json(resp.json()), which dumps the entire Privacy.com API response. Per mxe:strip-api-responses, verbose metadata and internal fields should be filtered to reduce token count and clarify intent. E.g., a card response likely includes raw hex PAN, CVC, expiry, never pass these to the LLM.
No explicit per-tool permission scope declarations. Tools should declare what OAuth scopes or API capabilities they require (e.g., create_card requires 'issuing_api_access', per the tool description).
update_card error handling for empty body is manual. Returns a JSON error dict instead of raising an exception, breaking consistency. Should validate parameters server-side and return a structured error.