Loading ToolBench
A Model Context Protocol (MCP) compatible server that integrates Ant International's Antom payment APIs, enabling AI assistants to handle payment and refund operations seamlessly.
Five tools with complete input schemas and descriptions, but significant quality gaps. All tools have descriptions (10-256 chars, within range) and typed parameters with descriptions. However, descriptions lack LLM-optimized guidance on WHEN to use each tool vs. alternatives, and lack recovery hints for error cases. Output schemas are completely undocumented, LLMs cannot infer what fields to expect from responses. No error handling guidance. Tool names are clear and action-oriented (create_, query_, cancel_), but parameter naming inconsistencies exist (refund_amount_value is string despite being described as integer). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk profiles (WRITE, READ_ONLY, REVERSIBLE). Composition is reasonable, each tool has one responsibility, but no guidance on tool chaining or prerequisites.
The tool is used to cancel the payment if the payment result is not returned after a long time. The cancellation cannot be performed if being out of the cancellable period specified in the contract.
The tool is used to create a payment session which helps you complete the payment process and eliminate intermediate page redirections throughout the entire payment process.
The tool is used to initiate a refund against a successful payment. The refund can be full or partial. A transaction can have multiple refunds as long as the total refund amount is less than or equal to the original transaction amount. If the refund request is out of the refund window determined in the contract, the refund request will be declined.
The tool is used to inquire about the transaction status and other information about a previously submitted payment request.
The tool is used to inquire about the refund status of a previously submitted refund request.
Output schemas completely undocumented. Tools return strings (raw API responses) with no field documentation. LLMs cannot parse results or chain tools. E.g., create_payment_session returns a string, does it contain a session_id, redirect_url, or error message? Unknown.
No tool annotations despite clear risk profiles. create_payment_session and create_refund are WRITE operations; cancel_payment is REVERSIBLE; query_* are READ_ONLY. Missing destructiveHint and idempotentHint annotations prevent agents from reasoning about retry safety and side effects.
Descriptions lack LLM-optimized guidance. No WHEN-to-use hints, no dependency documentation, no recovery guidance. E.g., create_payment_session description does not explain when to call it vs. query_payment_detail, or what to do if it fails. Descriptions are functional but not agent-optimized.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | 2026-07-28+ | v2 |
Parameter type mismatch: create_refund.refund_amount_value is declared as string in schema but described as 'positive integer in smallest currency unit'. Should be integer type. This invites LLM confusion and API failures.
No error handling guidance. All tools catch exceptions and return str(e), but descriptions do not explain what errors are possible, whether they are retryable, or what the LLM should do next. E.g., 'payment_request_id not found', should the agent retry, ask the user, or call a different tool?