Full payment matrix: every supported coin × network combination currently available, with the exact network strings orders require. The response includes live totals — report those, never a memorized count.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
| payment_via | No | ||
| combinations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds that the response includes live totals and that agents should report them rather than using memorized counts, which is useful behavioral context. There's a possible contradiction: openWorldHint=false but the description says 'currently available' implying a dynamic set, but that's not a direct contradiction. The description doesn't mention pagination or rate limits, but given the matrix scope, it's acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose and key detail about network strings. The instruction about reporting live totals is included without waste. Excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, an output schema exists (though not provided in detail here, it's indicated), and the annotations cover safety, the description is sufficient. It tells the agent what data is returned and how to use it. The only minor gap is not mentioning if there's any caching behavior or timing, but the warning against memorized counts addresses that. The description is complete for a no-arg tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100% (no params to cover). The description adds value by explaining the meaning of the response: every coin × network combination and exact network strings. It also emphasizes reporting live totals. With no parameters, the baseline for parameter semantics is 4 per instructions, and the description enhances that with response semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a full payment matrix of coin × network combinations with exact network strings needed for orders. This distinguishes it from siblings like get_currencies which lists currencies and create_order which places orders. However, the name 'get_payment_methods' is broad but the description sharpens it to the specific matrix.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is used to retrieve supported payment methods and exact network strings required by orders. It mentions 'report those, never a memorized count' which warns against using cached values, implying usage is to fetch live data. It does not explicitly state when not to use it or contrast with siblings like get_currencies, though the boundary is fairly clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools have clear distinct purposes: listing currencies, payment methods, prices, brands, eSIM plans, products, searching, validating, creating, and checking order status. However, potential confusion between list_esim_plans and list_products for eSIM purchases, and search_products overlapping with list_brands/list_products, creates slight ambiguity. purchase_wizard serves as a fallback but is clearly labeled.
Tools follow a consistent verb_noun pattern: get_currencies, get_order_status, get_payment_methods, get_price, list_brands, list_esim_plans, list_products, validate_order, create_order, search_products. 'purchase_wizard' deviates slightly as a noun phrase rather than verb_noun, but it's a distinct standalone tool.
With 11 tools covering the full purchase lifecycle (browse, search, price, validate, create, status) plus payment configuration, the count is well-scoped for a payment/order platform. Each tool serves a necessary function without redundancy.
The tool surface is comprehensive: listing brands/products/eSIM plans, searching, getting prices and methods, validating and creating orders, and checking status. The flow from validate_order → create_order → get_order_status is complete, with fallback purchase_wizard covering widget-less scenarios. No major gaps.
