Skip to main content
Glama
Mr-Money01

Monei MCP Server

by Mr-Money01
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
TypeScript
Hybrid

Send Crypto (Solana)

monei_send_crypto_solana
Destructive

Send crypto from your Solana wallet to any external address, supporting native SOL and SPL tokens like USDC or USDT. Provide a token mint address for tokens, or omit it to send SOL.

Instructions

Sends cryptocurrency from the user's Monei Solana wallet to an external wallet address.

Handles both native SOL and SPL tokens (USDC, USDT on Solana) with a single tool. Routing is automatic: if tokenMintAddress is provided it sends the SPL token, otherwise it sends SOL.

Before calling:

  1. Confirm sufficient balance using monei_get_solana_portfolio

  2. Ask for the user's transaction PIN if not already provided — never store or log it

  3. Show the recipient address and amount to the user and get explicit confirmation before sending

Args:

  • to (string): Recipient Solana wallet address (base58 encoded)

  • amount (string): Amount to send as a string

  • network (string, optional): "mainnet-beta" (default), "devnet", or "testnet"

  • tokenMintAddress (string, optional): SPL token mint address — omit to send native SOL

  • transactionPin (string): User's 4-6 digit PIN — ask at runtime, never store

Returns: { "signature": string, // Solana transaction signature "status": string, "amount": string, "token": string, // "SOL" or the SPL token symbol "to": string, "network": string }

Examples:

  • "Send 2 SOL to 5AH3..." -> amount: "2", no tokenMintAddress

  • "Send 50 USDC on Solana to 5AH3..." -> amount: "50", tokenMintAddress: USDC mint address on Solana

Security: Never log or store the transactionPin.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toYesRecipient Solana wallet address (base58 encoded)
amountYesAmount to send as a string (e.g. '2' for 2 SOL, '50' for 50 USDC)
networkNoSolana network to use. Defaults to mainnet-beta.mainnet-beta
transactionPinYesUser's 4-6 digit transaction PIN. Ask for this at runtime — never store or log it.
tokenMintAddressNoSPL token mint address. Omit for native SOL transfers. Include for SPL tokens like USDC, USDT on Solana.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv1.3.1

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already flag this as non-read-only, non-idempotent, and destructive, so the baseline burden is lower. The description adds valuable behavior: automatic token-vs-SOL routing, PIN handling rules, and the requirement to show the recipient and amount before sending. There is no contradiction with the annotations.

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 well-structured with summary, routing behavior, pre-call checklist, args, returns, examples, and security note. It is somewhat longer than necessary and repeats some schema parameter descriptions, but the extra detail is justified for a financial send operation with security caveats.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

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 explicit return object with signature, status, amount, token, to, and network is essential and provided. The description covers required parameters, optional network selection, SPL routing, examples, and security constraints, making it complete enough for an agent to invoke the tool correctly.

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?

Schema coverage is 100%, so the schema already documents all parameters clearly. The description adds meaning beyond the schema by explaining the routing rule for tokenMintAddress, providing concrete examples like 'Send 2 SOL' and 'Send 50 USDC', and clarifying that amount is a string.

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 opens with a specific verb and resource: 'Sends cryptocurrency from the user's Monei Solana wallet to an external wallet address.' It clearly distinguishes this tool from the EVM and naira send siblings by specifying Solana and covering both native SOL and SPL tokens.

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 gives an explicit before-calling workflow: check balance, ask for PIN at runtime, and get user confirmation before sending. It also explains automatic routing between SOL and SPL tokens. It does not explicitly name monei_send_crypto_evm as an alternative, but the Solana scope makes the intended use clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

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/Mr-Money01/mcp-server'

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