Loading ToolBench
Yuno MCP server: create and manage payments, subscriptions, customers, payment methods, checkouts, recipients, installment plans, and payment links on the Yuno payments platform.
Yuno MCP has 38 tools with consistently declared input schemas and basic descriptions. Tool naming generally follows verb_noun patterns (checkoutSessionCreate, customerRetrieve, paymentRefund). However, critical gaps limit the score: (1) Most parameter descriptions are minimal (often 1-2 lines with no dependency hints, format constraints, or multi-step guidance). (2) Output schemas are declared but not visible in the source, only referenced as optional in tool.outputSchema. (3) Many tools with 'account_id' parameters default to yunoClient.accountCode with vague 'optional' wording, creating ambiguity about when defaults apply. (4) Destructive operations (paymentRefund, paymentCancelOrRefund, subscriptionCancel, installmentPlanDelete, recipientDelete, paymentLinkCancel, paymentMethodUnenroll) lack explicit confirmation or dry-run patterns in their schemas. (5) The 'describeTool' meta-tool is present but cannot fully substitute for rich inline documentation of complex object parameters like 'payment' and 'body'. (6) No pagination guidance for tools like paymentRetrieveByMerchantOrderId or checkoutSessionRetrievePaymentMethods. (7) Error handling and recovery guidance are not visible in descriptions. Overall, the server is well-structured with valid TypeScript schemas and proper type safety, but descriptions are utilitarian rather than LLM-optimized, and output shapes are underdocumented.
Create a new checkout session in Yuno.
Generate a One Time Token (OTT) for a checkout session in Yuno.
Retrieve payment methods for a checkout session in Yuno.
Create a new customer in Yuno.
Retrieve a customer by ID.
Retrieve a customer by external merchant_customer_id.
Output schemas are not documented in descriptions or visible in the source. Tool.outputSchema fields exist but their structure is never explained to LLMs. This forces agents to call describeTool repeatedly to understand response fields before building queries.
Destructive operations (paymentRefund, paymentCancelOrRefund, subscriptionCancel, installmentPlanDelete, recipientDelete, paymentLinkCancel, paymentMethodUnenroll) lack confirmation/dry-run patterns. Server implements confirm_token at src/index.ts only for prod + destructive tools, but this is not documented in tool descriptions. LLMs cannot infer that a second call with a token is required.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 39 | 1.25.1+ | v1 |
Update a customer by ID.
Return the complete input/output JSON Schema and a worked example for any tool on this server. Registered schemas are compacted; call this before building complex payloads (e.g. paymentCreate).
Create an installment plan in Yuno.
Delete an installment plan in Yuno by its ID.
Retrieve an installment plan in Yuno by its ID.
Retrieve all installment plans in Yuno for an account.
Update an installment plan in Yuno by its ID.
Authorize a payment in Yuno.
Cancel or refund a payment in Yuno.
Cancel or refund a payment with transaction in Yuno.
Capture an authorized payment in Yuno.
Create a new payment in Yuno.
Cancel a payment link in Yuno by its ID.
Create a payment link in Yuno.
Retrieve a payment link in Yuno by its ID.
Enroll or create payment method.
Retrieve an enrolled payment method by customer and payment method ID.
Retrieve all enrolled payment methods for a customer.
Unenroll a saved payment method for the user.
Refund a payment in Yuno.
Retrieve a payment by ID in Yuno.
Retrieve payments by merchant order ID in Yuno.
Create a new recipient in Yuno.
Delete a recipient by ID in Yuno.
Retrieve a recipient by ID in Yuno.
Update a recipient by ID in Yuno.
Cancel a subscription in Yuno.
Create a new subscription in Yuno.
Pause a subscription in Yuno.
Resume a paused subscription in Yuno.
Retrieve a subscription by ID in Yuno.
Update a subscription in Yuno.
Complex object parameters ('payment' in paymentCreate, 'body' in paymentRefund/paymentCancelOrRefund) are declared as {type:'object', description:'...'} with no inline field documentation. LLMs cannot know what fields to include without calling describeTool. Parameter descriptions are generic: 'Payment data with optional account_id' vs 'Payment data: requires amount (number, cents), currency (string, ISO 4217 code), payment_method_id (string), ...'.
Many parameter descriptions are under 20 characters or lack actionable context. Examples: 'Account ID (optional, defaults to yunoClient.accountCode)' (repeated in 7 tools), does not explain when to override the default. 'The unique identifier of the customer to retrieve (MIN 36, MAX 64 characters)', present but does not explain what a customer_id looks like or how to obtain one if you only have an email.
No pagination guidance for tools returning multiple items (checkoutSessionRetrievePaymentMethods, installmentPlanRetrieveAll, paymentRetrieveByMerchantOrderId, paymentMethodRetrieveEnrolled). Descriptions do not mention limits, offsets, cursors, or result caps. Agents may retrieve unlimited data and blow context windows.
Vague tool naming for refund/cancel operations. 'paymentCancelOrRefund' and 'paymentCancelOrRefundWithTransaction' are ambiguous, LLMs cannot infer when to use one vs the other without reading descriptions. The distinction (with/without transaction_id) is not clear in names. Recommend: paymentCancelWithoutTransaction and paymentCancelWithTransaction, or paymentCancel and paymentRefund as separate verbs.
No error handling or recovery guidance in tool descriptions. Descriptions do not explain what happens on failure, when to retry, or how to recover from partial failures. For example, paymentCreate does not state: 'If this fails with insufficient_funds, the payment is not created and is safe to retry. If it fails with network_error, retry with the same idempotency_key. If it fails with invalid_card, ask the user for a different card.'
Inconsistent parameter naming for IDs with length constraints. Some tools use minLength/maxLength in schema (e.g., customer_id), but descriptions do not always state the range in human-readable form. Others repeat 'MIN 36, MAX 64 characters' in the description text, which is redundant with the schema. Normalize: put constraints only in schema, or only in description, not both.