MCP server for Tazapay payment platform integration, providing tools for payment links, FX rates, balance management, payins, payouts, beneficiaries, and customers
Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
The server has 19 well-structured tools with consistent naming conventions (all start with action verbs like 'tazapay_fetch_', 'tazapay_create_', 'tazapay_update_'). Tool descriptions are present for all tools and generally fall within the 50-200 char ideal range. However, parameter descriptions are inconsistent across tools, some parameters lack descriptions entirely (e.g., 'reference_id' in tazapay_create_payout_tool has no description), and several parameters in complex tools like tazapay_create_customer_tool have minimal guidance. Output schemas are not documented anywhere in the provided source code, making it unclear what agents can expect from tool responses. Error handling patterns are absent from the visible code. The server implements a financial API with high-stakes operations (payouts, payments) but lacks explicit error recovery guidance that would help agents handle failures gracefully.
Output schemas not documented. No visible schema definitions for what tools return, preventing agents from understanding what fields/types to expect in responses. This violates pattern:tool and forces agents to guess about downstream field availability.
Incomplete parameter descriptions. Multiple tools have parameters lacking descriptions or with minimal guidance: tazapay_create_payout_tool has 'reference_id' (no description), 'beneficiary' (no description), 'metadata' (no description). tazapay_update_payin_tool accepts 'id' but provides no description of what fields can be updated. tazapay_update_beneficiary_tool has no input schema visible at all.
tazapay_create_payout_tool
Recommendations
Add explicit output schemas for all 19 tools. Document return types, field names, and value types so agents can plan downstream tool calls and extract required references (e.g., if create_payout returns payout_id, agents need to know that field name to pass it to fund_payout or confirm_payout).
Add descriptions to all parameter fields, especially for complex objects. For tazapay_create_customer_tool, document what fields 'phone' object expects (e.g., country_code, number). For 'billing'/'shipping' arrays, specify required vs optional fields.
Rename bare 'id' parameters to resource-specific names: 'payout_id', 'payin_id', 'beneficiary_id', 'checkout_id', 'customer_id'. This makes tool signatures self-documenting and prevents parameter confusion when many tools operate on different resource types.
Add enum constraints for enumerated fields: type=['individual'|'business'] for create_beneficiary_tool, type=['individual'|'company'] for create_payout_tool, charge_type=[list valid values], currency=[list supported ISO-4217 codes].
Document error recovery patterns for financial operations. For create_payout_tool, add guidance like: 'If this returns insufficient_balance, call tazapay_fetch_balance_tool to check available funds. If this returns invalid_beneficiary, call tazapay_get_beneficiary_tool to verify the beneficiary exists.'
Add confirmation/dry-run support for destructive operations. For tazapay_cancel_payin_tool and tazapay_expire_checkout_tool, consider adding an optional 'confirm=true' parameter or a separate preview_cancellation tool to let agents show the user what will be cancelled before proceeding.
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
No error handling guidance. Financial tools (create_payout, fund_payout, create_payin, generate_payment_link) execute irreversible operations but provide no error recovery patterns, recovery guides, or actionable error messages. Agents have no guidance on what to do if a payout creation fails.
No dry-run or confirmation pattern for destructive operations. Tools like tazapay_cancel_payin_tool and tazapay_expire_checkout_tool are reversible but lack confirmation steps. An agent could cancel a payin without explicit user approval.
No pagination support visible. Tools like tazapay_fetch_balance_tool return 'all balances' when passed empty string, but no limit/offset/pagination parameters are defined for large result sets. This could cause context-window exhaustion.
Inconsistent parameter naming for IDs. Tools accept 'id' for various resource types (payout ID, payin ID, beneficiary ID, checkout ID, customer ID) without type-suffixed names. Parameter name alone does not clarify resource type, should be 'payout_id', 'payin_id', 'beneficiary_id', etc.
No enum constraints on high-cardinality string fields. Fields like 'type' (beneficiary/payout type), 'charge_type', and 'currency' accept free-form strings. Should define enums or pattern constraints to prevent hallucinated values.
No idempotency guarantees documented. Financial tools that create transactions (create_payout, create_payin, generate_payment_link) should declare whether they are idempotent and support idempotency keys. Agents need to know if retrying a failed call risks duplicates.
Add idempotency key support to transaction-creating tools (create_payout, create_payin, generate_payment_link). Document whether the Tazapay API supports reference_id as an idempotency key, or add an idempotency_key parameter.
Declare permission/scope requirements for each tool. E.g., tazapay_fund_payout_tool should declare it requires 'write:payout' scope, tazapay_fetch_balance_tool should declare 'read:balance'. This enables least-privilege agent configuration.
Add pagination parameters (limit, offset/cursor) to any tool that could return multiple items (e.g., if balance fetch can return many currencies, allow limit=10, offset=0). Cap default results at 20-50 items and document the limit in the description.
Document required vs optional fields explicitly. For tazapay_create_payin_tool, clarify which customer_details fields (name, email, country, phone) are required vs optional. For tazapay_create_beneficiary_tool, specify destination_details structure (is bank_account vs wallet vs other mutually exclusive?).
Add response field reference chains. If create_payout returns payout_id, fund_payout accepts payout_id, and confirm_payout accepts payout_id, document this in descriptions so agents understand the workflow: 'After creating a payout, pass its payout_id to tazapay_fund_payout_tool, then tazapay_confirm_payout_tool.'
Validate currency codes before accepting them. Add a constraint like 'Must be a 3-letter ISO-4217 code (case-insensitive)' to all currency parameters and validate server-side to provide clear feedback if an agent passes 'USA' instead of 'USD'.