Loading ToolBench
Zuora API MCP Server in JavaScript - provides access to Zuora billing and subscription management APIs through an MCP interface
This server has 4 well-defined static tools with complete input schemas and descriptions. Naming is clear and verb-based (list_, describe_, invoke_, download_). Descriptions are reasonably detailed (80-180 chars) and explain when to use each tool. However, there are significant gaps in output schema documentation, the server does not document what fields are returned by any tool, forcing LLMs to guess the structure of responses. Error handling is minimal (generic 'Error: {message}' catch-all). The invoke_api tool accepts overly generic 'arguments' (additionalProperties: true) without input validation or field descriptions, creating ambiguity about required vs optional parameters. No parameter examples or constraints guide LLM input beyond regex patterns on tool_name and url. The download_file tool lacks size limits, timeout documentation, or encoding guidance. Overall, these are decent meta-tools for API discovery, but lack the polish expected in production (output documentation, structured error recovery, input validation guidance).
🔍 Get comprehensive details about a specific Zuora API operation including required parameters, request body schema, field descriptions, examples, and usage guidelines. Always call this before 'invoke_api'.
⬇️ Download content from a URL (typically used for retrieving Zuora export files, reports, or generated documents). Returns the file content as text.
🚀 Execute a Zuora API operation with the provided parameters. Use 'describe_api' first to understand required fields and structure. For missing required parameters, ask the user rather than assuming values.
📋 List all available Zuora API operations. Returns operation IDs that can be used with 'describe_api' to get detailed information about each API endpoint. Essential first step for API discovery.
No output schema documentation for any tool. LLMs cannot plan downstream calls or extract fields without knowing what list_operations, describe_api, invoke_api, and download_file return. Pattern tool-description requires documenting return types.
invoke_api accepts 'arguments' as generic additionalProperties:true object with minimal documentation. No guidance on what keys are valid (path params vs query params vs headers vs body), required vs optional, or parameter types. LLMs will hallucinate parameter names.
Error handling is a catch-all that returns 'Error: {message}' with no recovery guidance. Per pattern recovery-guide, errors should tell the LLM what to do next (e.g., 'Invalid operation. Call list_operations() to see available operations.').
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 50 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 16 | - | v1 |
download_file tool lacks critical constraints: no max file size, no timeout documented, no content-type handling, no charset declaration. LLMs may attempt to download multi-GB files or hang on slow endpoints.
Parameter descriptions lack actionable constraints. E.g., tool_name has a regex pattern '^[A-Z_][A-Z0-9_]*$' in the schema but this constraint is NOT stated in the description text. LLMs cannot read JSON Schema patterns, they need constraint descriptions in plaintext.