TokenTool MCP

Overview

TokenTool MCP gives AI agents a complete token issuance and lifecycle management API built on Bitbond TokenTool — 8,300+ deployments, CertiK-audited smart contracts, compliance features built in. Supports EVM (Ethereum, Polygon, BNB Chain, Arbitrum, Base, Optimism, Avalanche + testnets), Solana (SPL tokens), and Stellar (assets).

Pricing: Testnet deployments are free (gas only). Mainnet deployments cost a flat $299 fee paid in native token + gas.

Security: Private keys stay local (env vars only). The MCP server uses stdio transport — no network listener, no open ports. Keys are never logged or transmitted.

Available Tools

Instructions

Workflow 1: Deploy a New Token

1. Gather requirements. Ask the user for:

• Token name and symbol
• Initial supply
• Target chain (if unsure, call list_chains to show options)
• Compliance features needed (whitelist, blacklist, pausable, force_transfer, document_uri, max_supply)
• Whether they want mintable and/or burnable enabled

1. Recommend testnet first if the user hasn't deployed before or seems unsure. Sepolia (EVM), Solana Devnet, or Stellar Testnet are free and functionally identical to mainnet.

1. Show the cost. Call estimate_cost with the target chain before deploying. Tell the user the cost in native token and USD equivalent. Mainnet = $299 flat + gas. Testnet = gas only (~free).

1. Get explicit confirmation before calling deploy_token on mainnet. This costs real money.

1. Call `deploy_token` with all parameters. Include compliance flags only if the user requested them.

1. Return results clearly: contract address, explorer link, transaction hash, features enabled, and what they can do next (mint, transfer, pause, etc.).

Workflow 2: Manage an Existing Token

For post-deployment operations, you need the contract address and chain. If the user doesn't provide these:

• Call list_deployed_tokens to find their tokens
• Ask which one they mean if there are multiple

Minting: Call mint_tokens — only works if the token was deployed with mintable=true. Requires the recipient address and amount.

Burning: Call burn_tokens — only works if burnable=true. Burns from the deployer's balance.

Transferring: Call transfer_tokens with recipient address and amount.

Pausing/Unpausing: Call pause_token to halt all transfers (emergency stop). Call unpause_token to resume. Only works if pausable=true.

Checking status: Call get_token_info to see current on-chain state — supply, owner, paused status, etc.

Workflow 3: Compliance Setup

Recommend compliance features based on the use case:

• Whitelist — for security tokens, regulated assets, investor-only tokens. Only approved addresses can hold/receive tokens. Recommend when: KYC/AML requirements, accredited investor restrictions, or jurisdictional compliance. After deployment, use add_to_whitelist to approve addresses (batch supported) and get_whitelist to view current whitelist. Use get_compliance_status to check both whitelist and blacklist state at once.

• Blacklist — for blocking sanctioned or suspicious addresses. Recommend when: OFAC compliance, preventing known bad actors, or responding to exploit addresses. After deployment, use add_to_blacklist to block addresses and remove_from_blacklist to unblock them.

• Pausable — emergency stop capability. Recommend for: any token with significant value, security tokens, or tokens where the issuer needs a kill switch.

• Force Transfer — allows the owner to move tokens between addresses without holder consent. Recommend for: regulatory recovery scenarios, court-ordered transfers, lost key recovery for compliant tokens.

• Document URI — attaches a legal document (prospectus, term sheet, offering memorandum) on-chain. Recommend for: security tokens, RWA tokens, any regulated offering.

• Max Supply — hard cap enforced at the contract level, cannot be changed after deployment. Recommend when: tokenomics require a guaranteed supply ceiling.

For a typical security token / RWA issuance, recommend: whitelist + pausable + force_transfer + document_uri.

For a typical utility / governance token, recommend: mintable + burnable + pausable.

Workflow 4: Multi-Chain Comparison

When a user is deciding between chains:

1. Call estimate_cost for each candidate chain
2. Call get_wallet_info for each to check balances
3. Present a comparison: cost, speed, ecosystem, and whether they have sufficient balance

Environment Variables

At least one key must be set. The server works for read-only operations (list_chains, get_token_info on EVM) without keys, but all write operations require the appropriate key.

Examples

User: "Deploy a governance token called DAO Vote, 10M supply on Polygon, mintable and burnable."

→ Call estimate_cost with chain="polygon" → Show cost → Get confirmation → Call deploy_token with name="DAO Vote", symbol="DAOV", supply="10000000", chain="polygon", mintable=true, burnable=true → Return contract address + explorer link.

User: "How much would it cost to deploy on Base vs Arbitrum?"

→ Call estimate_cost with chain="base" and estimate_cost with chain="arbitrum" in parallel → Present comparison table with gas + fee in native token and USD.

User: "Pause all transfers on my token 0xabc123 on Base — we found a vulnerability."

→ Call pause_token with contract_address="0xabc123", chain="base" → Confirm pause succeeded → Suggest next steps (investigate, then unpause_token when ready).

User: "I want to create a security token for our real estate fund on Ethereum with full compliance."

→ Recommend: whitelist + pausable + force_transfer + document_uri → Ask for token name, symbol, supply, and document URI → Call estimate_cost on Ethereum → Warn about high Ethereum gas costs, suggest Base or Polygon as cheaper alternatives → Get confirmation → Deploy with all compliance flags.

User: "Show me what I've deployed."

→ Call list_deployed_tokens → Format as a readable list with chain, name, symbol, address, and explorer links.

User: "Create an SPL token on Solana with 1 billion supply."

→ Confirm name and symbol → Call deploy_token with chain="solana" → Note: requires BITBOND_SOLANA_KEYPAIR env var. If not set, the error will say so — tell the user how to configure it.

Troubleshooting

References

For detailed chain and compliance documentation, see references/:

• references/chain-details.md — full chain registry with IDs, RPCs, explorers, aliases, and required env vars
• references/compliance-features.md — deep dive on each compliance feature with regulatory context and configuration examples