Skip to main content
Glama

paraswap-mcp

An MCP server that builds token swaps and hands them over unsigned.

It quotes a swap on Paraswap v5 and returns the raw transactions (to / data / value) for someone else to execute — in practice, a Rustok self-custody wallet, where a human approves every transaction in a separate console before anything is signed.

This server holds no keys, signs nothing and sends nothing on-chain. It has no filesystem state and no secrets. The worst it can do is return a transaction you decline to sign.

Chains: Ethereum (1), Arbitrum One (42161), Base (8453).

Why it exists

An agent that can swap tokens usually needs a private key sitting in .env. The alternative on offer is usually an agent that cannot touch funds at all.

The middle rung — the agent acts on its own, but a human releases every transaction — needs the building of a transaction to be separate from the signing of it. This server is the building half. The signing half belongs to a wallet the agent does not control.

Related MCP server: @cryptoapis-io/mcp-signer

Install

The published image lands with the first release; until then, run from source (bottom of this section) — it needs nothing but Python 3.12+.

Pull the image (no Python install needed):

docker pull ghcr.io/rustok-org/paraswap-mcp:1.0.0

Register it as a stdio MCP server — for example, in an MCP client config:

{
  "mcpServers": {
    "paraswap": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "ghcr.io/rustok-org/paraswap-mcp:1.0.0"]
    }
  }
}

Podman works the same way; substitute podman for docker.

Running from source needs nothing but Python 3.12+ — the server imports only the standard library:

python3 paraswap_mcp.py

Configuration

Both variables are optional. Defaults are the three chains above.

Variable

Meaning

PARASWAP_ALLOWED_CHAINS

Comma-separated chain ids the server will serve, e.g. 1,42161. An empty or malformed value refuses to start — a server with zero chains is never intentional. To get the defaults, leave the variable unset.

PARASWAP_RPC_URLS_<id>

JSON-RPC endpoint used for the on-chain allowance check on that chain, e.g. PARASWAP_RPC_URLS_1. Public nodes are used when unset. Allowing a chain with no default and no override refuses to start.

The tool

build_swap_transaction — one call, one swap plan.

Input: chain_id, src_token, src_decimals, dest_token, dest_decimals, amount (human units, e.g. "5"), user_address. Optional: slippage_bps (default 250 = 2.5%), src_symbol / dest_symbol.

Output: a fresh quote, the allowance check, and an ordered list of raw transactions. When the wallet's current allowance to the Paraswap TokenTransferProxy is short, an exact-amount ERC-20 approve is prepended — never an unlimited one. If a partial allowance is already in place, a reset to zero comes first: USDT and the tokens that copied it revert an approve made over a non-zero allowance. Execute the transactions in the order returned.

{
  "chain": { "id": 42161, "name": "Arbitrum One" },
  "quote": {
    "src_amount": "5",
    "src_token": { "address": "0xaf88…5831", "chain_id": 42161 },
    "dest_amount_estimate": "0.002663",
    "dest_token": { "address": "0x82aF…Bab1", "chain_id": 42161 },
    "slippage_bps": 250,
    "note": "quote is fresh now and expires in minutes; execute promptly"
  },
  "allowance_check": { "spender": "0x216b…fcae", "approve_included": true },
  "transactions": [ { "purpose": "approve exactly …", "to": "…", "data": "0x…", "value": "0", "chain_id": 42161 } ]
}

Things this server deliberately does not promise

Read these before putting it in front of real money.

  • Quotes go stale in minutes. Build immediately before executing. If a human approval is going to take a while, build again afterwards rather than executing an old plan.

  • src_symbol / dest_symbol are your own labels, echoed back unverified. They are never read from the contract, and every echoed symbol is returned alongside "symbol_unverified": true. The address is the identity of a token; a screen shown to a human must not present these symbols as confirmed fact.

  • The spender comes from the live quote, never from a hardcoded address. The Paraswap TokenTransferProxy differs per chain, and approving the wrong contract wastes gas at best.

  • A wallet reporting "executed" means the transaction was broadcast, not that it succeeded on-chain. Verify the receipt independently (an explorer, or eth_getTransactionReceiptstatus must be 0x1) until the wallet you use checks receipts itself. A reverted swap still costs gas.

  • Prices, routes and liquidity come from Paraswap. This server does not audit them, and does not compare against other venues.

Development

uv run --with ruff ruff check paraswap_mcp.py test_paraswap_mcp.py
uv run --with ruff ruff format --check paraswap_mcp.py test_paraswap_mcp.py
uv run --with mypy mypy --strict paraswap_mcp.py
uv run --with pytest pytest -q

Tests never touch the network: the HTTP boundary is the only thing stubbed, and the swap-planning logic is exercised for real.

License

MIT-0 — see LICENSE. Use it without attribution.

Available Tools

1 tool
build_swap_transactionA

Build a token swap via Paraswap v5 on Ethereum (1), Arbitrum One (42161) or Base (8453). Returns an ORDERED list of raw transactions, each with to/data/value ready for wallet preview and execution: an exact-amount ERC-20 approve when the current allowance is short (preceded by a reset to zero when a partial allowance already exists — USDT-style tokens revert otherwise), then the swap. Execute them in order; do not reorder, skip or batch. Quotes are fetched fresh on every call and expire in minutes: build right before executing.

ParametersJSON Schema
NameRequiredDescriptionDefault
amountYesAmount to sell in human units, e.g. "5" or "0.25"
chain_idYesChain to swap on: 1 (Ethereum), 42161 (Arbitrum One) or 8453 (Base)
src_tokenYesERC-20 address of the token to sell (0x...)
dest_tokenYesERC-20 address of the token to buy (0x...)
src_symbolNoOptional display label for the source token. Echoed back verbatim and NEVER verified against the contract — it is your own label, not evidence. The address is the identity; do not present this symbol to a human as a confirmed fact.
dest_symbolNoOptional display label for the destination token. Echoed back verbatim and NEVER verified against the contract — same rule as src_symbol: the address is the identity.
slippage_bpsNoMax slippage in basis points, default 250 (= 2.5%)
src_decimalsYesDecimals of the source token (e.g. USDC = 6)
user_addressYesWallet address that will sign the transactions (0x...)
dest_decimalsYesDecimals of the destination token (e.g. WETH = 18)

TDQS

A4.7/5.0
Behavior5/5

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

Despite having no annotations, the description reveals key behavioral details: it returns raw transactions, includes an approve step when allowance is short, and handles the USDT-style reset-to-zero case. It also discloses that quotes are fetched fresh and expire, which affects when the tool should be called.

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

Conciseness5/5

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

The description is moderately long but every sentence serves a purpose: scope, return format, approve nuance, execution order, and quote freshness. It is front-loaded with the primary action and structured logically, with no filler.

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?

Given there is no output schema and no annotations, the description adequately explains the return value (list of transactions with to/data/value) and the required execution behavior. It also covers the quoting lifecycle. This is sufficient for an agent to correctly invoke the tool and interpret its result.

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?

All 10 parameters have thorough descriptions in the schema (100% coverage), including warnings about the src_symbol and dest_symbol not being verified. The description itself adds no extra parameter-specific details, so the baseline score of 3 is appropriate.

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?

The description clearly identifies the action ('Build a token swap'), the specific integration (Paraswap v5), supported chains, and the nature of the return value (an ordered list of raw transactions). This is more specific than a generic verb and distinguishes the tool from any potential alternative by naming the protocol and chains.

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?

It explicitly tells the agent to build right before executing because quotes expire in minutes, and provides a direct instruction on how to handle the returned transactions: execute them in order, do not reorder, skip or batch. While no alternative tools are listed, the guidance on timing and ordering is explicit and actionable.

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

TDQS

A4.5/5.0
Disambiguation5/5

Only one tool exists, so there is no possibility of confusion between tools. The tool's purpose is clearly and specifically stated.

Naming Consistency5/5

The single tool uses a clear verb_noun pattern ('build_swap_transaction'). There are no other tools to introduce inconsistency.

Tool Count2/5

One tool is too few for a server that might be expected to provide a broader range of swap-related operations (e.g., quoting, token info). The scope feels thin.

Completeness4/5

The tool covers the core swap workflow by returning ordered transactions including approval and swap. However, it lacks separate quote retrieval or token discovery capabilities, which are minor gaps for a swap-focused server.

Maintenance

ActivityMaintained
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/rustok-org/paraswap-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server