What can you do with this server?

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

Official

by debridge-finance

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

deBridge MCP

MCP Endpoint llms.txt Skills npm version MCP Registry License: MIT TypeScript Node.js GitHub Stars

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

Connecting to deBridge MCP

Recommended: Direct connection (Streamable HTTP)

Connect your agent directly to the hosted endpoint — no installation, no local process:

https://agents.debridge.com/mcp

This 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/mcp

Verify:

claude mcp list

Add 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-adapter

Add to ~/.openclaw/openclaw.json:

{
  "plugins": {
    "entries": {
      "mcp-adapter": {
        "enabled": true,
        "config": {
          "servers": [
            {
              "name": "debridge",
              "transport": "streamable-http",
              "url": "https://agents.debridge.com/mcp"
            }
          ]
        }
      }
    }
  }
}

Alternative: Run a local proxy

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.

How the proxy works

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 (stdio)

npx -y @debridge-finance/debridge-mcp@latest

stdio configuration:

"debridge": {
  "type": "stdio",
  "command": "npx",
  "args": ["-y", "@debridge-finance/debridge-mcp@latest"]
}

claude mcp add debridge npx -- -y @debridge-finance/debridge-mcp@latest

Use Cursor Deeplink: Install MCP Server

OR install from Cursor Directory

OR add to .cursor/mcp.json:

{
  "mcpServers": {
    "debridge": {
      "command": "npx",
      "args": ["-y", "@debridge-finance/debridge-mcp@latest"]
    }
  }
}

Docker (HTTP proxy)

docker build -t debridge-mcp .
docker run -p 3000:3000 debridge-mcp

Then connect your agent to http://localhost:3000/mcp using the Streamable HTTP configs above.

Environment Variables

Variable	Default	Description
`REMOTE_MCP_URL`	`https://agents.debridge.com/mcp`	Remote MCP endpoint to proxy to
`MCP_TRANSPORT`	`stdio`	Transport mode: `stdio` or `http`
`PORT`	`3000`	HTTP listen port (HTTP mode only)
`HOST`	`0.0.0.0`	HTTP listen host (HTTP mode only)

Related MCP server: persistenceone-bridgekitty

Development

# 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

License

Available Tools

5 tools

create_txBInspect

Create a cross-chain swap transaction via the deBridge DLN protocol

ParametersJSON Schema

Name	Required	Description
`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

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided; description only says 'Create' without detailing side effects, permissions, or costs. Minimal behavioral context.

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?

Single sentence, front-loaded with purpose. Efficient but omits important context for conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema or annotations; does not explain return values, errors, or behavior for a complex 12-parameter tool.

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?

Schema coverage is 100% with descriptions; the tool description adds no extra meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it creates a cross-chain swap transaction via deBridge DLN protocol, distinguishing it from same-chain sibling tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for cross-chain swaps, contrasting with a same-chain sibling, but lacks explicit when-to-use or when-not-to-use guidance.

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

get_instructionsAInspect

Returns the full guide for the deBridge MCP server. CALL THIS FIRST.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations, the description must disclose all behavioral traits. It states the tool returns a guide, but does not specify the format (e.g., text, JSON) or any side effects. For a simple read tool, this is adequate but lacks detail.

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?

Two sentences, zero wasted words. The purpose is stated first, followed by a critical usage directive. Ideal for quick consumption.

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?

Given no parameters, no output schema, and low tool complexity, the description covers the essential facts: what it returns and when to use it. Could mention the guide's content type, but overall sufficient.

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?

The input schema is empty (100% coverage), so no parameter documentation is needed. The description adds no param info, but the baseline of 4 is appropriate since schema already covers all parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns the full guide for the deBridge MCP server, providing a specific verb and resource. It implicitly distinguishes from siblings by instructing to call this one first, though it does not explicitly differentiate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The instruction 'CALL THIS FIRST' explicitly tells the agent when to use this tool before others. No exclusions or alternatives are needed given its meta-role, but the guidance is clear and actionable.

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

get_supported_chainsAInspect

List all blockchain networks supported by deBridge for cross-chain swaps

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior3/5

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

The description indicates a read-only operation with no side effects. However, it does not disclose potential behavior like network caching, rate limits, or return format details, which is acceptable given the tool's simplicity.

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 a single, concise sentence that fully conveys the tool's purpose without unnecessary words or structure. It is front-loaded and efficient.

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 is adequate for a simple, parameterless tool. While it does not specify the exact output format (e.g., list of chain names vs. objects), the purpose is clear and likely sufficient for an AI agent to select and invoke the tool.

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?

With zero parameters, the description adds all necessary meaning beyond the empty schema. It clarifies that the tool returns a list of supported blockchain networks, which is sufficient for invocation.

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 uses a specific verb 'List' and clearly identifies the resource 'all blockchain networks supported by deBridge for cross-chain swaps'. It distinguishes the tool from siblings like create_tx and search_tokens, which serve different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool should be used when needing a list of supported chains for cross-chain swaps. It does not explicitly state when not to use it, but the sibling tools are functionally distinct, reducing ambiguity.

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

search_tokensBInspect

Search for tokens by name, symbol, or contract address in the deBridge token database

ParametersJSON Schema

Name	Required	Description
`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)

TDQS

B3.3/5.0

Behavior2/5

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

No annotations provided, so the description must fully disclose behavioral traits. It does not mention any side effects, authentication needs, rate limits, or whether it is read-only. Simply stating the search operation lacks depth.

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?

Single sentence of 18 words, front-loaded with the core action. No extraneous information; every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the basic purpose but lacks information about return values, pagination (limit parameter), or example usage. Given no output schema, more context on results would be helpful.

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?

Schema coverage is 100%, so parameters are already documented. The description adds marginal value by summarizing search criteria, but does not provide additional meaning beyond the schema.

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 explicitly states the action ('Search for tokens') and the resource ('deBridge token database'), with specific search criteria (name, symbol, contract address). It clearly distinguishes from sibling tools like create_tx or get_instructions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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, such as when to filter by chainId vs name, or any prerequisites. The description only states what it does.

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

transaction_same_chain_swapBInspect

Create a same-chain token swap transaction via deBridge

ParametersJSON Schema

Name	Required	Description
`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')

TDQS

B3.4/5.0

Behavior2/5

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

No annotations provided, and description merely states creation without disclosing side effects, permissions, failure modes, or post-creation steps (e.g., signing/submission). Minimal behavioral disclosure for a mutation tool.

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?

Single sentence, no fluff, directly communicates the tool's purpose. Efficient and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Description is too brief for a complex tool with 11 parameters. No information on expected output, transaction lifecycle, or integration steps. Output schema is missing, so agent lacks guidance on what the tool returns.

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?

Schema description coverage is 100%, so all parameters are documented in the schema. The tool description does not add extra semantic value beyond what the schema already provides.

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?

Description clearly specifies verb 'Create', resource 'same-chain token swap transaction', and method 'via deBridge'. Distinguishes from sibling tools like create_tx which may be more general.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool vs alternatives like create_tx. Usage is implied by the tool name and description but lacks context about appropriate scenarios.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesv0.1.0Apr 29, 2026

Changedcreate_tx11 fields changed

changedInput schema / properties / affiliateFeePercent / description

Previous value: -"Affiliate fee percentage (e.g. 0.1 for 0.1%)"New value: +"Affiliate fee percentage"

changedInput schema / properties / dstChainId / description

Previous value: -"Destination chain ID. Examples: '1' (Ethereum), '56' (BNB Chain), '42161' (Arbitrum)"New value: +"Destination chain ID"

changedInput schema / properties / dstChainOrderAuthorityAddress / description

Previous 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"

changedInput schema / properties / dstChainTokenOut / description

Previous value: -"Token address on the destination chain to receive"New value: +"Token address on destination chain"

removedInput schema / properties / dstChainTokenOutAmount / default
```
Removed value: -"auto"
```

changedInput schema / properties / dstChainTokenOutAmount / description

Previous value: -"Output amount in smallest units, or 'auto' for best available quote (default: 'auto')"New value: +"Output amount or 'auto' for best quote"

changedInput schema / properties / dstChainTokenOutRecipient / description

Previous value: -"Wallet address on the destination chain that will receive the tokens"New value: +"Wallet address on destination chain to receive tokens"

changedInput schema / properties / srcChainId / description

Previous value: -"Source chain ID. Examples: '1' (Ethereum), '56' (BNB Chain), '137' (Polygon), '7565164' (Solana)"New value: +"Source chain ID"

changedInput schema / properties / srcChainOrderAuthorityAddress / description

Previous 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"

changedInput schema / properties / srcChainTokenIn / description

Previous 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"

changedInput schema / properties / srcChainTokenInAmount / description

Previous 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)"

Changedget_instructions1 field changed
- addedInput schema / $schema
```
Added value: +"http://json-schema.org/draft-07/schema#"
```
Changedget_supported_chains1 field changed
- addedInput schema / $schema
```
Added value: +"http://json-schema.org/draft-07/schema#"
```
Removedget_trade_dapp_url

Changedsearch_tokens4 fields changed

changedInput schema / properties / chainId / description

Previous value: -"Filter by chain ID. Examples: '1' (Ethereum), '42161' (Arbitrum), '7565164' (Solana)"New value: +"Filter by chain ID"

removedInput schema / properties / limit / default
```
Removed value: -10
```

changedInput schema / properties / name / description

Previous value: -"Filter by token name (partial, case-insensitive). Examples: 'coin', 'ether'"New value: +"Filter by token name (partial, case-insensitive)"

changedInput schema / properties / query / description

Previous value: -"Token name, symbol, or contract address. Examples: 'USDC', 'ethereum', '0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48'"New value: +"Token name, symbol, or contract address"

Addedtransaction_same_chain_swap

5 tool updatesv0.1.3Feb 24, 2026
- First observedcreate_tx
- First observedget_instructions
- First observedget_supported_chains
- First observedget_trade_dapp_url
- First observedsearch_tokens

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

Each tool has a distinct purpose: cross-chain swap, same-chain swap, chain listing, token search, and a guide. No overlaps.

Naming Consistency4/5

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.

Tool Count5/5

5 tools is well-scoped for a cross-chain bridge server, covering core operations and utilities without bloat.

Completeness4/5

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.

Maintenance

ActivityInactive

ResponsivenessSlow

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

swaptitan A
net.swaptitan
Non-custodial cross-chain crypto swap MCP — 1288+ assets, no KYC. Solana/EVM/Monero, RPC, oracle.
Cryptocurrency Blockchain Web3 & Decentralized Tech
212
Tenzro Li.Fi MCP A
network.tenzro
Li.Fi MCP: cross-chain aggregation — quotes, routes, status, chains, tokens, execution.
Blockchain Cryptocurrency
2
RAVN A
exchange.ravn
Cross-chain swap aggregator across 16+ chains, incl. native Bitcoin/Solana. 0% fees, non-custodial.
Blockchain Cryptocurrency Web3 & Decentralized Tech
51
tenzro-lifi A
xyz.tenzro
Li.Fi tools over MCP: cross-chain quotes, routes, execution status, chains, tokens, balances.
Blockchain Cryptocurrency
2

Related MCP Servers

deBridge MCP Server
Cryptocurrency Blockchain Web3 & Decentralized Tech
RookieCol
F
license
Not graded
quality
D
maintenance
Enables cross-chain cryptocurrency swap quotes and operations using the deBridge DLN protocol. Provides read-only access to swap estimates, supported chains, token information, and order status tracking across multiple blockchain networks.
Updated 10 months ago (2025-10-28 04:36 UTC)
1
-
persistenceone-bridgekittyofficial
Blockchain Web3 & Decentralized Tech Autonomous Agents
persistenceOne
A
license
A
quality
B
maintenance
Cross-chain bridge aggregator MCP server for AI agents. Compares routes across LI.FI, deBridge, Relay, Across and Squid to find the best rate. Use when an agent needs to bridge or swap tokens between EVM chains, Solana, or Cosmos. The aggregator of aggregators.
Updated 3 months ago (2026-06-16 15:52 UTC)
12
66
MIT
near-hydra-mcp
Blockchain Cryptocurrency Web3 & Decentralized Tech
nikshepsvn
A
license
Not graded
quality
C
maintenance
Enables cross-chain transactions (swap, send, balance) on 10 blockchains from a single NEAR account, designed for AI agents and humans via MCP.
Updated 4 months ago (2026-05-11 19:38 UTC)
6
Apache 2.0
orbit-apiofficial
Blockchain Web3 & Decentralized Tech
Orbit-bridge
F
license
Not graded
quality
D
maintenance
MCP server for cross-chain bridging, enabling AI agents to find routes, estimate costs, check risks, execute transfers, and track status across blockchains.
Updated 2 months ago (2026-06-22 12:35 UTC)
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/debridge-finance/debridge-mcp'

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

deBridge MCP

Connecting to deBridge MCP

Recommended: Direct connection (Streamable HTTP)

Alternative: Run a local proxy

How the proxy works

npx (stdio)

Docker (HTTP proxy)

Environment Variables

Development

Links

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

persistenceone-bridgekittyofficial

orbit-apiofficial

Latest Blog Posts

MCP directory API