Provides tools for cross-chain bridging between Algorand and Voi, including asset discovery and transaction preparation for native tokens and ASAs.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@AramidBridgeMCP bridge 50 USDC from Algorand to Voi"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Protocol MCP server for the Aramid Bridge — cross-chain bridging between Voi and Algorand.
AramidBridgeMCP is a protocol-level MCP that sits above the infrastructure MCP layer:
UluCoreMCP / UluWalletMCP / UluBroadcastMCP
↓
AramidBridgeMCP
↓
On-chain (writes)AramidBridgeMCP handles:
Asset discovery with bridge routes between Voi and Algorand
Transaction preparation for bridging native tokens and ASAs
Automatic 0.1% fee calculation
AramidBridgeMCP does NOT:
Sign transactions (use UluWalletMCP)
Broadcast transactions (use UluBroadcastMCP)
Manage wallets
Related MCP server: Algorand MCP Server
Tool | Description |
| List bridgeable assets with source/destination token IDs and routes |
Tool | Description |
| Build unsigned bridge transaction for Voi ↔ Algorand transfers |
Agent calls AramidBridgeMCP: bridge_txn(chain, symbol, amount, sender, destinationAddress)
→ returns { transactions: [base64, ...] }
Agent calls UluWalletMCP: wallet_sign_transactions(signerId, transactions)
→ returns signed transactions
Agent calls UluBroadcastMCP: broadcast_transactions(network, txns)
→ returns transaction IDsAll tools accept a chain parameter:
"voi" — Voi mainnet (chain ID 416101)
"algorand" — Algorand mainnet (chain ID 416001)
Symbol | Name | Voi Asset ID | Algorand Asset ID |
VOI | Voi | 0 (native) | 2320775407 (aVOI) |
ALGO | Algorand | 302189 (aALGO) | 0 (native) |
USDC | USD Coin | 302190 (aUSDC) | 31566704 |
ETH | Ethereum | 302193 (aETH) | 770071959 (aETH) |
cbBTC | Coinbase BTC | 40152648 (acbBTC) | 3081230356 (acbBTC) |
WBTC | Wrapped BTC | 40152643 (aWBTC) | 3081228451 (aWBTC) |
UNIT | UNIT | 40266690 | 3121954282 |
POW | Power | 40152679 | 2994233666 |
GOLD | Gold | 302228 (aGOLD) | 1241944285 |
VOTE | Vote Coin | 797372 (aVOTE) | 452399768 |
FINITE | DeFi-nite | 797369 | 400593267 |
AMMO | Ammo | 40266675 | 3121959207 |
COOP | Coop Coin | 40266636 | 796425061 |
CORN | Corn Coin | 40266686 | 3121962516 |
Plus BALLSACK, BLAPU, GEMS, GPEPE, JIMMY, PANDA, TURTLE
Bridge Address: ARAMIDFJYV2TOFB5MRNZJIXBSAVZCVAUDAPFGKR5PNX4MTILGAZABBTXQQ
Fee: 0.1% fixed fee deducted from bridged amount
Delivery: Automatic on AVM destinations (no claim step required)
Protocol: Aramid transfer note format (aramid-transfer/v1:j{...})
index.js MCP server entry point (2 tools)
lib/
client.js Algod client factory
assets.js Asset lookup and route resolution
bridge.js Bridge transaction builder
data/
config.json Chain configs, bridge address, and supported asset pairsnpm installnode index.jsOr configure as an MCP server in your agent:
{
"mcpServers": {
"aramid-bridge": {
"command": "node",
"args": ["/path/to/AramidBridgeMCP/index.js"]
}
}
}Build an unsigned Aramid Bridge transaction for bridging assets between Voi and Algorand. Supports native tokens (VOI/ALGO) and ASAs. The 0.1% bridge fee is deducted automatically. Delivery is automatic on AVM destinations. Returns base64-encoded transaction (string[]) for wallet signing via UluWalletMCP.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | Yes | Source chain to bridge FROM | |
| amount | Yes | Amount in human-readable units (e.g. '10' for 10 VOI, '100' for 100 USDC) | |
| sender | Yes | Sender wallet address on source chain | |
| symbol | Yes | Token symbol to bridge (e.g. VOI, ALGO, USDC, ETH, UNIT, POW) | |
| destinationAddress | Yes | Recipient wallet address on destination chain |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the 0.1% auto-deducted fee, automatic delivery on AVM destinations, that the transaction is unsigned, and that it returns base64-encoded strings. It stops short of permissions, rate limits, or what happens for non-AVM destinations.
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?
Four tight sentences with the core purpose front-loaded and no filler. Slightly dense, but every sentence contributes a distinct fact (fee, delivery, return format, signer).
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 no-output-schema builder tool, the description usefully explains the return value (base64-encoded transaction string[] for wallet signing) and the fee behavior. Only minor gaps remain, such as the non-AVM delivery path and error/misconfiguration handling.
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 description coverage is 100%, so all five parameters are already documented in the schema, including the human-readable amount format and the chain enum. The description adds only the general token-category note (native tokens and ASAs), which does not extend semantics per-parameter.
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?
States a specific verb (Build) and resource (unsigned Aramid Bridge transaction) plus the exact scope: bridging assets between Voi and Algorand. An agent can immediately tell this apart from the sibling get_supported_assets, which only enumerates tokens.
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 bridging use case and the downstream step (signing via UluWalletMCP) are made explicit, so the agent knows where this fits in the workflow. It does not, however, state exclusions or when to prefer another tool for a similar task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List assets supported by the Aramid Bridge with available routes between Voi and Algorand. Each asset includes source/destination token IDs and types. Optionally filter by source chain.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Filter by source chain, or omit to show all routes | |
| symbol | No | Filter by token symbol (e.g. VOI, USDC, ETH) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose the shape of the return ('Each asset includes source/destination token IDs and types'), which is genuinely helpful for a listing tool, but says nothing about authentication, rate limits, caching, or that the list may vary as bridge routes change.
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?
Three compact sentences, front-loaded with the purpose and followed by the return shape and the optional filter. Slight redundancy between 'Optionally filter by source chain' and the schema's own wording, but nothing wasted.
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?
There is no output schema, so the description compensates by summarizing what each returned asset contains (source/destination token IDs and types). For a read-only, two-optional-param lookup tool this is nearly sufficient; a note on whether results are static or change with bridge state would close the gap.
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 description coverage is 100%, so both the chain and symbol parameters are already fully documented, including the enum values and the 'omit to show all routes' semantics. The description's 'Optionally filter by source chain' merely restates the chain parameter and adds no new semantics.
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 names a specific verb and resource ('List assets supported by the Aramid Bridge') and scopes it to routes between Voi and Algorand, which is far more useful than a generic listing statement. It does not explicitly name the sibling bridge_txn or contrast itself against it, so an agent must infer the read-vs-execute distinction from the word 'List'.
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 clause 'Optionally filter by source chain' implies when to narrow results, but there is no explicit guidance on when to call this versus bridge_txn or what to do with the returned assets. Usage is inferable but not stated.
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.0bridge_txnget_supported_assetsScored across 2 tools
get_supported_assets is a read-only query for available assets and routes; bridge_txn is a transaction builder. Their purposes are clearly distinct with no overlap, so an agent can easily select the right tool.
Both tools use snake_case with a consistent verb_noun pattern: get_supported_assets and bridge_txn. The abbreviation 'txn' is minor and does not break the pattern.
Only 2 tools are provided, which is below the typical 3-15 range. While each tool earns its place for a minimal bridge service, the count feels thin for a production bridging MCP.
The surface covers asset discovery and transaction building but lacks tools for checking bridge status, estimating fees, or retrieving transaction history. These are notable gaps for a bridge lifecycle, though signing is delegated to UluWalletMCP.
Pay any Algorand x402 invoice with any asset, plus DEX swap quotes and unsigned builds.
Fail-closed live-endpoint x402 router. POST /route, $0.01 USDC on Base, Solana, Algorand.
Non-custodial value router: ranked fiat/crypto & cross-chain routes, swaps, onramp, gasless wallet.
Li.Fi tools over MCP: cross-chain quotes, routes, execution status, chains, tokens, balances.