assetfare

assetfare_v2_session_create

Idempotent

Create a caller-approved receipt-driven workflow and get its unsigned action for multi-step execution without signing or submitting transactions.

Instructions

Create one caller-approved receipt-driven workflow and return its current unsigned action. Example: pass a locally generated 256-bit base64url session_token, public wallets, and idempotency_key='create-0001'. Use for multi-step execution, never alongside one-shot prepare; AssetFare never signs or submits.

Input Schema

TableJSON Schema

Name	Required	Description
`wallets`	Yes	Map each chain needed by this route to the caller's public wallet address. Include public addresses only; one to six entries, never private keys or seed phrases.
`to_chain`	Yes	Destination chain for the v2 route: Solana, Base, Arbitrum, or Robinhood Chain. Polygon and Optimism 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; USD 50 is the native-USDC economic-comparison start based on dated 2026-09-23 evidence, not a cheapest guarantee; 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 and Optimism 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.
`session_token`	Yes	Sensitive caller-generated v2 session capability: at least 32 CSPRNG bytes encoded as 43-128 URL-safe base64 characters. Generate it locally; never log it or substitute a private key or legacy access token.
`caller_approved`	Yes	Explicit confirmation that the caller approved this state-changing preparation or session creation. A quote alone is not approval.
`idempotency_key`	Yes	Caller-generated retry key, 8-128 characters. Reuse it only when retrying the same logical mutation; choose a new key for a new operation.
`event_signer_public`	No	Solana CCTP only: caller-generated ephemeral public key. Keep the matching private key client-side and use it to co-sign the returned unsigned event-account transaction; never send the private key.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`signed`	Yes
`status`	Yes
`submitted`	Yes
`session_id`	Yes
`current_action`	Yes
`server_signing`	Yes
`action_available`	Yes
`server_submission`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 24, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavior: it creates a state-changing session, returns an unsigned action, and explicitly states 'AssetFare never signs or submits.' It also clarifies the idempotency key and approval semantics. This goes beyond what annotations convey, exposing core operational boundaries without contradicting them.

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?

Two sentences plus an example. The example is compact and informative, and the negative guidance ('never alongside one-shot prepare', 'never signs or submits') is efficient. It is slightly dense with terms like 'receipt-driven' that are not defined, but overall it earns its place and front-loads the core purpose.

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?

The tool has 10 params, nested wallets object, output schema, and rich annotations. The description covers the workflow type, approval gating, idempotency, and the no-signing/no-submission boundary. It does not explain what 'receipt-driven' means or fully map the returned unsigned action's role, but the output schema and sibling tools (session_get, refresh_action) provide surrounding context. Adequate for a complex creation tool.

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 baseline is 3. The description adds a useful example (session_token, wallets, idempotency_key) and calls out the semantic distinction that amount_usd is a requested input, not a guaranteed quote. It does not deepen understanding of each parameter since the schema already documents them thoroughly. Meets the baseline without exceptional added value.

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?

The description states a specific action: 'Create one caller-approved receipt-driven workflow and return its current unsigned action.' It names resources (session, unsigned action, AssetFare) and gives an example. It does not explicitly distinguish from siblings by name, but the one-shot vs multi-step contrast and 'never signs or submits' help position it. Slight ambiguity remains around what 'receipt-driven' means for an agent encountering the tool cold.

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?

The description gives an example invocation pattern and explicitly says to use it for multi-step execution and 'never alongside one-shot prepare.' It names the alternative style ('one-shot prepare') but does not name the sibling tool assetfare_v2_prepare directly; the context signals show that sibling exists. It does not mention when to use session_get or refresh_action instead, but the primary routing decision is covered.

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