Loading ToolBench
PayU MCP Server enables secure AI integration with PayU payment APIs via the Model Context Protocol (MCP).
The PayU MCP server has 8 tools with reasonable naming and mostly complete parameter schemas. However, tool descriptions are minimal and generic (most are under 50 characters), parameter descriptions lack actionable detail, and output schemas are not documented. The server shows foundational structure but falls short of production standards: enum constraints are embedded in text descriptions rather than declared as JSON Schema enums, error handling lacks recovery guidance, and there is no documentation of return structures. This is typical of early-stage API wrapper servers.
Get refunds summary from PayU.
Get invoice details from PayU API.
Send payment link to a customer.
Search refunds in PayU system.
Get PayU settlement details by settlement ID.
Get transaction data for a specific PayU ID.
Get detailed transactions list from PayU.
Tool descriptions are too minimal. Most are 30 - 45 characters, well below the 50 - 200 char optimal range (baseline: 194 chars average). 'Get invoice details from PayU API' provides no context for when/why an LLM should select this tool vs others.
Enum constraints are embedded as text descriptions ('Valid values: captured, failed, failure, ...') rather than declared as JSON Schema enum fields. This forces LLMs to parse and validate against hardcoded lists in text, increasing hallucination risk and wasting tokens.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields without knowing what each tool returns. E.g., does invoice_details return an amount, due_date, and invoice_id for chaining?
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 48 | - | v1 |
Get transactions summary from PayU.
Parameter descriptions lack actionable format/constraint guidance. E.g., date_from is described as 'Start date (YYYY-MM-DD HH:MM:SS format)' which is good, but many parameters lack examples of valid ranges or formats. date_from and date_to are marked MANDATORY but no default or error message guides what happens if omitted.
payment_link and other write tools lack explicit state-change documentation. Descriptions do not confirm that calling payment_link sends a link to the customer (irreversible, idempotent via what identifier?). Agents cannot reason about retry safety.
No error handling guidance in tool descriptions or observable implementation. Code returns JSON errors (e.g., in enhanced_transaction_tools.py validation) but no recovery hints. An invalid status error should say 'Did you mean one of: [...]?' to enable LLM self-correction.
Inconsistent parameter naming across related tools. transactions_list uses 'page_offset' and 'page_limit', while search_refunds uses 'page_offset' and 'page_size'. This forces LLMs to remember different parameter names for the same concept.
No idempotency guarantees stated for write operations. payment_link accepts amount, description, name, phone, email but no idempotency key or check. Retrying with identical params may create duplicate payment links.
transactions_list and transactions_summary accept min_amount and max_amount, with documented requirement that 'both must be provided together (PayU API requirement).' This constraint is stated in descriptions but not enforced at the schema level (no JSON Schema conditional validation).