Skip to main content
Glama
Sign In

OpenFinance — Easy Trading: Crypto, Stocks, Perps & Prediction Markets

by tech.openfinance
OverviewDiscussionsAdmin

onchain_jupiter_order

Jupiter Swap v2 — get a Solana SAME-CHAIN swap quote and unsigned transaction. Wraps GET https://api.jup.ag/swap/v2/order.

ROUTING — pick the right swap tool, do not guess: • Solana → Solana (same chain, both mints are SPL or wSOL): USE THIS TOOL (onchain_jupiter_order + onchain_jupiter_execute). • EVM ↔ EVM same chain (e.g. USDC → USDT on Polygon, ETH → USDC on Base): use relay_get_quote / relay_execute with originChainId === destinationChainId. • Any cross-chain (EVM ↔ EVM different chains, EVM ↔ Solana, Solana ↔ EVM, Solana ↔ BTC, etc.): use relay_get_quote / relay_execute. Never use Jupiter for non-Solana swaps; never use Relay for Solana same-chain swaps — Relay's Solana same-chain pricing is worse and Jupiter handles SPL routing natively.

PRE-SWAP CHECKLIST — do all six steps in order, do not skip. Stop and ask the user if any step is ambiguous.

  1. RESOLVE TOKEN ADDRESSES. If the user named a token by symbol/name ("buy PEPE", "swap into BONK") and not by mint, call onchain_search_tokens with the symbol (omit networkIds — search all chains, then filter the response to Solana entries only by checking each result's chain/network field). Pick the highest-liquidity / highest-marketCap match on Solana. If multiple candidates exist with similar liquidity, show the top 3 with priceUSD + marketCap + mint and ask the user which one. If the canonical match isn't on Solana, switch to relay_get_quote instead (per the routing rule above).

  2. DEFAULT THE OTHER SIDE TO wSOL. If the user only named one token (e.g. "buy PEPE for $50", "sell my BONK"), default the unspecified side to wrapped SOL So11111111111111111111111111111111111111112. Examples: "buy PEPE for $50 worth of SOL" → inputMint=wSOL, outputMint=PEPE_mint "sell 1000 BONK" → inputMint=BONK_mint, outputMint=wSOL For ANY swap where the counterparty wasn't explicit, wSOL is the default — never substitute USDC, USDT, or any other token unless the user explicitly asked.

  3. SHOW THE DEXSCREENER LINK. Before any quote, surface a DexScreener URL for the non-wSOL token so the user can verify the project / chart / liquidity: https://dexscreener.com/solana/<token_mint_lowercased> Example: https://dexscreener.com/solana/etmhxtenfkmk85tacveebzdbv9htziwzdsddmshrp2wb. Present it as a clickable line in your reply (the user clicks if they want to verify).

  4. ALWAYS SHOW MARKET CAP. Quote the marketCap from the search result inline (e.g. "PEPE on Solana — mcap $4.2M, liquidity $890K, 24h vol $2.1M"). Always — even for blue-chip tokens. Numbers anchor the user.

  5. WARN ON THIN / VOLATILE TOKENS. If marketCap < $10M OR |change24| > 30% OR liquidity < $250K, surface this verbatim BEFORE the confirmation prompt: ⚠️ THIN / VOLATILE TOKEN — has marketCap $, liquidity $, 24h change %. Slippage and rug risk are elevated. Only swap an amount you're willing to lose. Adjust the message wording slightly if only one of the conditions trips, but always include the three numbers.

  6. EXPLICIT CONFIRMATION GATE. Show input token + amount, output token + estimated amount (from the quote), price impact, slippage, route, DexScreener link, mcap, and any warning. Then ask the user "type 'yes' to confirm". Do not call onchain_jupiter_execute until they reply yes. For known blue chips (SOL, USDC, USDT, JUP, JTO, RAY, BONK with mcap >$100M), a brief summary + confirmation is enough; for everything else use the warning template above.

The caller's Privy Solana address is auto-filled as taker if you don't pass one — that's required by Jupiter for the response to include a signable transaction field. Returns the full Jupiter order: inAmount / outAmount / priceImpact / routePlan (route splits across AMMs) / fees / transaction (base64 UNSIGNED — sign + execute via onchain_jupiter_execute) / requestId (required by /execute) / lastValidBlockHeight. Amounts are in the smallest unit of inputMint (USDC has 6 decimals: 1000000 = 1 USDC; SOL has 9 decimals: 1000000000 = 1 SOL).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "inputMint": "<inputMint>",
      "outputMint": "<outputMint>",
      "amount": "<amount>"
    },
    "name": "onchain_jupiter_order"
  }
}

Input Schema

NameRequiredDescriptionDefault
payerNoAccount covering gas-related fees.
takerNoOverride the caller Solana address. Leave blank to use the caller wallet (required for a signable transaction).
amountYesAmount of inputMint to swap, in smallest unit (string-encoded integer).
receiverNoAccount that receives the output token. Must differ from taker if provided.
swapModeNoCurrently only ExactIn is supported.
inputMintYesSPL mint address of the token being sold (e.g. USDC = EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v, wSOL = So11111111111111111111111111111111111111112).
outputMintYesSPL mint address of the token being bought.
slippageBpsNoSlippage tolerance in basis points (50 = 0.5%). Default ~auto.
excludeDexesNoComma-separated DEX IDs to exclude from the Metis router.
excludeRoutersNoComma-separated router IDs to exclude.
jitoTipLamportsNo
broadcastFeeTypeNo
priorityFeeLamportsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations, the description carries the full disclosure burden and does well: the taker auto-fill, that the returned transaction is base64 UNSIGNED, the requestId requirement for /execute, and the smallest-unit amount convention are all disclosed. It never explicitly says the call is read-only / non-mutating (no state change until execute), and offers no rate-limit or failure-mode info, keeping it below a 5.

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?

Well front-loaded — purpose, then routing, then checklist, then return shape. However, the six-step pre-swap checklist is lengthy workflow/policy content that inflates the definition well beyond what is needed to select and invoke the tool, so it is not maximally tight.

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

Completeness5/5

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

For a 13-parameter, no-output-schema, no-annotation quote tool, the description covers everything an agent needs: routing, required pre-work, defaults, the returned fields (inAmount/outAmount/routePlan/transaction/requestId), and the downstream execute step. Nothing material is missing.

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

Parameters4/5

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

Schema coverage is already 77% and documents most fields, so the baseline is 3. The description adds real value on top: taker defaults to the caller's Privy Solana address and is required for a signable transaction, and the smallest-unit convention is spelled out with concrete decimal examples (USDC 6, SOL 9), which the schema does not give.

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

Purpose5/5

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

States a specific verb (get a quote/unsigned transaction), the exact resource (Jupiter Swap v2 order), and the scope (Solana SAME-CHAIN), plus the underlying endpoint. It explicitly distinguishes itself from the sibling relay_get_quote by chain and asset type, so an agent can route without opening either schema.

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

Usage Guidelines5/5

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

Provides an explicit routing block with when-to-use (Solana→Solana, SPL/wSOL mints), when-not (any cross-chain, any EVM case), and the exact alternative tools (relay_get_quote / relay_execute). It even states the negative heuristic (never Relay for Solana same-chain) and names the downstream pairing tool onchain_jupiter_execute.

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

All OpenFinance — Easy Trading: Crypto, Stocks, Perps & Prediction Markets toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources