MultiversX MCP Server

Official

by multiversx

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.3
Disambiguation4/5
Most tools have distinct purposes, but there is some overlap between 'create-sft-nft-mesdt-tokens' and the individual collection issuance tools (issue-nft-collection, issue-semi-fungible-collection, issue-meta-esdt-collection), which could cause confusion. The send tools are clearly differentiated by token type and recipient count.
Naming Consistency4/5
Tools follow a consistent verb-object naming pattern with hyphens (e.g., create-wallet, get-balance-of-address, send-egld). Minor deviations exist, such as 'create-sft-nft-mesdt-tokens' using abbreviations inconsistently compared to others, but overall the naming is predictable and readable.
Tool Count5/5
With 14 tools, the server is well-scoped for managing wallets, tokens, and transactions on the MultiversX blockchain. Each tool addresses a specific operation like token issuance, balance queries, or transfers, making the count appropriate for the domain without being overwhelming.
Completeness4/5
The toolset covers key blockchain operations including wallet creation, balance and token queries, token issuance for various types, and transfers. Minor gaps exist, such as no tools for updating token properties or deleting wallets, but core workflows are well-supported.
Average 3.1/5 across 14 of 14 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool creates a transaction and issues a token, implying a write operation, but lacks details on permissions, network effects, transaction costs, or error handling. The vague phrase 'All the properties will be set to true' adds little value and doesn't clarify what properties or implications are involved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but could be more front-loaded and efficient. The first sentence clearly states the purpose, but the second sentence ('Will issue the token with the specified arguments.') is redundant, and the third ('All the properties will be set to true.') is vague and adds minimal value. It's concise but not optimally structured.
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?
Given the complexity of issuing and sending tokens (a write operation with no annotations or output schema), the description is incomplete. It lacks details on transaction behavior, success/failure responses, network requirements, or how it integrates with sibling tools. For a tool with significant implications, this leaves critical gaps in understanding.
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 the schema already documents all four parameters (tokenName, tokenTicker, initialSupply, numDecimals) with clear descriptions. The description adds no additional meaning beyond the schema, such as format examples or constraints, but doesn't contradict it either. This meets the baseline for high schema coverage.
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's purpose: 'Create a transaction to issue a fungible token and send it.' It specifies the verb ('issue'), resource ('fungible token'), and action ('send it'), making it understandable. However, it doesn't explicitly differentiate from sibling tools like 'issue-meta-esdt-collection' or 'send-fungible-tokens', which would require more specific context about when to use each.
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?
The description provides no guidance on when to use this tool versus alternatives. It mentions issuing and sending a token but doesn't clarify scenarios like initial token creation vs. transfers, or how it differs from sibling tools such as 'send-fungible-tokens' or 'issue-meta-esdt-collection'. Without this, users might struggle to choose the right tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions creating and sending a transaction, implying a write operation, but doesn't specify permissions needed, network effects, transaction costs, or what 'send it' entails (e.g., destination). The phrase 'All the properties will be set to true' is unclear about behavioral implications. This leaves significant gaps for a transaction-issuing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (two sentences) but includes vague phrasing like 'All the properties will be set to true' that doesn't add clear value. It's front-loaded with the main purpose, but the second sentence is redundant and unclear, reducing efficiency. It could be more streamlined by removing ambiguous statements.
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?
For a tool that creates and sends transactions (implied mutation) with no annotations and no output schema, the description is insufficient. It lacks details on behavioral aspects (e.g., side effects, error handling), doesn't explain the transaction outcome or return values, and provides minimal context beyond the basic action. Given the complexity and lack of structured data, more completeness is needed.
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 the schema already documents all three parameters (tokenName, tokenTicker, numDecimals) with basic descriptions. The description adds no additional meaning about parameters beyond implying they are used to issue the collection. No syntax, format, or constraints beyond the schema are provided, meeting the baseline for high schema coverage.
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's purpose: 'Create a transaction to issue a MetaESDT token collection (MESDT) and send it.' It specifies the action (create and send transaction) and resource (MetaESDT token collection). However, it doesn't explicitly differentiate from sibling tools like 'issue-nft-collection' or 'issue-semi-fungible-collection' beyond mentioning MetaESDT specifically.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when this tool is appropriate, prerequisites, or how it differs from similar tools like 'issue-nft-collection' or 'issue-semi-fungible-collection' in the sibling list. The statement 'All the properties will be set to true' is vague and doesn't clarify usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions creating a transaction and sending it, implying a write operation, but lacks details on permissions, costs, rate limits, or what 'All the properties will be set to true' means operationally. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, but the second sentence ('All the properties will be set to true') is vague and doesn't add clear value. The first sentence is front-loaded with the core purpose, but overall structure could be improved by clarifying the ambiguous statement.
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?
Given the complexity of issuing and sending NFTs (a mutation operation), no annotations, no output schema, and ambiguous statements in the description, this is incomplete. The description fails to explain critical aspects like transaction outcomes, error handling, or what 'send it' entails, leaving significant gaps for the agent.
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 the schema already documents both parameters (tokenName and tokenTicker). The description adds no additional meaning beyond what the schema provides, such as format constraints or examples. The baseline score of 3 is appropriate when the schema does the heavy lifting.
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's purpose: 'Create a transaction to issue a non-fungible token collection (NFT) and send it.' This specifies the verb (create transaction to issue and send) and resource (NFT collection). However, it doesn't explicitly differentiate from siblings like 'issue-meta-esdt-collection' or 'issue-semi-fungible-collection' beyond mentioning 'NFT' in the name.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, timing, or compare it to sibling tools like 'issue-fungible-token' or 'issue-meta-esdt-collection', leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions creating a transaction and sending tokens, implying a write operation, but doesn't cover critical aspects like required permissions, network fees, transaction finality, error handling, or what 'send' entails (e.g., recipient address). This leaves significant gaps for a tool that modifies state.
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?
The description is a single, well-structured sentence that efficiently conveys the core purpose. It front-loads key information (creating and sending tokens) and avoids redundancy, though it could be slightly more concise by removing 'Please also specify'.
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?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., transaction costs, success/failure outcomes), doesn't explain the relationship between token types and parameters, and omits context about the sending process (e.g., where tokens are sent).
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%, providing clear documentation for all parameters. The description adds minimal value beyond the schema, only implying that 'initialQuantity' and 'royalties' are relevant to the token creation process, without explaining their specific roles or interactions.
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 action ('create a transaction to issue') and the resource types (SFT, NFT, MetaESDT tokens), specifying that it's for a collection and involves sending. It distinguishes from sibling tools like 'issue-fungible-token' by covering multiple token types, but doesn't explicitly differentiate from 'issue-sft-collection' or similar siblings.
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 explicit guidance on when to use this tool versus alternatives like 'issue-semi-fungible-collection' or 'send-sft-nft-meta-tokens' is provided. The description implies usage for creating and sending specific token types, but lacks context on prerequisites, alternatives, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While 'Get' implies a read-only operation, it doesn't specify whether this requires authentication, has rate limits, returns specific data formats, or handles errors. For a tool with zero annotation coverage, this is insufficient.
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, efficient sentence that states the core purpose without any wasted words. It's appropriately sized for a simple query tool and gets straight to the point.
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?
For a query tool with no annotations and no output schema, the description should provide more context about what balance information is returned (native tokens, all tokens, specific format) and any behavioral constraints. The current description is too minimal given the lack of structured information elsewhere.
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 the schema already documents the single 'address' parameter with its bech32 format. The description adds no additional parameter information beyond what's in the schema, meeting the baseline for high schema coverage.
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 action ('Get the balance') and the resource ('for a MultiversX address'), making the tool's purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get-tokens-of-address' or 'get-wallet-address', which prevents a perfect score.
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?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'get-tokens-of-address' that might provide related information, there's no indication of when this specific balance query is appropriate versus other data retrieval tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that the tool creates and sends a transaction, implying a write operation, but lacks details on permissions, costs, network effects, or what 'All the properties will be set to true' entails. This leaves significant gaps in understanding the tool's behavior and risks.
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?
The description is concise with two sentences that directly address the tool's function. However, the second sentence ('All the properties will be set to true') is vague and adds minimal value, slightly reducing efficiency. Overall, it's well-structured and front-loaded with the main action.
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?
Given the complexity of issuing a token collection (a write operation with potential side effects), no annotations, and no output schema, the description is incomplete. It fails to explain return values, error conditions, or the implications of 'All the properties will be set to true', leaving the agent with insufficient context for safe and effective use.
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?
The input schema has 100% description coverage, with clear documentation for both parameters ('tokenName' and 'tokenTicker'). The description adds no additional meaning beyond what the schema provides, such as format examples or constraints, so it meets the baseline of 3 for adequate but not enhanced parameter semantics.
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 action ('Create a transaction to issue a semi-fungible collection (SFT) and send it') and specifies the resource ('collection'), making the purpose understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'issue-fungible-token' or 'issue-nft-collection', which would require mentioning unique aspects of semi-fungible tokens to earn a 5.
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?
The description provides no guidance on when to use this tool versus alternatives like 'issue-fungible-token' or 'issue-nft-collection', nor does it mention prerequisites or exclusions. It only states what the tool does, leaving the agent to infer usage from context without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool 'will send the specified token,' implying a write operation, but doesn't cover critical aspects like transaction costs, confirmation times, error handling, or whether the action is irreversible. This leaves significant gaps for a financial transaction tool.
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?
The description is concise and front-loaded, with two sentences that directly state the tool's purpose and key constraint (wallet from env). There's no unnecessary information, though it could be slightly more structured by separating usage notes.
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?
Given the complexity of a financial transaction tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., transaction finality, errors), output format, and clear differentiation from siblings. This makes it inadequate for safe and effective use by an AI agent.
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 the schema fully documents the parameters (amount, token, receiver). The description adds no additional meaning beyond what's in the schema, such as format examples or constraints. However, with high schema coverage, a baseline score of 3 is appropriate as the schema handles the heavy lifting.
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 action ('Create a fungible token transfer transaction and send it') and resource ('fungible token'), distinguishing it from sibling tools like send-egld (which sends native currency) or send-sft-nft-meta-tokens (which sends non-fungible tokens). However, it doesn't explicitly mention that this is for sending tokens other than EGLD, which would make it fully distinct.
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?
The description provides minimal guidance, stating only that it uses 'the wallet set in the env.' It doesn't explain when to use this tool versus alternatives like send-egld (for native currency) or send-sft-nft-meta-tokens (for non-fungible tokens), nor does it mention prerequisites such as having sufficient balance or proper wallet configuration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool retrieves a network set in the environment config, implying a read-only operation, but doesn't disclose behavioral traits such as error handling (e.g., if no network is set), performance (e.g., caching), or output format. This leaves gaps for a tool with no annotation coverage.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and appropriately sized for a simple tool, with zero waste or redundancy.
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?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is minimally adequate. It explains what the tool does but lacks details on output (e.g., network name, configuration object) and behavioral context, which could be helpful despite the simplicity. It meets basic needs but has clear gaps in completeness.
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 tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add param info, but with no params, the baseline is 4, as it adequately covers the lack of inputs without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool retrieves a network configuration, which is a clear purpose, but it's vague about what 'network' means (e.g., blockchain network, network settings) and doesn't distinguish it from siblings like 'get-balance-of-address' or 'get-wallet-address'. It uses a specific verb ('Get') but lacks resource specificity beyond 'network'.
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 is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., environment setup), exclusions, or how it relates to sibling tools like 'get-wallet-address' for network-specific operations. The description implies usage for configuration retrieval but offers no contextual boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves an address but doesn't clarify if this is a read-only operation, requires authentication, has side effects, or details error conditions. This is a significant gap for a tool in a financial/blockchain context.
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, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse quickly.
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?
Given the complexity of a wallet tool in a blockchain context, the description is insufficient. With no annotations and no output schema, it lacks details on behavior (e.g., read-only vs. mutating), error handling, or return format (e.g., what the bech32 address looks like), leaving gaps for safe agent operation.
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 tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter details, but that's appropriate here, as it focuses on the tool's purpose without redundancy.
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 action ('Get') and the specific resource ('bech32 address of the wallet set in the environment config'), which is a well-defined purpose. It doesn't explicitly differentiate from siblings like 'get-balance-of-address' or 'get-tokens-of-address', but the focus on the wallet address itself is clear enough to avoid confusion.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a configured wallet), exclusions, or comparisons to sibling tools like 'get-balance-of-address' or 'create-wallet', leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It mentions that transactions are created and sent, and the wallet is set in the environment, which adds some behavioral context. However, it lacks details on permissions, rate limits, error handling, or what happens upon execution (e.g., transaction IDs, confirmation). For a tool that performs financial transactions, this is a significant gap.
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?
The description is concise with two sentences that directly state the tool's purpose and key details (wallet from environment). It is front-loaded with the main action, though it could be slightly more structured by explicitly separating purpose from constraints.
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?
Given the complexity of a financial transaction tool with no annotations and no output schema, the description is incomplete. It lacks information on return values (e.g., transaction hashes), error cases, or behavioral nuances like atomicity of sends. For a tool with 2 parameters and significant implications, more context is needed.
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 the schema already documents both parameters ('amount' and 'receivers') with details like denomination and address format. The description does not add any additional meaning beyond what the schema provides, such as constraints or examples. Baseline 3 is appropriate as the schema handles the heavy lifting.
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 action ('create move balance transactions and send them') and resource ('EGLD'), specifying it sends to multiple receivers. It distinguishes from the sibling 'send-egld' by mentioning multiple receivers, though not explicitly naming the sibling. However, it could be more specific about the transaction creation aspect.
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 when sending EGLD to multiple receivers, as opposed to the sibling 'send-egld' for single receivers, but does not explicitly state when to use this tool versus alternatives. It mentions the wallet is set in the environment, providing some context, but lacks explicit guidance on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool sends tokens using a wallet from the environment, which implies a write operation, but does not disclose critical traits like authentication requirements, rate limits, transaction costs, or potential side effects (e.g., irreversible transfers). This leaves significant gaps in understanding the tool's behavior and risks.
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?
The description is concise and front-loaded, stating the core purpose in the first sentence and adding a brief operational detail in the second. There is no unnecessary information, and it efficiently communicates the tool's function without redundancy. However, it could be slightly improved by structuring usage guidelines more explicitly.
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?
Given the complexity of a token transfer tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., security, errors), output format, and differentiation from sibling tools. While the schema covers parameters well, the overall context for safe and effective use is insufficient, especially for a write operation involving financial transactions.
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?
The input schema has 100% description coverage, providing clear details for each parameter (token, amount, receiver). The description adds minimal value beyond the schema, only noting that amount is 'ONLY needed for SFT or Meta-ESDT,' which clarifies usage but does not significantly enhance parameter understanding. With high schema coverage, the baseline score of 3 is appropriate as the description does not compensate with additional semantic insights.
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's purpose: 'Create a nft, sft or meta esdt transfer transaction and send it.' It specifies the action (create and send) and the resource (NFT, SFT, or Meta-ESDT tokens). However, it does not explicitly differentiate from sibling tools like 'send-fungible-tokens' or 'send-egld', which handle other token types, leaving some ambiguity in distinguishing use cases.
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 sending NFT, SFT, or Meta-ESDT tokens, but does not provide explicit guidance on when to use this tool versus alternatives like 'send-fungible-tokens' or 'send-egld'. It mentions the wallet is set in the environment, which gives some context, but lacks clear when-to-use or when-not-to-use statements, such as specifying token type constraints or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions transaction creation and sending, implying a write operation, but lacks details on permissions, rate limits, confirmation behavior, or error handling. It adds minimal context beyond the basic action.
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, efficient sentence with zero waste, front-loading the core action and key details (wallet source, receiver specification). Every word contributes essential information.
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?
For a 2-parameter tool with no annotations and no output schema, the description covers the basic purpose and usage but lacks behavioral details like transaction outcomes, error cases, or dependencies. It's minimally adequate given the simplicity but could be more informative.
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 the schema fully documents parameters. The description adds no additional parameter meaning beyond what the schema provides, such as format examples or constraints, meeting the baseline for high coverage.
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 action ('Create a move balance transaction and send it') and resource ('send EGLD'), specifying it uses the wallet from environment variables. It distinguishes from sibling 'send-egld-to-multiple-receivers' by implying single-receiver scope, though not explicitly named.
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 sending EGLD to a single receiver, with an alternative hinted at ('send-egld-to-multiple-receivers' for multiple receivers). However, it lacks explicit when-not-to-use guidance or comparisons with other send tools like 'send-fungible-tokens'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context: default returns (first 25 of each token type), ability to specify size, and that the returned list contains twice the specified number if available. However, it doesn't cover critical aspects like rate limits, authentication needs, error conditions, or pagination behavior, leaving gaps for a read operation tool.
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?
The description is appropriately sized and front-loaded, starting with the core purpose. Each sentence adds value: explaining default returns, how to adjust size, and the total token count. There's no wasted text, but the structure could be slightly improved by separating key points more clearly, such as listing token types upfront.
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?
Given no annotations and no output schema, the description provides basic completeness for a read operation tool with two parameters. It covers the tool's behavior and parameter usage reasonably well, but lacks details on output format (e.g., structure of returned tokens), error handling, or performance considerations, which are important for full contextual understanding.
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 the schema already documents both parameters (address and size) adequately. The description adds marginal value by explaining the default size (25) and that size affects both fungible and non-fungible token counts, but doesn't provide additional semantics beyond what the schema offers. This meets the baseline for high schema coverage.
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's purpose: 'Get the tokens of an address.' It specifies the resource (tokens) and verb (get), and distinguishes it from siblings like get-balance-of-address by focusing on token holdings rather than balance. However, it doesn't explicitly differentiate from other token-related tools like send-fungible-tokens, which slightly reduces specificity.
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 retrieving token lists from an address, with context on default behavior and how to adjust token counts. It mentions 'To get more tokens, specify the number,' which provides some guidance on when to use the size parameter. However, it lacks explicit when-not-to-use scenarios or comparisons to alternatives like get-balance-of-address, leaving usage somewhat inferred rather than clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: the creation action, file output format (PEM), security implications ('PEM file ARE NOT SECURE'), and idempotency behavior ('will abort operation' if wallet exists). It doesn't cover rate limits or authentication needs, but provides substantial operational context.
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 extremely concise with just two sentences that each earn their place: the first states the core functionality and output format with a critical security warning, the second specifies important behavioral constraints. There's zero wasted text and it's front-loaded with the main purpose.
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?
For a zero-parameter creation tool with no annotations or output schema, the description provides good completeness: it explains what the tool does, the output format, security implications, and idempotency behavior. The main gap is lack of information about what 'wallet' means in this context or what happens after creation, but given the simplicity of the tool, this is reasonably complete.
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 0 parameters and 100% schema description coverage, the baseline would be 4. The description appropriately doesn't discuss parameters since there are none, and instead focuses on the tool's operational semantics and output characteristics, which adds value beyond the empty 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 clearly states the tool's purpose with specific verbs ('create a new wallet', 'save it as a PEM file') and distinguishes it from siblings by focusing on wallet creation rather than token operations or queries. It goes beyond restating the name by specifying the output format and security warning.
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 provides clear context about when to use this tool (to create a new wallet) and includes an important exclusion case ('If a wallet already exists, will abort operation'). However, it doesn't explicitly mention alternatives or when not to use it compared to sibling tools like get-wallet-address.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mx-mcp MCP server](https://glama.ai/mcp/servers/multiversx/mx-mcp/badges/card.svg)](https://glama.ai/mcp/servers/multiversx/mx-mcp)

Score Badge

Copy to your README.md:

[![mx-mcp MCP server](https://glama.ai/mcp/servers/multiversx/mx-mcp/badges/score.svg)](https://glama.ai/mcp/servers/multiversx/mx-mcp)

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/multiversx/mx-mcp'

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