Loading ToolBench
MCP server for processing payments and managing transactions via SecurePay API
SecurePay MCP has three tools with complete JSON schemas and basic descriptions. However, the server exhibits critical security flaws (credential exposure in tool parameters), incomplete error handling guidance, and missing output schema documentation. Tool descriptions are generic (12-16 words) and lack context about when/why to use each tool. Parameter descriptions are minimal (1-2 words). No error recovery guidance. The process_payment tool is particularly dangerous, exposing credit card details and billing information as parameters rather than using secure server-side injection. None of the tools include guidance on expected outputs or error scenarios. While schemas are structurally valid JSON Schema, they lack constraints (enums, patterns, min/max) that would prevent hallucinated values from the LLM.
Check the status of a transaction
Get the transaction history for a merchant
Process a payment with credit card details
CRITICAL SECURITY: Credit card numbers, CVV, and billing details exposed as tool parameters. These are secrets that must never appear in agent traces, logs, or prompt history. Parameters like 'card.number' and 'card.cvv' should be replaced with server-side secret injection or tokenization.
No output schema documentation. LLMs cannot know what fields process_payment, check_transaction, or get_transaction_history return. This prevents downstream tool chaining and forces LLMs to guess at response structure.
No error recovery guidance. Tools lack descriptions of failure modes and next steps. E.g. process_payment offers no hint about what to do if the card is declined, if the billing address is invalid, or if the payment gateway times out.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 42 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 35 | - | v1 |
Tool descriptions are generic and too brief (12-16 words). They lack context about prerequisites, side effects, or when to use each tool instead of alternatives. E.g. 'Check the status of a transaction' does not explain whether this returns real-time status, polling frequency, or what statuses are possible.
Parameter descriptions are minimal (1-2 words). 'Card number', 'Expiry month', 'CVV' do not explain format, constraints, or validation rules. E.g. card.number lacks a format constraint (must be 13-19 digits, numeric). card.expiryMonth lacks clarity (is it '12' or '12/2025'? zero-padded?). Without constraints, LLMs hallucinate invalid values.
No enums or pattern constraints in schemas. ExpiryMonth and expiryYear accept any string, LLMs will pass '13', 'December', 'Dec', or nonsense values. No enum constraint like ['01','02',...,'12'] or pattern validation.
Missing confirmation/dry-run pattern for irreversible write operations. process_payment executes a real payment, agents make mistakes. No support for confirmation_required, dry_run, or review-before-commit.
startDate and endDate in get_transaction_history lack format constraints. Description says 'YYYY-MM-DD' but this is in the description text, not a JSON Schema format property. LLMs cannot parse prose constraints reliably. Should declare 'format: date'.
process_payment does not declare that it modifies state (charge payment, financial write). Description lacks explicit side effect notification. LLMs need to know if a tool is safe to retry.
No permission gates or audit trail implementation visible. Tools accept calls with no authentication or authorization verification. No logging of who called what tool, with which parameters, or what the result was.