assetfare

assetfare_v2_quote_selected_candidate

Read-only

Reuses a selected route candidate’s valid request-time quote; after expiry, refreshes only that candidate at the same amount and never reselects.

Instructions

Reuse the chosen exact request-time quote while valid; after expiry refresh only that candidate at the same amount and never reselect. Example: pass candidate_id and the selection receipt hash. An AssetFare result requires a caller-local proof check and fresh wallet simulation before verified_for_signing; remote verification is not signing authority. An external result is only its provider handoff and has no AssetFare transaction-verification claim. Never prepares, signs, submits, or grants transaction authority.

Input Schema

Name	Required	Description
`profile`	No	Time policy: fast (30s), balanced (60s default), or explicit economy (60s). Every recommendation profile has an absolute 60-second ceiling.
`to_chain`	Yes	Destination chain for the v2 route: Solana, Base, Arbitrum, or Robinhood Chain. Source-only chains are not destinations.
`to_token`	Yes	Output token symbol on to_chain. The chain-token pair must appear in current v2 capabilities.
`amount_usd`	Yes	Requested input value in USD, minimum 1. USD 1 is reachability/schema smoke only. A USD 50 competitive bucket was observed only for dated 2026-09-23 Solana USDC to Base USDC evidence and must not be generalized to another corridor. USD 1,000 is the primary representative amount. SOL input includes a swap. Always quote the actual intended amount.
`from_chain`	Yes	Source chain for the v2 route. Polygon, Optimism, Ethereum, HyperEVM, X Layer, Sei, Sonic, Monad, Avalanche, Cronos, Injective, Linea, Aptos, Unichain, and Ink are source-only and cannot be used as to_chain.
`from_token`	Yes	Input token symbol on from_chain. The chain-token pair must appear in current v2 capabilities.
`candidate_id`	Yes	Exact candidate_id returned by assetfare_v2_route_selection; it is never chosen automatically.
`max_eta_seconds`	No	Optional stricter maximum ETA in seconds; it cannot exceed 60 or the selected profile limit.
`selection_receipt_sha256`	Yes	Exact selection_receipt.sha256 returned with the fresh shortlist.

Output Schema

Name	Required	Description	Default
`status`	Yes
`version`	Yes
`choice_binding`	Yes
`server_signing`	Yes
`execution_handoff`	Yes
`server_submission`	Yes
`selected_candidate`	Yes
`selection_quote_source`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.21.6Oct 26, 2026

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds meaningful context beyond the annotations: caller-local proof check and fresh wallet simulation are required before verified_for_signing, remote verification is not signing authority, and external results carry no AssetFare verification claim. The 'never prepares, signs, submits, or grants transaction authority' line reinforces the readOnly profile. With annotations already covering the safety surface, this is solid added value.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Leads with the core reuse/refresh behavior before the verification caveats, so the actionable part is front-loaded. The last two sentences overlap somewhat ('remote verification is not signing authority' vs 'never prepares, signs, submits'), a minor redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained. For a 7-required-parameter tool the description covers the reuse/refresh semantics and the verification boundary an agent must respect. Gaps are minor and largely covered by the rich schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 9 parameters thoroughly. The description only restates two required inputs (candidate_id and the receipt hash), adding no format or constraint detail beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: 'Reuse the chosen exact request-time quote while valid' and 'refresh only that candidate at the same amount and never reselect.' This clearly distinguishes it from a fresh-quote sibling like assetfare_v2_quote. It stops short of naming that sibling explicitly, so an agent must infer the alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete when-to-use context: reuse while valid, refresh only the chosen candidate after expiry, never reselect. The example ('pass candidate_id and the selection receipt hash') clarifies the call site. No explicit exclusion naming an alternative tool, which keeps it from a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.