Loading ToolBench
AI agent payment integration SDK, CLI, and MCP server for adding Yolfi crypto checkout, payment links, webhooks, and payment status checks.
Server demonstrates solid naming conventions, comprehensive parameter descriptions, and proper schema structure across 19 tools. Tool names follow verb_noun patterns (yolfi_agent_setup_start, yolfi_paylinks_create, yolfi_webhooks_configure). Most tools include substantive descriptions (median ~120 chars) and well-typed input schemas with enum constraints for controlled values (adapter: NONE|STRIPE|LEMON_SQUEEZY, currency: USD|EUR|CNY, type: ONE_TIME|RECURRING). Strong security awareness (no credentials as parameters, confirmation gates on destructive ops). However, output schemas are entirely undocumented, tool responses are not described, breaking the tool-chain pattern where downstream tools need to know what fields to expect. Error handling is absent from documentation; tools provide no recovery guidance or error classification. Some parameter relationships are underdocumented (e.g., settlementAccounts structure is vague: 'Example fields: id, address, tokens' invites invalid input). Per-tool scores range 55 - 82; the average is held down by missing output documentation and error guidance.
Check whether browser authorization finished. On success, securely stores the returned yolfi_agent_* credential for later local SDK, CLI, and MCP calls.
Start signup for a new Yolfi user from a user-confirmed email. The first call sends a confirmation link and stores protected check-in state; call the same tool again after confirmation to store the one-time credential without exposing it.
Start the preferred browser-based Yolfi authorization flow. Returns a login URL and stores only a short-lived check-in token in the protected local Yolfi config.
Verify the active OAuth, local agent, or API-key credential and return the current Yolfi organization context before mutating payment settings.
Read the current Yolfi organization settings, including webhook and settlement configuration visible to this API key.
Output schemas are entirely undocumented. No tool describes its return type or response fields. This breaks tool-chaining: when yolfi_agent_setup_start completes, what does it return? When yolfi_paylinks_create succeeds, does it return a paylinkId that yolfi_paylinks_get can accept? Downstream tools cannot reliably extract required fields (organization context, pagination cursors, IDs for chaining) without explicit response documentation.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | 2026-07-28+ | v2 |
Update organization profile fields through the existing Yolfi organization endpoint. Do not invent merchant identity, support email, or settlement settings.
Create a one-time or recurring payment link with optional description and metadata.
Disable a payment link and stop accepting payments on it.
Get details of one payment link by id.
List all payment links with pagination.
Create a payment for the target paylink or attached to an external order id.
Get payment status and details by id.
Configure settlement wallets after the user provides wallet addresses, networks, and enabled tokens. Never invent wallet addresses.
Configure webhook delivery for the target app. The host must not invent backend URLs and must ensure the app verifies X-Yolfi-Signature.
Delete an unused webhook endpoint or disable it when existing delivery history must be retained.
List all independent webhook endpoints configured for the current organization.
Rotate an endpoint-specific webhook signing secret and store it in the protected local Yolfi config without returning the plaintext secret.
Update the name, URL, adapter, or enabled state of one independent Yolfi webhook endpoint.
Verify a webhook payload signature using the endpoint's stored signing secret.
No error handling or recovery guidance. Tools provide no documentation on failure modes, error categories (retryable vs user-fixable vs fatal), or recovery actions. Example: yolfi_agent_checkin could fail if the browser authorization timed out, but agents have no guidance on what to do next. This violates the recovery-guide pattern and forces agents to guess.
yolfi_settlement_configure has vague parameter schema. settlementAccounts is an array of generic objects with 'Example fields: id, address, tokens' but no formal type definition. This invites invalid input from agents. Should use a strict JSON Schema object type with required/optional fields explicitly typed (e.g., address: string format:ethereum-address, tokens: array of string enums, id: string).
Pagination parameters on yolfi_paylinks_list lack constraints. 'page' and 'rows' accept any integer, but no min/max is documented. Agents could pass page=0 or rows=999999, causing failures or timeouts. Should enforce: page >= 1, rows in range 1 - 100.
Missing parameter type in yolfi_webhooks_verify: 'endpointId' is required but has no type declaration in the schema (only a description). All required parameters must have explicit JSON Schema types.
Descriptions for discovery tools (yolfi_paylinks_list, yolfi_webhooks_list, yolfi_organization_get) are generic and do not explain what use cases they enable or when to call them. Should include 'Call this to...' hints to guide agent planning.