MultiversX MCP Server
OfficialClick 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., "@MultiversX MCP Serverquery the account erd1qyu5wthldzr8wx5c9ucg8kjyt0p50yv3p6x3j0"
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.
MultiversX MCP Server
A comprehensive Model Context Protocol (MCP) server implementation for the MultiversX blockchain ecosystem. This server provides AI agents and applications with access to MultiversX SDK-dApp v5 documentation, development resources, and blockchain data querying capabilities.
π Features
π Resources (Knowledge Base)
SDK-dApp v5 Complete Guide (
mx://sdk-dapp-guide) - Comprehensive MultiversX SDK-dApp v5 documentation including architecture, installation, configuration, and best practices
π§ Tools (Executable Functions)
Query Account (
mx-query-account) - Retrieve account information from any MultiversX networkSDK-DAPP Guide (
mx-sdk-dapp-guide) - Fetch the latest SDK-DAPP v5 guide from GitHub with optional section extraction
Related MCP server: MultiversX MCP Server
π¦ Installation
Prerequisites
Node.js (v18 or higher)
pnpm (recommended) or npm
Quick Setup
# Clone the repository
git clone <repository-url>
cd mx-dev-mcp
# Install dependencies
pnpm install
# Build the project
pnpm build
# Test the server (optional)
pnpm startπ§ Development
# Watch mode for development
npm run watch
# Run in development mode
npm run dev
# Run linting
npm run lint
# Run tests
npm test
# Clean build artifacts
npm run cleanβοΈ Configuration
Environment Variables
LOG_LEVEL- Set logging level (DEBUG, INFO, WARN, ERROR)MULTIVERSX_NETWORK- Default network (mainnet, testnet, devnet)
Network Support
The server supports all MultiversX networks:
Mainnet - Production network
Testnet - Testing network
Devnet - Development network
ποΈ Project Structure
src/
βββ index.ts # Main entry point
βββ resources/ # MCP resources (documentation)
β βββ index.ts # Resource handler setup
β βββ sdk-dapp-guide.ts # Complete SDK-dApp guide
βββ tools/ # MCP tools (executable functions)
β βββ index.ts # Tool handler setup
β βββ query-account.ts # Account querying tool
β βββ sdk-dapp-guide.ts # SDK-dApp guide tool
βββ prompts/ # MCP prompts (templates) - Currently empty
β βββ index.ts # Prompt handler setup
βββ utils/ # Utilities
β βββ constants.ts # Constants and configurations
β βββ logger.ts # Logging utilityπ Client Integration
Cursor IDE Integration
Step 1: Clone and Setup
git clone <repository-url>
cd mx-dev-mcp
pnpm install && pnpm buildStep 2: Configure Cursor MCP Settings
Add to Cursor Settings β Features β Model Context Protocol:
{
"mcpServers": {
"mvx-dev-mcp": {
"name": "MultiversX SDK development MCP Server",
"command": "node",
"args": ["<absolute-path-to-repo>/mx-dev-mcp/dist/index.js"],
"env": {
"LOG_LEVEL": "INFO"
}
}
}
}Important: Replace <absolute-path-to-repo> with the actual absolute path.
Step 3: Alternative Configuration (npm link)
# In the mx-dev-mcp directory
npm link
# Then in Cursor MCP settings:
{
"name": "MultiversX MCP Server",
"command": "mx-dev-mcp"
}Claude Desktop Integration
Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS):
{
"mcpServers": {
"mvx-dev-mcp": {
"name": "MultiversX SDK development MCP Server",
"command": "node",
"args": ["<absolute-path-to-repo>/mx-dev-mcp/dist/index.js"],
"env": {
"LOG_LEVEL": "INFO"
}
}
}
}π Resources Documentation
SDK-dApp v5 Complete Guide (mx://sdk-dapp-guide)
Comprehensive guide covering MultiversX SDK-dApp v5 architecture, installation, configuration, provider interactions, data access patterns, transaction management, network configuration, account management, UI components, and debugging strategies.
π§ Tools Documentation
Query Account Tool (mx-query-account)
Query MultiversX account information including balance, nonce, transactions, guardian status, assets, and more for any network (mainnet, testnet, devnet).
Parameters:
address(required): MultiversX account address (erd1... format)network: MAINNET, TESTNET, or DEVNET (default: MAINNET)withGuardianInfo: Include guardian information in the response (default: false)withTxCount: Include transaction count in the response (default: false)withScrCount: Include smart contract results count in the response (default: false)withTimestamp: Include timestamp of last activity in the response (default: false)withAssets: Include assets (tokens/NFTs) in the response (default: false)timestamp: Retrieve account state from a specific timestamp
Response Format:
Address and balance information
Transaction counts and activity
Guardian status (if requested)
Smart contract details (if applicable)
Asset information (if requested)
Verification status and metadata
Usage Examples:
Query the MultiversX account erd1qga7ze0l03chfgru0a32wxqf2226nzrxnyhzer9lmudqhjgy7ycqjjyknzGet balance for address erd1qga7ze0l03chfgru0a32wxqf2226nzrxnyhzer9lmudqhjgy7ycqjjyknz on testnetShow detailed account info with transaction count and guardian status for erd1qga7ze0l03chfgru0a32wxqf2226nzrxnyhzer9lmudqhjgy7ycqjjyknzSDK-DAPP Guide Tool (mx-sdk-dapp-guide)
Fetch the MultiversX SDK-DAPP v5 guide from the official GitHub repository, including setup and usage for React, TypeScript, JavaScript, Angular, login/logout, signing, sending, tracking transactions, signing messages, and creating custom providers. Optionally, provide a section name to extract a specific section.
Parameters:
section(optional): The section name to extract from the guide (e.g., Installation, Configuration, Transactions, etc.)
Response Format:
Markdown content of the full guide or the requested section
Usage Examples:
Basic Usage - Fetch Complete Guide
Fetch the complete MultiversX SDK-DAPP v5 guideSetup SDK-dApp
Get the SDK-dApp installation and setup instructionsUse section: "Installation"
Login and Logout with SDK-dApp
Show me how to implement login and logout functionality with SDK-dAppUse section: "Login" or "Logout" or "Authentication"
Sign/Send/Track Transactions
Get information about signing, sending, and tracking transactions with SDK-dAppUse section: "Transactions" or "Signing Transactions"
Get Account Information
Show me how to get account information using SDK-dAppUse section: "Account" or "Getting account data"
Sign Messages
Get information about signing messages with SDK-dAppUse section: "Signing Messages" or "Message Signing"
Configuration and Setup
Get the SDK-dApp configuration and initialization guideUse section: "Configuration" or "Setup"
Provider Management
Show me how to work with different wallet providers in SDK-dAppUse section: "Providers" or "Wallet Providers"
UI Components
Get information about SDK-dApp UI componentsUse section: "UI Components" or "Components"
Advanced Usage Examples
Fetch specific sections:
Get only the "Installation" section from the SDK-DAPP guideTransaction workflow:
Show me the complete transaction workflow from signing to trackingProvider integration:
How do I integrate different wallet providers with SDK-dApp?Account management:
Get the account management section from the SDK-DAPP guideNetwork configuration:
Show me how to configure networks in SDK-dApp
π οΈ Tool Usage Examples
Query Account Tool
Query a mainnet account:
Query the MultiversX account erd1qga7ze0l03chfgru0a32wxqf2226nzrxnyhzer9lmudqhjgy7ycqjjyknzQuery an account on testnet:
Get balance for address erd1qga7ze0l03chfgru0a32wxqf2226nzrxnyhzer9lmudqhjgy7ycqjjyknz on testnetShow detailed info with transaction count and guardian status:
Show detailed account info with transaction count and guardian status for erd1qga7ze0l03chfgru0a32wxqf2226nzrxnyhzer9lmudqhjgy7ycqjjyknz
SDK-DAPP Guide Tool
Fetch the entire guide:
Fetch the complete MultiversX SDK-DAPP v5 guideFetch a specific section:
Get only the "Installation" section from the SDK-DAPP guideGet setup instructions:
Show me how to set up SDK-dApp in my projectGet authentication guide:
How do I implement login and logout with SDK-dApp?Get transaction guide:
Show me how to sign and send transactions with SDK-dApp
π§ Troubleshooting
Common Issues
1. MCP Server Not Connecting
Problem: Cursor shows "MCP server failed to start" Solutions:
Ensure absolute path is correct in configuration
Verify project is built:
pnpm buildCheck Node.js installation and accessibility
Restart Cursor after configuration changes
2. Account Query Failures
Problem: "Account not found" or API errors Solutions:
Verify address format (must start with "erd1")
Check network connectivity
Try with known valid address:
erd1qga7ze0l03chfgru0a32wxqf2226nzrxnyhzer9lmudqhjgy7ycqjjyknzEnsure correct network selection
3. Build Errors
Problem: TypeScript compilation errors Solutions:
Ensure Node.js version 18+
Clean install:
rm -rf node_modules && pnpm installCheck TypeScript errors:
pnpm tsc --noEmit
4. SDK-DAPP Guide Fetch Issues
Problem: Guide not loading or sections not found Solutions:
Check internet connectivity
Verify section names are correct (case-insensitive matching)
Try fetching the complete guide first
Check GitHub repository accessibility
Debug Mode
Enable debug logging:
{
"env": {
"LOG_LEVEL": "DEBUG"
}
}Getting Help
If you encounter issues:
Check troubleshooting section
Verify setup against installation instructions
Test server independently:
pnpm startCheck MCP server logs in client settings
Review console output for error details
π Best Practices
Security
Always validate addresses before querying
Use appropriate network for development/production
Follow SDK-dApp security guidelines
Implement proper error handling
Performance
Cache frequently accessed documentation
Use section-specific queries when possible
Monitor API rate limits
Optimize query parameters
Development
Use development networks for testing
Follow TypeScript best practices
Implement comprehensive error handling
Document custom implementations
π€ Contributing
Fork the repository
Create a feature branch
Make your changes
Run tests and linting
Submit a pull request
π License
MIT License - see LICENSE file for details
π Links
Available Tools
2 toolsmx-query-accountB
Query MultiversX account information including balance, nonce, transactions, and guardian status for any network (mainnet, testnet, devnet)
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | The MultiversX account address to query (erd... format) | |
| network | No | The MultiversX network to query (default: MAINNET) | MAINNET |
| timestamp | No | Retrieve account state from a specific timestamp | |
| withAssets | No | Include assets (tokens/NFTs) in the response | |
| withTxCount | No | Include transaction count in the response | |
| withScrCount | No | Include smart contract results count in the response | |
| withTimestamp | No | Include timestamp of last activity in the response | |
| withGuardianInfo | No | Include guardian information in the response |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. The verb 'Query' weakly implies a read-only operation, but the description says nothing about authentication requirements, rate limits, cost, error behavior, or whether historical timestamp queries behave differently. For an 8-parameter network-facing tool with zero annotation coverage this is a substantial gap.
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 front-loaded sentence with no filler; the resource and scope come first. It is efficient, though the trailing network parenthetical is slightly redundant with the schema enum.
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 partially compensates by naming the major return categories (balance, nonce, transactions, guardian status) and the supported networks. Combined with 100% schema coverage for all 8 params, an agent has enough to invoke it correctly; only the exact return shape and flag interactions remain implicit.
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 every parameter including the network enum and the with* booleans is already documented in the schema. The description's enumeration of balance/nonce/transactions/guardian status loosely maps to some flags but adds no syntax, format, or defaulting detail beyond the schema. Baseline 3 applies.
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 (Query) and resource (MultiversX account information) and enumerates the data categories returned β balance, nonce, transactions, guardian status. It is clearly distinct from the only sibling, mx-sdk-dapp-guide, but it never explicitly differentiates itself, so it stops short of a 5.
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 parenthetical '(mainnet, testnet, devnet)' and 'for any network' imply the tool covers all networks, which is useful usage context. However, there is no explicit when-to-use versus when-not guidance, no prerequisites, and no alternative tool named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mx-sdk-dapp-guideA
Fetch the MultiversX SDK-DAPP v5 guide, including setup and usage for React, TypeScript, JavaScript, Angular, login/logout, signing, sending, tracking transactions, signing messages, and creating custom providers. Optionally, provide a section name to extract a specific section.
| Name | Required | Description | Default |
|---|---|---|---|
| section | No | Optional. The section name to extract from the guide (e.g., Installation, Configuration, Transactions, etc.) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the content scope and that a section can be extracted, but never states the operation is read-only/idempotent, what happens if the requested section name does not exist, or how the guide content is returned. For a low-risk documentation fetch this is acceptable but not rich.
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, front-loaded with the resource and its scope, followed by the parameter behavior. The topic list is long but it is informative rather than padding, and there is no redundant restatement of the tool name.
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 single-optional-parameter read tool with no output schema and no annotations, the description covers what is fetched, what topics are included, and what the parameter does. The remaining gaps (section name enumeration, not-found behavior, return format) are minor.
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 baseline is 3. The description restates that the section parameter is optional and causes extraction of a specific section, which adds a little behavioral meaning over the schema's field description but no format, casing, or matching rules beyond the schema's own examples.
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 ('Fetch') and a precise resource ('MultiversX SDK-DAPP v5 guide') and enumerates the covered topics (setup, React/TypeScript/JavaScript/Angular usage, login/logout, signing, transactions, custom providers). This is unambiguous and clearly distinct from the only sibling, mx-query-account, which is a chain-state query rather than a documentation lookup.
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 implies when to use it (when you need SDK-DAPP v5 guidance) and explains the optional section parameter's effect, but gives no explicit when-to-use/when-not framing, no alternatives, and no prerequisites. Usage is inferable but not spelled out.
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.
2 tool updates
v1.0.0- First observed
mx-query-account - First observed
mx-sdk-dapp-guide
TDQS
Scored across 2 tools
The two tools serve completely distinct purposes: one queries live on-chain account data, the other retrieves static SDK documentation. There is no realistic scenario where an agent would confuse them.
Both names share a consistent 'mx-' prefix and kebab-case formatting, which is predictable. The main deviation is that one uses an action verb (query) while the other is a noun-style resource name (sdk-dapp-guide).
Two tools is thin for a server branded as a general MultiversX blockchain interface. The scope implied by the name suggests querying blocks, tokens, NFTs, and submitting transactions, so the surface feels under-developed rather than intentionally minimal.
The surface only supports reading a single account; there are no tools for tokens, NFTs, blocks, smart contracts, or sending transactions. This leaves significant gaps for anything beyond read-only account inspection, though the doc tool partially compensates by describing transaction workflows.
Maintenance
Related MCP Connectors
Provide AI agents and automation tools with contextual access to blockchain data including balanceβ¦
AI agent gateway with web fetching, data extraction, crypto pricing, and x402 payments
Pay-per-call (x402/USDC-Base) web + crypto data tools for AI agents: audit, extract, crypto, DeFi.
Read-only on-chain intelligence for AI agents on Base: balances, tokens, gas, tx status.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceEnables AI agents to interact with the Somnia blockchain network, including documentation search, blockchain queries, wallet management, cryptographic signing, and on-chain operations.-

MultiversX MCP Serverofficial
FlicenseBqualityDmaintenanceEnables interaction with the MultiversX blockchain, allowing users to create wallets, check balances, and send or issue tokens (EGLD, Fungible, SFT, NFT, MetaESDT) through natural language.146 npm2-
Nexus MCP Serverofficial
AlicenseNot gradedqualityDmaintenanceEnables AI agents to interact with the Nexus blockchain, providing tools for querying blockchain data, smart contract calls, transaction submission, and event monitoring.7MIT- AlicenseNot gradedqualityBmaintenanceProvides AI agents with access to DFNS documentation, API reference, and SDK code through full-text search and type intelligence.11 npmMIT