The deBridge MCP server enables AI agents to perform cross-chain and same-chain cryptocurrency swaps and transfers across major blockchain networks.
Get Instructions: Retrieve a full guide on using the server, including recommended workflows for initiating swaps, estimating pricing, and generating transaction links.
Search Tokens: Look up tokens by name, symbol, or contract address to resolve them to contract addresses, with optional filtering by chain ID.
Get Supported Chains: List all blockchain networks supported by deBridge (e.g., Ethereum, BNB Chain, Arbitrum, Solana, Polygon) along with their chain IDs.
Create Transaction: Build a cross-chain swap transaction via the deBridge DLN protocol, specifying source/destination chains, tokens, amounts, recipient addresses, and optional affiliate fees — returns transaction data ready to be signed and submitted.
Generate dApp URL: Produce a deBridge app URL so users can complete a cross-chain swap directly in their browser, with configurable input/output chains, tokens, and amounts.
deBridge MCP integration for AI agents — cross-chain and same-chain swaps, fee estimation, and trade execution across major blockchain networks.
The hosted MCP endpoint is available at agents.debridge.com. This npm package is a thin proxy client for agents that require a local stdio or HTTP process.
https://github.com/user-attachments/assets/8ebe88ff-db3c-455e-9efb-50389e4bf5bd
Connect your agent directly to the hosted endpoint — no installation, no local process:
https://agents.debridge.com/mcpThis is a Streamable HTTP MCP endpoint. It exposes tools (get_instructions, search_tokens, get_supported_chains, create_tx, transaction_same_chain_swap), workflow skills via MCP resources, and an llms.txt overview. Tools and skills are maintained in the debridge-finance/debridge-skills repository.
Generic Streamable HTTP configuration:
"debridge": {
"type": "streamable-http",
"url": "https://agents.debridge.com/mcp"
}claude mcp add debridge --transport http https://agents.debridge.com/mcpVerify:
claude mcp listAdd as a remote MCP server with the URL https://agents.debridge.com/mcp.
Add to .cursor/mcp.json in your project or ~/.cursor/mcp.json globally:
{
"mcpServers": {
"debridge": {
"url": "https://agents.debridge.com/mcp"
}
}
}Add to .vscode/mcp.json in your workspace:
{
"mcpServers": {
"debridge": {
"type": "streamable-http",
"url": "https://agents.debridge.com/mcp"
}
}
}Add to ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"debridge": {
"type": "streamable-http",
"url": "https://agents.debridge.com/mcp"
}
}
}Open Cline settings in VS Code, go to MCP Servers, click "Edit MCP Settings" and add:
{
"mcpServers": {
"debridge": {
"type": "streamable-http",
"url": "https://agents.debridge.com/mcp"
}
}
}Add to ~/.continue/config.json:
{
"mcpServers": [
{
"name": "debridge",
"transport": "streamable-http",
"url": "https://agents.debridge.com/mcp"
}
]
}Add to your Zed settings (~/.config/zed/settings.json):
{
"context_servers": {
"debridge": {
"transport": "streamable-http",
"url": "https://agents.debridge.com/mcp"
}
}
}Install the mcp-adapter plugin:
openclaw plugins install mcp-adapterAdd to ~/.openclaw/openclaw.json:
{
"plugins": {
"entries": {
"mcp-adapter": {
"enabled": true,
"config": {
"servers": [
{
"name": "debridge",
"transport": "streamable-http",
"url": "https://agents.debridge.com/mcp"
}
]
}
}
}
}
}Some agent frameworks only support stdio transport and cannot connect to a remote HTTP endpoint directly. This npm package bridges that gap — it runs a local MCP process that transparently proxies all requests to https://agents.debridge.com/mcp.
Tools and resources are not implemented locally. They are dynamically discovered from the upstream endpoint at startup (stdio) or forwarded per-request (HTTP), so any changes to the hosted MCPd are reflected automatically without updating the package.
Stdio mode (default): Opens a long-lived MCP client connection to the upstream MCPd via StreamableHTTPClientTransport. Creates a local Server with StdioServerTransport that mirrors the upstream capabilities and forwards tools/list, tools/call, resources/list, resources/read, and resources/templates/list to the upstream.
HTTP mode (MCP_TRANSPORT=http): Transparent HTTP reverse proxy via Express. Forwards raw JSON-RPC requests and SSE response streams to the upstream MCPd, passing through Mcp-Session-Id headers for session continuity.
npx -y @debridge-finance/debridge-mcp@lateststdio configuration:
"debridge": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@debridge-finance/debridge-mcp@latest"]
}claude mcp add debridge npx -- -y @debridge-finance/debridge-mcp@latestUse Cursor Deeplink: 
OR install from Cursor Directory
OR add to .cursor/mcp.json:
{
"mcpServers": {
"debridge": {
"command": "npx",
"args": ["-y", "@debridge-finance/debridge-mcp@latest"]
}
}
}docker build -t debridge-mcp .
docker run -p 3000:3000 debridge-mcpThen connect your agent to http://localhost:3000/mcp using the Streamable HTTP configs above.
Variable | Default | Description |
|
| Remote MCP endpoint to proxy to |
|
| Transport mode: |
|
| HTTP listen port (HTTP mode only) |
|
| HTTP listen host (HTTP mode only) |
Related MCP server: persistenceone-bridgekitty
# Install dependencies
npm install
# Run in dev mode (stdio proxy)
npm run dev
# Run in dev mode (HTTP proxy)
npm run dev:http
# Test with MCP Inspector
npm run inspect
# Run tests
npm test
MIT, Copyright 2026 deBridge
Create a cross-chain swap transaction via the deBridge DLN protocol
| Name | Required | Description | Default |
|---|---|---|---|
| srcChainId | Yes | Source chain ID | |
| srcChainTokenIn | Yes | Token address on source chain | |
| srcChainTokenInAmount | Yes | Amount in smallest units (wei, lamports) | |
| dstChainId | Yes | Destination chain ID | |
| dstChainTokenOut | Yes | Token address on destination chain | |
| dstChainTokenOutRecipient | Yes | Wallet address on destination chain to receive tokens | |
| srcChainOrderAuthorityAddress | Yes | Address on source chain authorized to manage the order | |
| dstChainOrderAuthorityAddress | Yes | Address on destination chain authorized to manage the order | |
| dstChainTokenOutAmount | No | Output amount or 'auto' for best quote | |
| affiliateFeePercent | No | Affiliate fee percentage | |
| affiliateFeeRecipient | No | Wallet address to receive affiliate fees | |
| prependOperatingExpenses | No | Whether to prepend estimated operating expenses to the input amount |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description only says 'create', which implies mutation. It omits critical behavioral details like side effects (e.g., gas fees, wallet approval) for a blockchain transaction, leaving the agent with little insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no filler, efficiently communicates the tool's primary purpose, and is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a 12-parameter cross-chain swap transaction, the description is too brief; it lacks information about return values, error handling, or workflow steps, making it incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-documented in the schema. The description does not add extra meaning beyond 'create', but since the schema already covers parameter semantics, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a cross-chain swap transaction via the deBridge DLN protocol, with a specific verb and resource, and distinguishes it from siblings like transaction_same_chain_swap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, no prerequisites or context provided; the description does not help differentiate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the full guide for the deBridge MCP server. CALL THIS FIRST.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description accurately describes the tool's behavior (returns a guide) with no side effects. This is sufficient for a read-only, zero-parameter tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Directly states purpose and usage priority.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description is complete for a simple guide tool without output schema or parameters. Could possibly mention the format of the guide, but not necessary for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters and 100% coverage. Description adds no parameter info, which is acceptable since none exist. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns the full guide for the deBridge MCP server, using a specific verb and resource. It also adds a usage hint ('CALL THIS FIRST'), distinguishing it from sibling tools that perform actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call this tool first, providing clear usage context. No need for when-not or alternatives given the simple nature of the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all blockchain networks supported by deBridge for cross-chain swaps
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It correctly indicates a read-only list operation but does not disclose any behavioral traits like caching, rate limits, or data freshness. Adequate for a trivial tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that fully communicates the tool's purpose without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema list tool, the description is entirely sufficient to understand its functionality and context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the description does not need to add meaning beyond the schema. Baseline for zero parameters is 4, and the description succinctly covers what the tool returns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('blockchain networks supported by deBridge for cross-chain swaps'), clearly distinguishing it from sibling tools like create_tx or transaction_same_chain_swap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no context on when to use this tool versus alternatives, nor any exclusions or prerequisites. For a simple list tool, minimal guidance is acceptable but not provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for tokens by name, symbol, or contract address in the deBridge token database
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Token name, symbol, or contract address | |
| chainId | No | Filter by chain ID | |
| name | No | Filter by token name (partial, case-insensitive) | |
| limit | No | Max results (default 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description states it searches the deBridge database but omits details like read-only nature, result format, pagination, or rate limits. Basic disclosure but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with verb, resource, and searchable fields. No wasted words, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core purpose but lacks output format, pagination, and limitations. Adequate for a simple search but not fully complete given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with descriptions. Description adds no additional meaning beyond them; baseline 3 for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'search', resource 'tokens', and searchable fields (name, symbol, contract address). Distinguishes from sibling tools which deal with transactions and chains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage for token lookups; siblings are clearly different (transactions, instructions, chains). No explicit exclusions but context sufficiently separates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a same-chain token swap transaction via deBridge
| Name | Required | Description | Default |
|---|---|---|---|
| chainId | Yes | Chain ID (native or deBridge internal) | |
| tokenIn | Yes | Input token address | |
| tokenInAmount | Yes | Amount in smallest units | |
| tokenOut | Yes | Output token address | |
| tokenOutRecipient | Yes | Address on the source chain to receive target tokens | |
| slippage | No | Slippage tolerance or 'auto' | |
| tokenOutAmount | No | Expected output amount or 'auto' | |
| affiliateFeePercent | No | Affiliate fee percentage | |
| affiliateFeeRecipient | No | Wallet address to receive affiliate fees | |
| senderAddress | No | Transaction submitter address | |
| srcChainPriorityLevel | No | Priority level: 'normal' or 'aggressive' (default: 'normal') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It does not mention side effects, permissions, whether the transaction is submitted or just prepared, gas costs, or any other behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence, front-loaded with verb and resource, no unnecessary words. Every part is essential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 parameters, no output schema, and no annotations, the description fails to provide sufficient context. It does not explain how to construct the parameters, what the output looks like, or how to handle errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the schema's property descriptions; it simply restates the tool's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create', the resource 'same-chain token swap transaction', and the platform 'via deBridge'. It distinguishes from sibling tools like search_tokens (search) and create_tx (likely general transaction).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no prerequisites, no when-not-to-use conditions. Description only states what it does, not how to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0create_tx11 fields changedInput schema / properties / affiliateFeePercent / descriptionPrevious value: -"Affiliate fee percentage (e.g. 0.1 for 0.1%)"New value: +"Affiliate fee percentage"Input schema / properties / dstChainId / descriptionPrevious value: -"Destination chain ID. Examples: '1' (Ethereum), '56' (BNB Chain), '42161' (Arbitrum)"New value: +"Destination chain ID"Input schema / properties / dstChainOrderAuthorityAddress / descriptionPrevious value: -"Address on the destination chain authorized to manage the order. Typically the recipient's wallet address"New value: +"Address on destination chain authorized to manage the order"Input schema / properties / dstChainTokenOut / descriptionPrevious value: -"Token address on the destination chain to receive"New value: +"Token address on destination chain"Input schema / properties / dstChainTokenOutAmount / defaultRemoved value: -"auto"Input schema / properties / dstChainTokenOutAmount / descriptionPrevious value: -"Output amount in smallest units, or 'auto' for best available quote (default: 'auto')"New value: +"Output amount or 'auto' for best quote"Input schema / properties / dstChainTokenOutRecipient / descriptionPrevious value: -"Wallet address on the destination chain that will receive the tokens"New value: +"Wallet address on destination chain to receive tokens"Input schema / properties / srcChainId / descriptionPrevious value: -"Source chain ID. Examples: '1' (Ethereum), '56' (BNB Chain), '137' (Polygon), '7565164' (Solana)"New value: +"Source chain ID"Input schema / properties / srcChainOrderAuthorityAddress / descriptionPrevious value: -"Address on the source chain authorized to manage the order (cancel, etc). Typically the sender's wallet address"New value: +"Address on source chain authorized to manage the order"Input schema / properties / srcChainTokenIn / descriptionPrevious value: -"Token address on the source chain to swap from. Use 0x0000000000000000000000000000000000000000 for native tokens (ETH, BNB, etc.)"New value: +"Token address on source chain"Input schema / properties / srcChainTokenInAmount / descriptionPrevious value: -"Amount of source token in smallest units (wei, lamports). Example: '1000000000000000000' for 1 ETH (18 decimals), '1000000' for 1 USDC (6 decimals)"New value: +"Amount in smallest units (wei, lamports)"get_instructions1 field changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"get_supported_chains1 field changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"get_trade_dapp_urlsearch_tokens4 fields changedInput schema / properties / chainId / descriptionPrevious value: -"Filter by chain ID. Examples: '1' (Ethereum), '42161' (Arbitrum), '7565164' (Solana)"New value: +"Filter by chain ID"Input schema / properties / limit / defaultRemoved value: -10Input schema / properties / name / descriptionPrevious value: -"Filter by token name (partial, case-insensitive). Examples: 'coin', 'ether'"New value: +"Filter by token name (partial, case-insensitive)"Input schema / properties / query / descriptionPrevious value: -"Token name, symbol, or contract address. Examples: 'USDC', 'ethereum', '0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48'"New value: +"Token name, symbol, or contract address"transaction_same_chain_swapv0.1.3create_txget_instructionsget_supported_chainsget_trade_dapp_urlsearch_tokensScored across 5 tools
Each tool has a distinct purpose: cross-chain swap, same-chain swap, chain listing, token search, and a guide. No overlaps.
Most tools follow verb_noun pattern with underscores, but 'transaction_same_chain_swap' uses 'transaction' as a verb which is slightly less conventional, though still consistent in style.
5 tools is well-scoped for a cross-chain bridge server, covering core operations and utilities without bloat.
Covers essential functions: cross-chain and same-chain swaps, chain and token discovery. Lacks status tracking or fee estimation, but the guide tool may compensate.
Non-custodial cross-chain crypto swap MCP — 1288+ assets, no KYC. Solana/EVM/Monero, RPC, oracle.
Li.Fi MCP: cross-chain aggregation — quotes, routes, status, chains, tokens, execution.
Cross-chain swap aggregator across 16+ chains, incl. native Bitcoin/Solana. 0% fees, non-custodial.
Li.Fi tools over MCP: cross-chain quotes, routes, execution status, chains, tokens, balances.
