Skip to main content
Glama

jupiter_swap

Destructive

Execute a token swap via Jupiter (non-custodial).

Without signed_transaction: returns an UNSIGNED base64 transaction for your wallet to sign + broadcast. With signed_transaction: broadcasts the caller-signed tx and returns tx_signature. amount is in base units of input_token. Includes the Crank technology service fee when a referral fee account is configured -- collected ON-CHAIN via Jupiter's platformFeeBps, deducted from swap output. Swaps are NOT additionally gated by x402 (that would double-charge the same fee), so payment_header stays a no-op here (jupiter_swap is not in x402 PAID_TOOLS). pay_in_crank is NO LONGER a no-op: the on-chain rate is now derived from this wallet's volume tier and $CRANK staker / pay-in-$CRANK / Crank Score discounts, so a discounted wallet is quoted a lower platformFeeBps -- the same schedule x402 applies to perps/lend/stake.

SECURITY: the output_token is run through multi-layer authenticity verification before any tx is built; an unverified/suspicious/fake token is blocked (UNVERIFIED_TOKEN). Set allow_unverified=true to trade an unverified token at your own risk (hard scam signals are never overridable).

venue_hint is ADVISORY, never required -- spot routes via Jupiter aggregation (the only spot venue today); an unknown hint raises, omitting it is unchanged from before.

Workflow: EXECUTE step -- deploy the directional/allocation leg after the risk phase capped the size. Non-custodial. Get a price first with get_quotes. See get_trading_workflow.

idempotency_key (optional): a client-generated UUID. Retrying the SAME call (build or broadcast) with the same key + same args replays the original result instead of re-executing -- guards against a timeout-then-retry double-swap. Reuse the SAME key across the build call and its signed_transaction broadcast retry (they dedupe independently); a NEW key means a genuinely new swap.

verify (default True): when broadcasting (signed_transaction supplied), await on-chain confirmation and re-read the output_token balance -- the response gains a verification block ({confirmed, slot, post_state, expected_vs_actual}). Gate follow-on decisions on verification.confirmed, never on tx_signature alone. Set False to skip for latency-sensitive callers. Verify any prior signature later with the standalone verify_transaction tool.

GEO GATE: when either leg is a tokenized security this call is geo-gated (Reg S = no US persons) and OFAC-screened, same control trade_equity enforces -- jurisdiction declares the caller's jurisdiction once (persisted for next time), ip is the caller's origin IP for the additional Reg-S IP layer. Non-security swaps are unaffected.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ipNo
amountYes
verifyNo
caller_idNo
venue_hintNo
input_tokenYes
jurisdictionNo
output_tokenYes
pay_in_crankNo
slippage_bpsNo
payment_headerNo
wallet_addressYes
idempotency_keyNo
allow_unverifiedNo
signed_transactionNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the destructiveHint annotation by disclosing non-custodial behavior, signature/broadcast semantics, on-chain fee collection, token authenticity checks, geo-gating, optional verification, and idempotency-key deduplication. This is a high level of behavioral disclosure for a dangerous swap operation.

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?

The description is long but well-structured and front-loaded with the most important distinction: unsigned transaction vs signed broadcast. Most sections serve a purpose given the 15-parameter surface, though some fee/governance detail could be tightened without losing essential guidance.

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 description covers the core operation, security, fees, idempotency, verification, and geo restrictions, and the output schema covers the return shape. The mainly remaining gaps are slippage_bps and caller_id, plus a slight assumption that the agent already understands the broader trading workflow.

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 description coverage is 0%, but the description compensates for most parameters: amount, signed_transaction, verify, venue_hint, idempotency_key, allow_unverified, jurisdiction, ip, payment_header, and pay_in_crank are all meaningfully explained. However, slippage_bps and caller_id are not described, and wallet_address is only implied from the signing workflow.

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?

Starts with a concrete verb and resource: 'Execute a token swap via Jupiter'. It clearly differentiates itself from sibling trading tools by naming the aggregation venue and the two modes of use: build an unsigned transaction or broadcast a caller-signed one.

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 clear workflow context: get a quote first with get_quotes, execute after the risk phase, see get_trading_workflow, and apply trade_control-like geo controls for tokenized securities. It also explains when payment_header is a no-op and when verify should or should not be used, giving explicit routing to the right behavior.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.2/5.0
Disambiguation2/5

Multiple tools overlap significantly: close_perp_position vs perp_close, get_leaderboard vs get_score_leaderboard vs get_strategy_leaderboard, get_venue_status vs get_all_venues_status, send_token_social vs bulk_send_social, and get_crank_score vs get_score. Several read-only tools have nearly identical purposes, and the descriptions do not always clarify boundaries.

Naming Consistency4/5

Most tools follow a consistent verb_noun snake_case pattern (get_balances, create_strategy, set_alert, list_webhooks). However, there are deviations like 'lst_swap', 'jupiter_swap', 'flash_loan', 'sr_backtest', and the use of both 'get_' and 'list_' for reads, plus category prefixes like 'perp_' and 'strategy_' that vary in order. Overall still readable and predictable.

Tool Count1/5

177 tools is an extreme count for any server, far exceeding the 25+ threshold for 'too many'. Even a full DeFi platform does not need this many separate operations; the surface is overwhelming and clearly not well-scoped.

Completeness3/5

The domain (Solana DeFi trading) is covered extensively across swaps, perps, lending, staking, strategies, signals, and support. However, there are notable gaps: no lend_withdraw, no direct way to close a lending position, no spot order cancellation (though aggregator-based swaps may not need it), and a general lack of tiered account management. The huge number of tools makes it hard to identify missing lifecycle steps.

Resources