How do AI agents use Uniswap through Open Connector?

Your user connects Uniswap once with one of its cataloged authentication methods. Open Connector stores the credential in an encrypted vault and exposes Uniswap tools to your agent over MCP or a typed API, with credentials injected server-side on each call.

Is this a Uniswap MCP server?

Yes. Open Connector can serve Uniswap as a named MCP server with a scoped allowlist and a per-user connection URL, so any MCP client can call Uniswap actions with credentials injected server-side.

Where do Uniswap credentials live?

In your own infrastructure. Open Connector keeps credentials in its own vault and injects them at call time, so they never leave your environment.

Uniswap integration

Uniswap integration for AI agents.

Uniswap integration for AI agents with secure authentication and server-side credential injection. Open Connector runs the OAuth, seals the token in an encrypted vault, and serves Uniswap tools to your agent over MCP or a typed API — credentials injected server-side, every call audited, nothing leaving your infrastructure. Open source (AGPL-3.0) and self-hostable.

View source on GitHub All integrations →

What your agents can do

Real Uniswap actions, managed and audited.

Your user connects Uniswap once; your agent can then swap crypto on Ethereum, Base, Arbitrum, Polygon, Unichain and more. The DeFi platform trusted by millions — scoped to the OAuth permissions you grant and the tool allowlist you configure. Every action is least-privilege and written to a tamper-evident audit trail.

1
Your user grants Uniswap access once (OAuth) — the token lands in the vault.
2
Your agent calls a tool over MCP or the typed API; Open Connector injects the credential server-side.
3
Every routed call appends a hash-chained audit record — nothing leaves your infra.

Tools & triggers

Supported Uniswap tools.

27 tools are generated from the published Uniswap catalog. Descriptions are plain text; each action remains subject to its configured authentication and tool allowlist.

Showing 27 tools. All published catalog entries are included in this page's server-rendered HTML.

Get a quote: Requests a quote according to the specified swap parameters. This endpoint may be used to get a quote for a swap, a bridge, or a wrap/unwrap. The resulting response includes a quote for the swap and the proposed route by which the quote was achieved. The response will also include estimated gas fees for the proposed quote route. If the proposed route is via a Uniswap Protocol pool, the response may include a permit2 message for the swapper to sign prior to making a /swap request. The proposed route will also be simulated. If the simulation fails, the response will include an error message or `txFailureReason`. Certain routing options may be whitelisted by the requestor through the use of the `protocols` field. Further, the requestor may ask for the best price route or for the fastest price route through the 'routingPreference' field. Note that the fastest price route refers to the speed with which a quote is returned, not the number of transactions that may be required to get from the input token and chain to the output token and chain. Further note that all `routingPreference` values except for `FASTEST` and `BEST_PRICE` are deprecated. For more information on the `protocols` and `routingPreference` fields, see the [Token Trading Workflow](https://uniswap-docs.readme.io/reference/trading-flow#swap-routing) explanation of Swap Routing. API integrators using this API for the benefit of customer end users may request a service fee be taken from the output token and deposited to a fee collection address. To request this, please reach out to your Uniswap Labs contact. This optional fee is associated to the API key and is always taken from the output token. Note if there is a fee and the `type` is `EXACT_INPUT`, the output amount quoted will **not** include the fee subtraction. If there is a fee and the `type` is `EXACT_OUTPUT`, the input amount quoted will **not** include the fee addition. Instead, in both cases, the fee will be recorded in the `aggregatedOutputs` field. Native ETH on UniswapX: UniswapX routes (e.g. `DUTCH_V2`, `DUTCH_V3`, `PRIORITY`) can use native ETH as the input token by setting `tokenIn` to the native currency address (e.g. `0x0000000000000000000000000000000000000000`) and passing `x-erc20eth-enabled: true`. Native ETH input on UniswapX requires wallet support for EIP-7914, a smart wallet activated on your desired network, and a sufficient native allowance (set via /swap_7702 if x-erc20eth-enabled header is set to `true`). If these requirements are not met, UniswapX quotes for native input may be omitted and the response may fall back to `CLASSIC` routing instead.; swapping
Check swap approvals: Allows the requestor to check if the `walletAddress` has the required approval to transact the `token` up to the `amount` specified. If the `walletAddress` does not have the required approval, the response will include a transaction to approve the token spend. If the `walletAddress` has the required approval, the response will return the approval with a `null` value. If the parameter `includeGasInfo` is set to `true` and an approval is needed, then the response will include both the transaction and the gas fee for the approval transaction. Certain tokens may require that approval be reset before approving a new spend amount. If this condition is detected for the `walletAddress` and `token`, the response will include the necessary approval cancellation in the `cancel` paragraph. When `cancel` is not applicable, the paragraph will have a `null` value.; swapping
Create approval ERC-4337 UserOperation: Builds and returns an ERC-4337 v0.8 UserOperation that performs the ERC-20 approval (and any required allowance reset) needed before a swap. Paymaster fields and `signature` are left for the client to populate. When `sponsorshipInfo.sponsored` is `true`, the approval is tagged for sponsorship and a `paymasterServiceContext` envelope is returned for the client to forward to the paymaster.; swapping
Check LP token approvals: Checks whether the wallet has the required token approvals to perform an LP action (create, increase, decrease, or migrate). Returns any needed approval transactions. If `simulateTransaction` is set to `true`, the response will include gas fees for the approval transactions. The `action` field specifies which LP operation the approval is for. Different actions may require different approvals (e.g., V2 decrease requires approval of the LP token, V3 migrate requires approval of the V3 NFT).; liquidity-provisioning
Claim LP position fees: Claims accumulated trading fees from a V3 or V4 LP position. If `simulateTransaction` is set to `true`, the response will include the gas fee for the claim transaction. Note: V2 positions do not have claimable fees. V2 trading fees are automatically added to your LP token balance.; liquidity-provisioning
Create a classic (V2) LP position: Creates a full-range liquidity position in a Uniswap V2 pool. Specify the independent token and amount; the server computes the dependent token amount based on the current pool ratio. If `simulateTransaction` is set to `true`, the response will include the gas fee for the creation transaction.; liquidity-provisioning
Create an execution plan: Creates a multi-step execution plan for chained transactions. The plan breaks down complex multi-chain or multi-transaction flows into sequential steps that can be executed by the client. Each step includes the method (transaction, message signature, or batch calls), payload, and current status. The response includes the current step index to track progress through the plan.; chained-swapping
Create a V3 or V4 LP position: Creates a new LP position in a V3 or V4 pool (including full-range positions). You can create a position in an existing pool by providing `existingPool` parameters, or create a new pool by providing `newPool` parameters (fee, tick spacing, initial price, and optionally hooks for V4). The position's price range is specified via either `priceBounds` or `tickBounds`. The server computes the dependent token amount. If `simulateTransaction` is set to `true`, the response will include the gas fee.; liquidity-provisioning
Create swap ERC-4337 UserOperation: Builds and returns a partially-populated ERC-4337 v0.8 UserOperation for executing a swap (including wrap/unwrap and bridging) against the Uniswap Protocols. The response includes any required ERC-20 approval and Permit2 calls bundled into the UserOperation's `callData`. Paymaster fields are left empty for the wallet to populate via `pm_sponsorUserOperation` before signing and submitting to the bundler. The `signature` field contains a dummy value that the wallet must replace before submission.; swapping
Create swap EIP 5792 calldata: Create the EIP 5792 calldata for a swap transaction (including wrap/unwrap and bridging) against the Uniswap Protocols. If the `quote` parameter includes the fee parameters, then the calldata will include the fee disbursement. The gas estimates will be **more precise** when the response calldata would be valid if submitted on-chain.; swap-batching
Create swap EIP 7702 calldata: Create the EIP 7702 calldata for a swap transaction (including wrap/unwrap and bridging) against the Uniswap Protocols. If the `quote` parameter includes the fee parameters, then the calldata will include the fee disbursement. The gas estimates will be **more precise** when the the response calldata would be valid if submitted on-chain. Native ETH / UniswapX setup: When `x-erc20eth-enabled` is `true` and the input token is native ETH, the response may include an additional native approval call (e.g. an `approveNative` step) to enable ERC20-ETH (EIP-7914) spending for the wallet. This native allowance is a prerequisite for native ETH input on UniswapX (`/quote` then `/order`) for supported wallets.; swap-batching
Create swap calldata: Create the calldata for a swap transaction (including wrap/unwrap) against the Uniswap Protocols. If the `quote` parameter includes the fee parameters, then the calldata will include the fee disbursement. The gas estimates will be **more precise** when the the response calldata would be valid if submitted on-chain.; swapping
Decrease an LP position: Decreases liquidity in an existing position by a specified percentage. The server derives all position state (liquidity, fees, ticks) from on-chain data. Supports V2 (by token pair), V3, and V4 (by NFT token ID). If `simulateTransaction` is set to `true`, the response will include the gas fee.; liquidity-provisioning
Encode ERC-4337 UserOperation: Builds and returns a fully-populated ERC-4337 v0.8 UserOperation for the given batch of calls. When a `paymasterUrl` is provided the endpoint attempts gas sponsorship via the paymaster; the response indicates whether sponsorship was granted and includes sponsor metadata when available.; utilities
Get a limit order quote: Get a quote for a limit order according to the provided configuration.; swapping
Get gasless order status: Retrieve one or more gasless orders filtered, optionally filered by query param(s). The request must at minimum include one of the following parameters: `orderId`, `orderIds`, `orderStatus`, `swapper`, or `filler`.; swapping
Get an execution plan: Retrieves an existing execution plan by its ID. Returns the full plan with current status and all steps. If forceRefresh is set to true, the plan will be refreshed to check for any updates to step statuses. Note: Completed plans cannot be refreshed.; chained-swapping
Get supported chains: Returns the list of chains supported by the Trading API, including protocol contract addresses and the protocols and actions available on each chain.; utilities
Get bridgable tokens: Returns the list of destination bridge chains for a given token on a given chain.; utilities
Get swap status: Get the status of swap or bridge transactions. Accepts on-chain transaction hashes (`txHashes`), ERC-4337 userOperation hashes (`userOpHashes`), or both. At least one of the two must contain at least one item.; swapping
Increase an LP position: Increases liquidity in an existing position. Specify the independent token and amount; the server derives the dependent token amount from the current pool state. Supports V2 (by token pair), V3, and V4 (by NFT token ID). If `simulateTransaction` is set to `true`, the response will include the gas fee.; liquidity-provisioning
Check token KYC permissions: For each token in the request, reports whether the token requires a permissioned adapter and whether the supplied `walletAddress` is allowlisted to trade it. If the token is permissioned but the wallet is not allowlisted, the response includes a `kycUrl` the wallet holder must complete to gain access. The request supports a maximum of 2 tokens.; utilities
Get pool state: Fetches detailed information about one or more liquidity pools across Uniswap V2, V3, and V4. Returns pool state including token addresses, reserves, liquidity, current tick, sqrtRatioX96, fee tier, tick spacing, and hook addresses (V4). Provide one of `poolParameters` or `poolReferences` (not both): - `poolParameters`: Look up pools by token pair. Provide token addresses and optional fee/tickSpacing/hooks to find matching pools. - `poolReferences`: Look up specific known pools by their reference identifier (pool address for V3, pool ID for V4, pair address for V2). Limited to 20 references per request; larger batches are rejected with a 400 RequestValidationError. Pool reserves (`token0Reserves`/`token1Reserves`) are returned for V2 pools and, best-effort, for V4 pools. V4 reserves are the fee-excluded core principal computed from on-chain pool state: uncollected LP fees, donations, and hook-held assets are excluded, and for pools whose hooks perform custom accounting the value approximates swappable reserves.; utilities
Create a gasless order: The order endpoint is used to submit a UniswapX intent. If the `routing` field in the response to a quote is any of `DUTCH_V2`, `DUTCH_V3`, `LIMIT_ORDER`, or `PRIORITY` this endpoint is used to submit your order to the UniswapX protocol to be filled by the filler network. These orders are gasless because the filler will pay the gas to complete the transaction. The order will be validated and, if valid, will be submitted to the filler network. The network will try to fill the order at the quoted `startAmount`. If the order is not filled at the `startAmount` by the `deadline`, the amount will start decaying until the `endAmount` is reached. The order will remain `open` until it is either filled, canceled, or has expired by remaining unfilled beyond the `decayEndTime`. For simplicity, the order request is identical to the quote response except for the addition of the signed permit. Native ETH on UniswapX: If the quote you are submitting uses native ETH as the input token (e.g. `tokenIn` is `0x0000000000000000000000000000000000000000`), include `x-erc20eth-enabled: true`. Native ETH input on UniswapX requires wallet support for EIP-7914 and sufficient native allowance. For 7702-delegated smart contract wallets, you can generate the required approval call(s) via `/swap_7702` when needed.; swapping
Update an execution plan: Updates an existing execution plan by submitting proof of completed plan steps (transaction hashes or signatures). The endpoint retrieves the existing plan, attaches proofs to specified steps, verifies the proofs, and potentially regenerates remaining steps if needed. Returns the full updated plan with current status. Note: Order IDs are not accepted in requests; they are system-generated after receiving a signature.; chained-swapping
Get wallet delegations: Gets the current delegation status and message for a smart contract wallet across different chains. Returns delegation information for each chain ID in the request.; utilities
Encode wallet transactions: Encodes a list of transactions into a single transaction for an EIP-7702 delegated smart contract wallet. All transactions must have the same chainId.; swap-batching

FAQ

Uniswap integration, answered

How do AI agents use Uniswap through Open Connector?: Your user connects Uniswap once with one of its cataloged authentication methods. Open Connector stores the credential in an encrypted vault and exposes Uniswap tools to your agent over MCP or a typed API, with credentials injected server-side on each call.
Is this a Uniswap MCP server?: Yes. Open Connector can serve Uniswap as a named MCP server with a scoped allowlist and a per-user connection URL, so any MCP client can call Uniswap actions with credentials injected server-side.
Where do Uniswap credentials live?: In your own infrastructure. Open Connector keeps credentials in its own vault and injects them at call time, so they never leave your environment.

Give your agents Uniswap — keep the keys.

Open source, self-hostable, with Uniswap credentials that never leave your infrastructure. Run it from source today.

View source on GitHub How the MCP gateway works →