Trade Router vs Jupiter for AI Agents on Solana

Both are non-custodial swap APIs on Solana

If you only need swap a token, get an unsigned transaction back, sign it yourself, submit it — both APIs do that and neither ever sees your private key. Same security model, same on-chain settlement.

Feature comparison

"Buy 0.1 SOL of a token, MEV-protected"

This is the most common AI-agent task. Below is the same intent expressed against each API. We're not cherry-picking — both are the canonical paths.

Jupiter v6 (~3 stages, 2-3 API calls + manual Jito wiring)

// 1. Get a quote
const quote = await fetch(
  `https://quote-api.jup.ag/v6/quote?inputMint=So11111111111111111111111111111111111111112` +
  `&outputMint=TARGET_MINT&amount=100000000&slippageBps=100`
).then(r => r.json());

// 2. Build the unsigned swap tx
const { swapTransaction } = await fetch('https://quote-api.jup.ag/v6/swap', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    quoteResponse: quote,
    userPublicKey: WALLET_ADDRESS,
    wrapAndUnwrapSol: true,
    // For MEV protection you separately wire Jito here:
    prioritizationFeeLamports: { priorityLevelWithMaxLamports: { priorityLevel: 'veryHigh' } },
  }),
}).then(r => r.json());

// 3. Sign locally
const tx = VersionedTransaction.deserialize(Buffer.from(swapTransaction, 'base64'));
tx.sign([keypair]);

// 4. (Optional) submit through Jito directly for bundle inclusion
//    — separate SDK, separate endpoint, separate retry logic.
const sig = await jitoClient.sendBundle([tx]);

Trade Router (1 MCP tool call, MEV-protected by default)

// auto_swap = build + sign + submit-via-Jito in one call.
// MCP server signs with TRADEROUTER_PRIVATE_KEY (locally), submits via /protect.
{
  "tool": "auto_swap",
  "args": {
    "wallet_address": "WALLET_ADDRESS",
    "token_address": "TARGET_MINT",
    "action": "buy",
    "amount": 100000000,         // 0.1 SOL in lamports
    "slippage": 1500             // bps
  }
}

// Returns: { signature, balance_changes: { sol: -0.1, target: +N } }
// MEV protection is the default path, not a separate integration.

"Place a TWAP buy: 1 SOL split into 10 slices over 1 hour"

This is where the API shape diverges most. Jupiter has a DCA program but it's a separate on-chain account-creation flow with its own SDK. Trade Router exposes it as one WS-backed tool call.

// 1. Derive PDA
// 2. Build createDca instruction
// 3. Build deposit instruction
// 4. Sign + send tx
// 5. DCA program executes
//    on its own schedule
//
// Read the @jup-ag/dca-sdk
// docs for full account
// derivation + reclaim flow.

{
  "tool": "place_twap_order",
  "args": {
    "wallet_address": "W",
    "token_address": "T",
    "action": "twap_buy",
    "total_amount": 1000000000,
    "frequency": 10,
    "duration": 3600,
    "slippage": 1500
  }
}

How to pick honestly

Choose Jupiter when

• You're routing one-off swaps and need maximum DEX coverage (especially long-tail tokens that only live in obscure pools).
• You already have your own Jito client, your own retry logic, your own callback infrastructure, and just want the routing.
• You're building a UI for human traders (Jupiter has the deeper ecosystem of UI tooling).
• You want zero per-call fee and are happy to integrate the limit / DCA programs separately.

Choose Trade Router when

• You're building an AI agent and want one MCP tool that an LLM can call without you scaffolding 4 SDKs.
• You need the same call to handle swap + limit + trailing + TWAP + DCA + combo orders, with the same auth model and the same response shape.
• You want MEV protection on by default (not as a separate integration).
• You want the holdings endpoint that catches tokens standard RPC misses.
• You want WebSocket-driven order callbacks that are Ed25519-signed by the server (so your agent can trust order_filled events without re-querying chain state).

Run them together

These aren't mutually exclusive. A common pattern: Jupiter for tail-token routing, Trade Router for the agent-orchestration loop (limits, trailing stops, TWAP, MEV-protected execution on the four major DEXes). The non-custodial model is identical, so the same wallet works in both.

What each costs

Common questions

Is Trade Router a Jupiter wrapper?

No. Trade Router routes directly to Raydium, PumpSwap, Orca, and Meteora and submits via Jito. It does not call Jupiter's API. Routing logic and pool selection are independent.

Does the 1% fee mean my swaps are worse than Jupiter's?

Sometimes. On long-tail tokens where Jupiter routes through a DEX we don't, Jupiter will be better. On the four major Solana DEXes, the price difference is usually within the slippage you'd already accept, and Trade Router includes MEV protection that's a separate cost on Jupiter. Compare for your specific pair before committing — both APIs return the route and price up-front.

Why does Trade Router exist if Jupiter already routes Solana?

Different shape, different audience. Jupiter's primary customer is the human trader and the wallet UI. Trade Router's primary customer is the AI agent that wants one tool call per intent — including order types Jupiter doesn't expose as a single API (trailing stops, combo orders) and a built-in MEV-protected execution path.

Can I use both?

Yes. Same wallet, same non-custodial model. A common pattern is using Jupiter for one-off routing on tail tokens and Trade Router for the persistent order-management layer (limits, trailing, TWAP, callbacks).

Where's the source?

Trade Router MCP server source: github.com/TradeRouter/trade-router-mcp. It's a single ~85 KB .mjs file you can read end-to-end.

How do I install Trade Router as an MCP server?

npx -y @traderouter/trade-router-mcp

Or wire it into Claude Desktop / Cursor / Cline / any MCP client — see the MCP setup section on the home page.