Skip to main content
Glama

Send Naira to Bank

monei_send_naira_to_bank
Destructive

Send NGN from your Monei wallet to any Nigerian bank account. Verify the recipient's name first, then use the bank code and 10-digit account number to complete the transfer.

Instructions

Sends NGN from the user's Monei wallet to any Nigerian bank account.

Before calling this tool:

  1. Confirm the user has sufficient NGN balance using monei_get_wallet

  2. Call monei_verify_bank_account to get the account holder's name and show it to the user for confirmation

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

Args:

  • amount (number): Amount in NGN to send (e.g. 20000 for ₦20,000)

  • bankCode (string): Bank code from monei_get_banks (e.g. "058" for GTBank)

  • accountNumber (string): 10-digit recipient bank account number

  • transactionPin (string): User's 4-6 digit transaction PIN — ask for this at runtime

  • narration (string, optional): Note for the transfer (max 100 characters)

Returns: { "reference": string, "status": string, // "PENDING" | "COMPLETED" | "FAILED" "amount": number, }

Examples:

  • "Send ₦20,000 to my GTBank account 0123456789" -> verify account first, then call with bankCode="058"

  • "Pay 5000 naira to account 0987654321 at UBA" -> verify, confirm name, then send

Security: Never log or store the transactionPin. Pass it directly to this call only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
amountYesAmount in NGN to send (e.g. 20000 for ₦20,000)
bankCodeYesBank code (e.g. '058' for GTBank, '033' for UBA). Call get_banks to get the full list of bank codes.
narrationNoOptional description or note for the transfer (max 100 characters)
accountNumberYesNigerian bank account number (exactly 10 digits)
transactionPinYesUser transaction PIN (4-6 digits). Required for all money movement operations. Prompt the user for this if not provided — never store or log it.

Schema Changelog

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

  1. First observedv1.3.1

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already flag readOnlyHint=false, destructiveHint=true, and idempotentHint=false, which are consistent with a money-movement call. The description adds genuine behavior context beyonnd those flags: the PIN must never be stored or logged, the recipient account must be verified before calling, and the returned status enum (PENDING/COMPLETED/FIALED) is disclosed.s No contradiction with 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 front-loaded with the core purpose and organized into clearly delineated sections (pre-call checklist, Args, Returns, Examples, Security). It is longer than average, but every section earns its place given the tool's money-movement and security implications.

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 security-sensitive tool with five parameters and no output schema, the description is comprehensive: it covers purpose, pre-conditions, parameter formats, return shape, examples, and key behavioral rules. Gaps are minor -- failure-path semantics are only the status enum, and there is no explicit routing note pointing intra-wallet transfers to monei_send_naira_to_user.

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 five parameters and the baseline is 3. The Args section largely restates schema content (e.g., bankCode '058' for GTBank, 10-digit accountNumber, narration max 100 chars), adding only marginal value such as the runtime-ask framing for transactionPin and concrete natural-language-to-amount examples.

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 opening sentence 'Sends NGN from the user's Monei wallet to any Nigerian bank account' states a specific verb, resource, and destination. The phrase 'any Nigerian bank account' distinguishes it from the sibling monei_send_naira_to_user, which targets other Monei users, so an agent can tell them apart without opening either schema.

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?

Provides an explicit numbered pre-call checklist naming the exact sibling tools to invoke first (monei_get_wallet to confirm balance, monei_verify_bank_account to confirm the recipient name) and instructs asking for the PIN at runtime. It stops just short of a 5 because it never explicitly says when not to use this tool versus its closest sibling monei_send_naira_to_user.

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

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