payment_optimizerRank only integration-tested payment routes under explicit cost and latency constraints.; 0.003 USDC. Deterministic, evidence-bounded and signed.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Input schema / additionalPropertiesRemoved value: -trueInput schema / minPropertiesRemoved value: -1Input schema / requiredAdded value: +[]Input schema / examplesAdded value: +[
+ {
+ "policy": {
+ "max_latency_ms": 2000,
+ "max_total_atomic": 4000
+ },
+ "routes": [
+ {
+ "amount_atomic": 3000,
+ "fee_atomic": 10,
+ "id": "base-usdc",
+ "latency_ms": 800,
+ "production_tested": true,
+ "success_rate": 0.98
+ }
+ ]
+ }
+]Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior, so the safety profile is fully covered. The description adds genuine extra context — a 0.003 USDC invocation cost and that results are deterministic, evidence-bounded and signed — but 'evidence-bounded and signed' remains vague about what is actually verified or returned.
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?
Extremely short and front-loads the ranking purpose. Minor penalty for the malformed punctuation ('.; 0.003 USDC.') which makes the price fragment read as an afterthought rather than a deliberate cost disclosure.
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?
An output schema exists and annotations cover safety, so return values need not be explained. Still, for a paid ranking tool surrounded by overlapping routing siblings, the omission of sibling differentiation and of any explanation of the policy/routes input shape leaves the agent with meaningful gaps before calling it.
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 exposes zero declared parameters (required list is empty) and schema coverage is 100%, so the baseline is 4. The description does not explain the policy/routes structure shown in the schema example, but there is no formal parameter surface for it to document.
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?
States a specific verb and resource ('Rank ... payment routes') with clear scope qualifiers ('only integration-tested', 'under explicit cost and latency constraints'), so the agent knows it is an optimization/ranking operation. However, it never distinguishes itself from the very similar sibling 'payment_route_selector' or 'x402_quote_comparator', leaving ambiguity about which selector to call.
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?
No when-to-use or when-not-to-use guidance and no named alternatives, despite sitting in a cluster of near-identical routing siblings. The phrase 'only integration-tested' filters candidate inputs but says nothing about when this tool should be chosen over payment_route_selector or execution_cost_estimator.
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.