LayerZero OFT MCP Server
The LayerZero OFT MCP Server enables the creation, deployment, and bridging of Omnichain Fungible Tokens (OFTs) across multiple blockchains using LayerZero's protocol. With this server, you can:
Deploy OFTs on multiple chains: Deploy OFT contracts on multiple LayerZero-supported chains simultaneously with the
deploy-and-configure-oft-multichaintoolConfigure peer connections: Automatically set up peering between newly deployed OFT contracts on different chains
Bridge tokens: Transfer OFT tokens between chains using the
bridge-ofttoolCustomize tokens: Define token properties (name, symbol, supply, decimals) with support for deterministic addressing via CREATE2
Set enforced options: Configure standard enforced options on OFT contracts for cross-chain transfers
Integration-friendly: Easily integrate with LLM agents, bots, or applications requiring decentralized cross-chain functionality
Uses .ENV for managing environment variables like private keys, wallet addresses, and RPC endpoints for blockchain interactions
Enables deployment and management of Omnichain Fungible Tokens (OFTs) across multiple Ethereum-based blockchains
Utilizes ethers.js to interact with blockchain networks for deploying contracts and executing cross-chain token transfers
Runs on Node.js to provide a server environment for blockchain interactions and cross-chain token bridging
Leverages Solidity's CREATE2 opcode for deterministic cross-chain contract addressing when deploying OFT tokens
Click on "Install 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., "@LayerZero OFT MCP Serverdeploy MyToken with symbol MYT and 1M supply to Arbitrum and Base"
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.
LayerZero OFT MCP Server
LayerZero OFT MCP is a TypeScript/Node.js Model Context Protocol (MCP) server for creating, deploying, and bridging Omnichain Fungible Tokens (OFTs) across multiple blockchains. Interactions are primarily managed via ethers.js, leveraging LayerZero contracts and protocols for cross-chain communication.
This MCP abstracts the complexity of omnichain token creation and cross-chain interactions by providing a structured, context-aware layer for initiating, managing, and bridging OFTs. It is designed for easy integration with LLM agents, bots, or applications that require secure and reliable access to decentralized cross-chain functionality.
Deterministic Cross-Chain Contract Addressing
The MCP uses Solidity's CREATE2 opcode to deploy OFT contracts at the same address on every chain.
The address is derived from the bytecode and a fixed salt, which includes currently the token name and symbol. Make sure you use unique identifiers when deploying, because you cannot create two times the same token (same name and symbol) using the same factory (You can also use an other type of salt if you want to avoid this).
It’s a working starting point. You can bring your own OFT contract and expand it with custom features or token logic. The system is open and extendable by design.
Features & Tools
This MCP server exposes the following tools for interaction:
1. deploy-and-configure-oft-multichain
Description: Deploys an Omnichain Fungible Token (OFT) contract to one or more specified LayerZero-supported chains. After successful deployments, it configures each new OFT contract to be a peer with all other newly deployed OFTs in the set. It also sets standard enforced options (e.g., for gas limits) on each contract to enable cross-chain transfers to its peers.
Parameters:
tokenName(string): Name of the token (e.g., "MyToken").tokenSymbol(string): Symbol of the token (e.g., "MYT").initialTotalSupply(string): Total supply of the token in human-readable format (e.g., "1000000"). This will be parsed using thedecimalsvalue.decimals(number, Optional, default: 18): Number of decimals for the token.targetChains(array of strings): List of chain names (from the configuredNETWORKSinutils.ts, e.g.,["Arbitrum sepolia", "baseSepolia"]) to deploy and configure the OFT on. Must select at least one. For peering to occur, at least two chains must be specified and result in successful deployments.owner(string, Optional): The Ethereum address to be the owner of the deployed contracts. If not provided, defaults to theOWNER_ADDRESSset in the.envfile.
Output: Details the success or failure of deployments on each target chain, peering status between them, and the status of setting enforced options.
2. bridge-oft
Description: Bridges OFT tokens from one chain to another using LayerZero.
Parameters:
tokenAddress(string): The address of the OFT contract on the source chain.amount(string): The amount of tokens to bridge (e.g., "100"). This is parsed assuming 18 decimals; ensure your token uses this or modify the tool if necessary.fromChain(string): The source chain name (e.g., "Arbitrum sepolia").toChain(string): The destination chain name (e.g., "baseSepolia").receiverAddress(string): The address to receive tokens on the destination chain.extraOptions(string, optional, default: "0x"): Extra options for LayerZero message execution.
Output: Details of the bridging transaction, including the transaction hash.
Related MCP server: Akash MCP Server
IMPORTANT: Configure ABI and Bytecode
Before running the server, you MUST replace theses paths with the absolute path to your contract artifacts
// --- index.ts ---
// Replace these paths with the actual ABI and Bytecode JSON file of your OFT contract (e.g., from MyOFT.sol)
const oftPath = resolve(
"D:\\Dev\\layerzero-mcp\\artifacts\\MyOFT\\MyOFT.json"
);
// Same here for the factory contract
// This should point to the CREATE2Factory ABI and Bytecode JSON file
const factoryPath = resolve(
"D:\\Dev\\layerzero-mcp\\artifacts\\factory\\CREATE2Factory.json"
);
// --- --- --- Failure to do so will result in errors when attempting to use the deploy-and-configure-oft-multichain tool. The bridge-oft tool also requires the OFT_ABI to be correctly set for interacting with existing contracts.
Setup
Prerequisites
Node.js (v16 or higher recommended)
Access to an LLM or application that can communicate via the Model Context Protocol (e.g., Claude for Desktop).
Installation
Clone the repository:
git clone https://github.com/your-username/layerzero-oft-mcp.git cd layerzero-oft-mcpInstall dependencies:
npm install # or yarn installCreate a
.envfile: Copy the.env.example(if provided) or create a new.envfile in the root of the project and populate it with your details:PRIVATE_KEY="your_hex_encoded_private_key_here" OWNER_ADDRESS="your_owner_ethereum_address_here" ARBITRUM_SEPOLIA_RPC_URL="your_Arbitrum sepolia_testnet_rpc_url_here" BASE_SEPOLIA_RPC_URL="your_base_sepolia_testnet_rpc_url_here" ARBITRUM_FACTORY_ADDRESS="0x754a2643Ce68e0e34510B1E246254f93946AE3a1" BASE_FACTORY_ADDRESS="0x754a2643Ce68e0e34510B1E246254f93946AE3a1" # Add other RPC URL env variables if you configure more networks in utils.tsSecurity Note: Never commit your
.envfile containing private keys to a public repository.Update ABI and Bytecode: As mentioned in the "IMPORTANT" section above, open
layerzero-mcp.tsand replaceOFT_ABIandOFT_BYTECODEplaceholders with your actual contract details.Build the project (if using TypeScript compilation):
npm run build # or yarn run build(This command assumes you have a
buildscript in yourpackage.jsonthat compiles TypeScript to JavaScript, e.g.,tsc)
Configure the MCP for Claude for Desktop (Example)
Add the MCP configuration to your Claude for Desktop configuration file (typically found at C:\Users\{User}\AppData\Roaming\Claude\claude_desktop_config.json on Windows):
{
"layerzero-oft-mcp": {
"command": "node",
"args": [
"<PROJECT_ABSOLUTE_FILEPATH>/build/index.js"
],
"env": {
"PRIVATE_KEY": "your_hex_encoded_private_key_here",
"OWNER_ADDRESS": "your_owner_ethereum_address_here",
"ARBITRUM_SEPOLIA_RPC_URL": "your_Arbitrum_sepolia_testnet_rpc_url_here",
"BASE_SEPOLIA_RPC_URL": "your_base_sepolia_testnet_rpc_url_here",
"ARBITRUM_FACTORY_ADDRESS": "0x754a2643Ce68e0e34510B1E246254f93946AE3a1",
"BASE_FACTORY_ADDRESS": "0x754a2643Ce68e0e34510B1E246254f93946AE3a1"
}
}
}Replace
<PROJECT_ABSOLUTE_FILEPATH>with the actual absolute path to your project directory.Ensure the
envvariables here match those required by your server, or that they are correctly picked up from your.envfile if your Node.js setup loads them (thedotenv.config()call in the scripts should handle this). For Claude Desktop, explicitly setting them inclaude_desktop_config.jsonis required.
Follow the official MCP guide for more details on testing with Claude for Desktop.
Running the Application & Example Usage
Once configured (including ABI/Bytecode and environment variables), the MCP server will be launched by the host application (e.g., Claude for Desktop) when needed.
You can then interact with it using natural language prompts if using an LLM. For example:
To deploy and configure a new OFT: "Deploy a new OFT named 'OmniCoin' (OMC) with a total supply of 500,000 tokens across both Arbitrum sepolia and Base Sepolia testnets."
This will use the deploy-and-configure-oft-multichain tool.
To bridge existing OFT tokens: "Bridge 50 MyOFT from Arbitrum sepolia to Base Sepolia to address 0x123...abc. The token is deployed at 0xabc...123 on Arbitrum sepolia."
This will use the bridge-oft tool.
NOTE: Ensure you have sufficient gas tokens (e.g., testnet ETH or MATIC) on the respective chains for the account associated with your PRIVATE_KEY to cover deployment and bridging transaction fees.
Example Screenshots
Deploying an OFT

Bridging an OFT

Available Tools
2 toolsbridge-oftB
Bridges OFT tokens from one chain to another using LayerZero.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | The amount of tokens to bridge (e.g., '100'). | |
| extraOptions | No | Extra options for LayerZero message execution (default: '0x'). | 0x |
| fromChain | Yes | The source chain name. | |
| receiverAddress | Yes | The address to receive tokens on the destination chain. | |
| toChain | Yes | The destination chain name. | |
| tokenAddress | Yes | The address of the OFT contract on the source chain. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic operation without disclosing critical behavioral traits such as transaction costs, execution time, security implications, error handling, or whether it's a read-only or destructive action.
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?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words, making it highly concise and well-structured.
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 complex tool involving cross-chain token transfers with 6 parameters and no annotations or output schema, the description is insufficient. It lacks details on outcomes, error cases, and operational constraints, leaving significant gaps in understanding.
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 the schema fully documents all parameters. The description adds no additional meaning beyond the schema, maintaining the baseline score of 3 for adequate but not enhanced parameter context.
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 specific action ('bridges'), the resource ('OFT tokens'), and the mechanism ('using LayerZero'), distinguishing it from the sibling tool 'deploy-and-configure-oft-multichain' which appears to be about setup rather than bridging operations.
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 is provided on when to use this tool versus alternatives or under what conditions it should be invoked. The description lacks context about prerequisites, constraints, or comparison with the sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
deploy-and-configure-oft-multichainB
Deploys an OFT contract to multiple chains, sets up peer connections, and configures enforced options.
| Name | Required | Description | Default |
|---|---|---|---|
| decimals | No | Number of decimals for the token (default: 18) | |
| initialTotalSupply | Yes | Total supply of the token in human-readable format (e.g., '1000000') | |
| owner | No | Optional owner address. Defaults to OWNER_ADDRESS from .env if not provided. | |
| targetChains | Yes | List of chain names to deploy and configure the OFT on (e.g., ['ArbitrumSepolia', 'baseSepolia']) | |
| tokenName | Yes | Name of the token (e.g., MyToken) | |
| tokenSymbol | Yes | Symbol of the token (e.g., MYT) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only mentions high-level actions without disclosing critical behavioral traits like permission requirements, cost implications, whether deployment is reversible, rate limits, or error handling. It states what the tool does but not how it behaves.
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 efficiently captures the core functionality with zero wasted words. It's appropriately sized and front-loaded, making every word earn its place.
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 complex deployment tool with 6 parameters, no annotations, and no output schema, the description is insufficient. It lacks information about what happens after deployment, error conditions, side effects, or integration context, leaving significant gaps for an AI agent.
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%, providing detailed parameter documentation. The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline of 3 without compensating for any gaps.
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 specific action ('deploys an OFT contract to multiple chains, sets up peer connections, and configures enforced options') with the resource (OFT contract) and distinguishes it from the sibling tool 'bridge-oft' by focusing on deployment and configuration rather than bridging operations.
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 explicit guidance on when to use this tool versus alternatives like 'bridge-oft' or other deployment methods. The description implies usage for initial setup but lacks context on prerequisites, timing, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
The two tools have clearly distinct purposes: bridge-oft handles token transfers between existing chains, while deploy-and-configure-oft-multichain handles contract deployment and configuration across chains. There is no overlap in functionality, making it easy for an agent to select the correct tool.
Both tools use kebab-case naming, which is consistent. However, the first tool uses a simple verb-noun format (bridge-oft), while the second is more complex with multiple verbs and nouns (deploy-and-configure-oft-multichain), showing a minor deviation in naming style.
With only two tools, the server feels thin for a multichain token deployment and bridging domain. While the tools cover core operations, typical LayerZero OFT workflows might benefit from additional tools for tasks like querying deployments or managing configurations.
The tools cover deployment and bridging, which are essential operations, but there are notable gaps. Missing tools for querying deployed contracts, checking bridge status, or updating configurations could lead to agent workarounds or failures in complex workflows.
Maintenance
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
Deploy ERC-20 tokens on Ethereum, Base, BNB, Polygon via MCP. One call = deployed contract.
MCP server for Boson Protocol — on-chain agentic commerce for physical & digital goods.
LayerZero V2 tools over MCP: message quotes, OFT transfers, Stargate bridging, DVN lookups.
The OpenZeppelin Solidity Contracts MCP server integrates OpenZeppelin's security and style rules into AI-driven development workflows, enabling AI assistants to generate safe, correct, and production-ready smart contracts. It automatically validates generated code against OpenZeppelin standards (including imports, modifiers, naming conventions, and security checks) and supports various contract types including ERC-20, ERC-721, ERC-1155, Stablecoins, RWA, Governor, and Account contracts through prompt-driven workflows.
Related MCP Servers
- AlicenseAqualityDmaintenanceA comprehensive server that enables AI agents to interact with multiple EVM-compatible blockchain networks through a unified interface, supporting ENS resolution, token operations, and smart contract interactions.25127MIT

Akash MCP Serverofficial
AlicenseNot gradedqualityCmaintenanceA TypeScript server implementing the Model Context Protocol that enables AI agents to interact with the Akash Network, allowing them to deploy applications, create leases, manage deployments, and access other Akash services through typed tools.2113Apache 2.0- AlicenseNot gradedqualityDmaintenanceA TypeScript-based server that provides debugging and management capabilities for FiveM plugin development, allowing developers to control plugins, monitor server logs, and execute RCON commands.8MIT
- AlicenseNot gradedqualityDmaintenanceA TypeScript-based MCP server that provides backend API handling and facilitates communication between microservices. Features an organized structure with controllers, routes, and models for easy extensibility and maintenance.2251MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/thomasfevre/layerzero_mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server