Enables bulk transfers of BNB (Binance Coin) and BEP20 tokens on the Binance Smart Chain (BSC), allowing users to distribute native BNB and tokens to multiple addresses in single transactions.
Provides repository access for cloning the MCP server code from GitHub (kukapay/bsc-multisend-mcp).
Runs on Node.js environment (version 18+) to execute the BSC MultiSend MCP server which facilitates bulk cryptocurrency transfers on the Binance Smart Chain.
Uses pnpm as the package manager for installing and managing the MCP server dependencies.
Displays status badges in the README to indicate license type, Node.js version requirements, and project status.
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., "@bsc-multisend-mcp distribute 0.1 BNB to 0x123...abc and 0.2 BNB to 0x456...def"
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.
An MCP server that enables agents to perform bulk BNB and BEP20 token transfers on BSC.
distributeNative Tool: Sends BNB to multiple addresses in a single transaction.
Parameters:
receivers: Array of BSC addresses to receive BNB.
amounts: Array of BNB amounts (e.g., 0.1 BNB) to send, automatically summed for the total.
Automatically converts amounts to wei and handles gas estimation.
distributeToken Tool: Sends BEP20 tokens to multiple addresses.
Parameters:
tokenAddress: Address of the BEP20 token contract.
receivers: Array of BSC addresses to receive tokens.
amounts: Array of token amounts (e.g., 100.5 tokens).
Queries token decimals, checks allowance, and auto-approves if needed.
Related MCP server: bnbchain-mcp
Node.js: Version 18 or higher.
pnpm: For installing dependencies.
BNB Smart Chain Wallet: A wallet with sufficient BNB for gas and tokens for distribution.
BSC RPC Endpoint: Access to a BSC node (e.g., https://bsc-dataseed.binance.org/).
Clone the repository:
git clone https://github.com/kukapay/bsc-multisend-mcp.git
cd bsc-multisend-mcpInstall dependencies:
pnmp installConfigure MCP client:
Claude Desktop configuration file as a reference:
{
"mcpServers": {
"BSC MultiSend": {
"command": "node",
"args": [ "/path/to/bsc-multisend-mcp/index.js" ],
"env": { "PRIVATE_KEY": "your-private-key" }
}
}
} Replace /path/to/bsc-multisend-mcp with your actual installation path, and your-private-key with your BSC wallet private key.
The server offers two tools — distributeNative and distributeToken — for bulk token distribution.
Purpose: Distributes BNB to multiple addresses in a single transaction.
Example Prompt:
I want to send 0.1 BNB to 0xRecipient1 and 0.2 BNB to 0xRecipient2 on BSC.Expected Response:
BNB distribution successful. Tx Hash: 0x...Purpose: Distributes BEP20 tokens to multiple addresses. It queries the token's decimals, checks the contract's allowance, approves the contract if needed, and executes the transfer.
Example Prompt:
Send tokens to the following addresses on BSC using the token contract at 0xTokenAddress:
- 0xRecipient1: 100.5 tokens
- 0xRecipient2: 200 tokens
- 0xRecipient3: 50.75 tokens
- 0xRecipient4: 150 tokens
- 0xRecipient5: 75.25 tokensExpected Response:
Token distribution successful. Tx Hash: 0x...This project is licensed under the MIT License. See the LICENSE file for details.
Send BNB to multiple addresses on BSC using the C98MultiSend contract.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions using a specific contract ('C98MultiSend contract') but doesn't disclose critical behavioral traits like transaction costs, gas requirements, success/failure handling, security implications, or rate limits. For a financial transaction tool with zero annotation coverage, this is a significant gap in transparency.
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 with zero waste. It's appropriately sized for a simple tool and front-loaded with the core action and resource. Every word earns its place, 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?
Given the complexity of a financial transaction tool with no annotations and no output schema, the description is incomplete. It lacks details on return values, error handling, network conditions, or operational constraints. For a tool that sends cryptocurrency, this minimal description fails to provide adequate 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details beyond the schema, but since there are no parameters, this is appropriate. Baseline 4 is correct for zero-parameter tools where the schema fully covers the absence of inputs.
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 action ('Send BNB'), target resource ('multiple addresses'), and context ('on BSC using the C98MultiSend contract'). It distinguishes from the sibling tool 'distributeToken' by specifying BNB instead of tokens, though it doesn't explicitly name the alternative. The purpose is specific and actionable.
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 like 'distributeToken'. The description implies usage for BNB distribution on BSC, but lacks explicit when/when-not criteria, prerequisites, or comparisons with sibling tools. It's a basic functional statement without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send ERC20 tokens to multiple addresses on BSC using the C98MultiSend contract.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 the action ('Send ERC20 tokens') and contract ('C98MultiSend'), but fails to disclose critical behavioral traits like required permissions, transaction costs, rate limits, error handling, or whether this is a read-only or mutative operation, leaving significant gaps in understanding the tool's behavior.
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 any wasted words. It is front-loaded with the core action and context, making it highly concise and well-structured for quick understanding.
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?
Given the complexity of token distribution on a blockchain, the lack of annotations, no output schema, and the description's minimal detail, this is incomplete. It doesn't cover return values, error cases, or practical usage nuances, making it insufficient for safe and effective tool invocation in a real-world context.
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?
The input schema has 0 parameters with 100% coverage, meaning no parameters are defined. The description implies parameters related to token distribution (e.g., addresses, amounts) but doesn't specify them, which is acceptable since the schema indicates no parameters are needed. However, this could be confusing if parameters are actually required in practice, warranting a score just below perfect.
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 action ('Send ERC20 tokens') and target ('to multiple addresses on BSC using the C98MultiSend contract'), which is specific and actionable. However, it doesn't explicitly differentiate from its sibling 'distributeNative', which likely distributes native BNB instead of ERC20 tokens, leaving some room for improvement in sibling distinction.
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 provides no guidance on when to use this tool versus alternatives, such as its sibling 'distributeNative'. It lacks explicit instructions on prerequisites, timing, or scenarios where this tool is preferred, offering only a basic functional statement without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
distributeNativedistributeTokenThe two tools have clearly distinct purposes: one handles native BNB transfers and the other handles ERC20 token transfers. There is no overlap or ambiguity between them, as each targets a specific asset type with no functional duplication.
Both tools follow a consistent verb_noun pattern with 'distribute' as the verb and descriptive nouns ('Native', 'Token'). The naming is perfectly uniform and predictable across the set.
With only 2 tools, the set feels thin for a multisend server, lacking operations like checking balances, viewing transaction history, or handling batch configurations. While the core functionality is present, the scope is minimal and may limit agent workflows.
The server covers the basic distribution actions for two asset types but has significant gaps: no tools for querying contract status, validating addresses, estimating gas, or managing batches. This incomplete surface could lead to agent failures in complex scenarios.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Multi-chain wallet MCP. 18 tools: balance, swap, bridge, stake, claim. Pay-per-call USDC (x402 v2).
MCP Server for an Agent Task Marketplace
MCP server connecting AI agents to non-custodial staking data across 130+ networks.
MCP Server for agents to onboard, pay, and provision services autonomously with InFlow
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/kukapay/bsc-multisend-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
