Loading ToolBench
Global Payments API MCP Server for AI agent integration. Provides tools for creating payment links, retrieving documentation, and managing payment operations through the Global Payments API.
The server provides three well-structured tools with mostly complete schemas and descriptions. Tool naming follows verb_noun convention (create_payment_link, get_documentation, get_links) which is strong. All tools have meaningful descriptions (119-258 chars, within the 10-1024 baseline). Input parameters are typed with JSON Schema and include descriptions. However, there are significant gaps: output schemas are not documented in the visible code, some parameter relationships are undocumented, and error handling guidance is not explicit in tool definitions. The schema quality is good but incomplete, parameters have types and length constraints, but no documented response structure means agents cannot plan downstream calls effectively.
Create a payment link using Global Payments API. Returns a unique URL that can be shared with customers for payment collection. Supports single-use or multi-use links with customizable amounts, currencies, and countries.
Fetch and retrieve Global Payments API documentation for specified categories. Returns OpenAPI specifications with endpoints, parameters, schemas, and security information.
Retrieve a list of payment links with optional filtering and pagination. Returns details about existing payment links including status, usage, and expiration information.
Output schemas are not documented in any tool definition. LLMs cannot plan downstream tool calls or extract specific fields from responses without knowing the structure. This violates pattern:tool and pattern:response-shaper.
get_documentation tool has minimal description (47 chars) stating only 'Retrieve API documentation from Global Payments. Fetches OpenAPI specifications and returns structured API documentation.' No guidance on WHEN to call it, WHAT structure it returns, or how it differs from get_links. Description length is below baseline average (194 chars).
Conditional parameter relationships are undocumented. In create_payment_link, 'shipping_amount' is 'Conditionally MANDATORY when shippable is YES' but there is no guidance in the shippable parameter description stating this dependency. LLMs may omit shipping_amount without knowing it is required. Violates pattern:constrained-input.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 12 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 46 | 2025-06-18+ | v1 |
No error handling or recovery guidance visible in tool definitions. No description of what errors may occur, what they mean, or what the LLM should do next (e.g., 'Invalid amount: must be > 0 in smallest currency unit'). Violates pattern:recovery-guide.
get_links accepts 11 optional filter parameters with no guidance on mutual exclusivity or sensible combinations. An LLM could pass contradictory filters (e.g., status='PAID' AND status='ACTIVE'). No documentation of how multiple filters interact (AND vs OR logic).
No pagination result limits documented in get_links tool description, though page_size accepts 1-1000. Best practice (mxe:enforce-result-limits) recommends capping at 20-50 and documenting this in the tool description to manage context window. Default page_size is not specified.