Loading ToolBench
MCP server for Payman payment platform integration, supporting multiple payment rails including TEST_RAILS, US_ACH, and CRYPTO_ADDRESS payees, with payment sending capabilities
Server has 5 tools with explicit Zod schemas and descriptions, but quality is inconsistent. Tool naming follows verb_noun convention (set-api-key, create-test-rails-payee, send-payment). Descriptions exist but are brief (10-50 chars) and lack context on when/why to use tools or prerequisites. Schemas are present with type definitions, but parameter descriptions are minimal. Critical issue: set-api-key exposes API credentials as a tool parameter, violating secret-injection pattern. send-payment is IRREVERSIBLE but lacks confirmation/dry-run pattern. No output schemas documented. Error handling returns isError flag but lacks recovery guidance or actionable next steps.
Create a cryptocurrency address payee
Create a test payee using TEST_RAILS payment rails
Create a US ACH payee with bank account details
Send a payment to a payee
The Payman API key to use for authentication
set-api-key exposes API credentials as a tool parameter. Credentials must never appear in tool parameters, use server-side secret injection via environment variables or vault. Agent traces log every parameter, leaking secrets into logs and prompt history.
send-payment is marked IRREVERSIBLE but lacks confirmation/dry-run pattern. Agents make mistakes, destructive operations should support a confirmation step or require explicit user approval before executing.
Tool descriptions are too brief (10-50 chars) and lack context. Descriptions should explain WHAT the tool does, WHEN to use it, and any prerequisites. E.g., 'Create a test payee using TEST_RAILS payment rails' does not explain when to call this vs other payee creation tools or what happens next.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | 2026-07-28+ | v2 |
No output schemas documented. LLMs need to know what fields to expect in responses so they can plan downstream tool calls and extract the right data. Responses return raw JSON without structure hints.
Error handling returns isError flag but lacks recovery guidance. Errors should tell the LLM what to do next: 'API key not set. Call set-api-key first.' Raw error messages give the agent nothing actionable.