Sell Crypto for Naira

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

Annotations already declare destructiveHint=true and idempotentHint=false, so the description's job is to add context. It does: it states the tool 'initiates the swap', returns a reference for tracking, lists possible statuses ('initiated' or 'awaiting_deposit'), and warns to get explicit confirmation after showing the quote. Minor gap: it doesn't explicitly state whether crypto is deducted immediately or if a deposit is required first, though the return object hints at it via 'onChain' deposit details.

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 well-structured with clear sections: summary, pre-call checklist, Args list, Returns snippet, and post-call instructions. It front-loads the core purpose and flow. The Args list is somewhat redundant with the schema, adding length without new information, but the overall organization is strong for a complex financial tool.

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 this is a 7-parameter, potentially destructive tool with no output schema, the description is notably complete. It explains prerequisites, the required parameter values, the return object shape with field meanings, the expected settlement timeframe, and follow-up tracking via monei_track_offramp. An agent can confidently determine how and when to call it.

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?

Schema coverage is 100%: every one of the 7 parameters has a schema description, enums, defaults, or patterns. The description's Args list largely repeats the schema (e.g., token allowed values, network list, accountNumber format). It adds minimal new semantic value beyond the schema, so the baseline 3 is appropriate.

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 uses a specific verb–resource pair: 'Sells cryptocurrency and sends the NGN proceeds to a Nigerian bank account.' It clearly identifies this as the crypto offramp tool and distinguishes it from siblings like monei_send_naira_to_bank and monei_generate_deposit_link. It also names the full flow ('complete offramp flow'), leaving no ambiguity about what the tool accomplishes.

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 a numbered before-calling checklist naming exact sibling tools: check balance via monei_get_evm_portfolio or monei_get_wallet, call monei_get_offramp_quote, call monei_verify_bank_account, then get explicit user confirmation. It also tells the agent what to do after initiation: share the reference, mention 5–10 minute settlement, and use monei_track_offramp for progress. This is explicit, actionable usage guidance.

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