Loading ToolBench
Razorpay MCP server providing stdio and SSE transports
The server defines 11 read-only tools with consistent pagination patterns. All tools have descriptions and input schemas visible in src/core/mcp-server.ts. However, descriptions are minimal (15-60 chars), parameter descriptions are generic, and output schemas are not documented. No error handling guidance, no tool annotations, and all tools lack depth beyond basic pagination. The 11 tools follow a repetitive pattern (getAllX) with identical parameter sets, suggesting missed opportunities for composition and differentiation. Tools return JSON-wrapped responses via MCP's text content format, but the actual response structure (what fields are in 'data') is undocumented. The server passes validation only on definition presence, not quality.
Fetch account balance for a specific account
Fetch all contacts with pagination support
Fetch all customers with pagination support
Fetch all disputes with pagination support
Fetch all invoices with pagination support
Fetch all orders with pagination support
Fetch all payments with pagination support
Descriptions are too brief (15-60 chars) and lack context for LLM selection. None explain WHY to use a specific tool vs alternatives, WHEN it applies, or what the output structure contains. Pattern baseline is 194 chars and 100% of A+ tools have substantive descriptions.
Parameter descriptions ('Number of records to skip', 'Timestamp from which to fetch records') are generic and do not state format, range, or valid values. Pattern requires descriptions to state 'expected format, range, and allowed values', e.g. 'Unix timestamp (seconds since epoch, e.g. 1704067200)' not just 'Timestamp from which to fetch records'.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Fetch all refunds with pagination support
Fetch all settlements with pagination support
Fetch all transactions with pagination support
Fetch all VPAs (Virtual Payment Addresses) with pagination support
No output schema documented. Tools return JSON-wrapped text responses, but the structure of 'data' field is not documented. LLMs cannot plan downstream calls or extract relevant fields without knowing response shape. Pattern requires 'document the output schema' and 'return structured objects with typed fields'.
No error handling guidance. Error responses return raw error messages (e.g. 'error.message' from try-catch) but do not categorize errors as retryable/user-fixable/fatal or suggest recovery actions. Pattern requires 'Error responses must tell the LLM what to do next' and 'categorize errors as retryable, user-fixable, or fatal'.
11 tools with identical pagination signatures (skip, count, from, to) repeat the same pattern. No batch variants, no filtering parameters beyond timestamps, and no differentiation in capability. Naming (getAllX) is repetitive and does not match the verb_noun convention that helps LLMs disambiguate. Pattern recommends 'Each tool should do exactly one thing' and avoiding tools that 'do the same thing differently'.
No tool annotations present. Tools should declare readOnlyHint, destructiveHint, or idempotentHint via @tool annotation. All 11 tools are read-only but this is not machine-declared; agents must infer it from behavior.
accountId parameter in getAccountBalance has minimal description ('Account ID cannot be empty') but does not state format (alphanumeric? hex? numeric?), length, or example. Pattern requires 'state the expected format, range, and allowed values directly in the parameter description'.
No limit specified on result size. Tools accept 'count' parameter (max 100 per description) but if omitted, all records may be returned. Pattern states 'Even if the API allows returning thousands of items, cap results at a reasonable limit (e.g. 20-50) and offer pagination. State the limit in the tool description.' No default limit is enforced or documented.