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

Although annotations already mark it readOnly, idempotent, and non-destructive, the description adds substantial behavior: it reveals the return shape, all four possible status values, and the poll-until-resolution pattern. Since there is no output schema, this return contract is essential and well covered.

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 cleanly sectioned: purpose, when-to-use, parameter, return contract, and examples. It is front-loaded with the operative verb and resource, and every block adds decision-relevant information. The examples are short and demonstrate natural-language invocation.

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?

For a single-parameter, no-output-schema read-only tool, this is complete. It specifies the input, the full response contract including status enum, the intended workflow position after link generation, and the polling strategy. Nothing that an agent needs to correctly select and invoke the tool is missing.

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 already documents 'reference' at 100% coverage, giving baseline 3. The description improves on that by identifying the exact provenance of the value: 'The reference returned from monei_generate_deposit_link.' This tells an agent where to obtain the parameter, which is more useful than the generic schema description.

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 opens with a clear verb-resource statement: 'Checks the status of a deposit by its reference string.' It names the exact resource (deposit), the action (check status), and the input (reference). Among siblings, only this tool and monei_generate_deposit_link involve deposits, so it is readily distinguishable.

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?

It explicitly explains when to call it: 'Use this after generating a deposit link to confirm whether the user has completed payment,' and gives a concrete polling cadence of every 30-60 seconds. It does not enumerate exclusions or name alternatives, but the usage context is specific enough for an agent.

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

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

The description adds meaningful behavioral context beyond the annotations: this is a one-call flow, the user must complete the payment externally, and the agent should tell the user to check status afterward. The reference for status checking is mentioned but not fully defined, and the absence of an output reference field creates slight ambiguity.

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 organized with clear sections: purpose, args, returns, follow-up instructions, and examples. It front-loads the core workflow and every section contributes actionable guidance without unnecessary filler.

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 that there is no output schema, the description compensates by documenting the return shape and the post-return user flow. Examples and exclusions round out the context, but the 'reference' used for status checks is never clearly introduced, leaving a minor ambiguity.

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%, so the baseline is 3, but the description adds value with practical natural-language examples ('₦50,000' -> 50000, '₦10k' -> 10000) and clarifies that the optional customer fields pre-fill the payment page. These details help the agent map user requests to correct parameter values.

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 states a specific action ('Generates a payment link'), a clear resource ('deposit NGN into their Monei wallet'), and explicitly distinguishes this from card and USSD multi-step flows. This makes it easy to separate from sibling tools like monei_send_naira_to_bank or monei_check_deposit_status.

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?

It clearly explains the intended deposit workflow: the user opens the returned link, pays via bank, and funds arrive in the NGN wallet. It also explicitly says card and USSD multi-step flows are not supported through this tool, though it does not name specific alternative tools for those flows.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds meaningful context beyond this: it discloses the exact response shape, indicates the data reflects the 'currently authenticated' user, and documents error cases such as invalid/expired API keys and suspended accounts.

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-organized with an opening summary, usage context, a concrete return shape, examples, and error handling. Each section adds value, especially since there is no output schema, and the structure is front-loaded with the most important information.

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 tool's low complexity, zero parameters, and rich annotations, the description is complete. It compensates for the missing output schema by documenting all returned fields and provides enough guidance on authentication, examples, and error behavior for an agent to invoke and interpret this tool correctly.

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?

This tool has zero parameters, so the baseline is 4. There are no parameter semantics to explain, and the description correctly focuses on the returned profile and usage context instead of inventing unnecessary parameter details.

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 states a specific verb and resource: 'Returns the profile of the currently authenticated Monei user.' This clearly distinguishes it from sibling tools like monei_get_wallet or monei_get_transaction_history, which cover different resources.

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 clear guidance on when to use the tool: at the start of a session to identify the logged-in user, confirm identity, or check verification status. It does not explicitly mention when not to use it or name alternative tools, but the context is strong enough that an agent can select it appropriately.

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

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

Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to repeat safety semantics. It adds useful behavioral context by specifying the exact return shape and emphasizing that the bank code is 'required' by downstream tools, which goes beyond what annotations convey.

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 front-loaded with the core statement, followed by a highly relevant usage directive, a compact output example, and practical examples. Every section adds value; there is no filler or meaningless repetition, and the formatting makes it easy for an agent to scan.

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?

There is no output schema, so the description must document the return value, and it does so clearly with a banks array containing name and code. It also connects the result to the real-world workflow (bank payouts and verification), making the tool's role fully understandable in 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 zero parameters and no parameter descriptions are needed. The description does not document parameters, but the 0-param schema makes this a non-issue. Baseline 4 is appropriate because there is no parameter burden the description must carry.

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 opens with a specific verb-resource pairing: 'Returns the full list of Nigerian banks supported by Monei, including their bank codes.' This clearly distinguishes it from sibling tools like get_supported_networks and get_transaction_history, and the title 'Get Banks' reinforces the resource without creating ambiguity.

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 explicitly states when to use the tool: 'Call this before any payout to a bank account if you do not already have the bank code.' It also names the dependent tools (send_naira_to_bank and verify_bank_account), giving concrete routing guidance that is missing from most tool descriptions.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds interpretive context beyond that: status enum semantics (PENDING/SUCCESS/FAILED) that directly enable the 'did my payment go through' use case, the type enum, and field meanings such as customer (phone/meter/smartcard) and token (electricity prepaid meter). The pagination envelope (page, totalPages) is disclosed too, though the 'recent' window and pagination mechanics are left undefined.

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 first sentence states purpose, the second gives usage context, and the commented JSON block documents the output in one structured pass — appropriate since no output schema accompanies this tool. The three examples are distinct (list, status check, specific query) and earn their place, though the overall definition is on the longer side.

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?

For a zero-parameter, read-only tool with comprehensive annotations, this is nearly complete: the only thing the schema and annotations can't convey — return structure — is documented inline with field-level comments. The remaining gaps are minor: 'recent' is not time-bounded, and page size/pagination behavior is not described.

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 tool takes zero parameters, so the baseline is 4 and the description correctly avoids manufacturing parameter documentation. It instead documents the return payload thoroughly and offers client-side filtering guidance ('filter by type=UTILITYBILLS'), which is the closest thing to parameter semantics this tool has.

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 opens with a specific verb and resource — 'Returns the user's recent bill payment history' — and names the full category scope (airtime, data, electricity, cable TV). This explicit scope distinguishes it from sibling tools like monei_get_transaction_history (all transactions) and monei_pay_bill (initiating a payment), so an agent can route correctly without opening schemas.

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?

A dedicated paragraph states 'Use this when the user wants to review past bill payments, check if a payment went through, or audit utility spending,' which is clear, contextual guidance. Three concrete intent-to-action examples ('Did my electricity payment go through?', 'When did I last buy MTN airtime?') reinforce when to call it. However, no exclusions or explicitly named alternative tools are given, so it falls just short of a 5.

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

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

Annotations already declare readOnly and non-destructive behavior, and the description adds significant behavioral context beyond them: category-dependent response shapes, the fact that UTILITYBILLS returns all electricity providers, and how returned codes map to monei_pay_bill parameters. This does not contradict 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is long but well-organized with Routing, Args, Returns, and Examples sections, and the critical prerequisite is front-loaded. It earns its length because there is no output schema. Minor redundancy with the schema's Args descriptions prevents a 5.

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?

With no output schema, the description fully compensates by specifying return shapes for both UTILITYBILLS and the other categories, including the meaning of each field for downstream use. Examples cover the main category types, and routing rules are explicit, so an agent has enough context to invoke the tool correctly.

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 description coverage is 100%, so baseline is 3. The description adds extra semantic value by mapping billerCode/itemCode to monei_pay_bill fields and providing real examples for category/billerName combinations, helping the agent choose correct values beyond the schema alone.

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?

Description clearly states it returns available billers and packages for a bill category, using a specific verb and resource. It goes further to distinguish itself as the prerequisite lookup step before monei_pay_bill, separating it from payment and history siblings.

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?

Explicitly instructs 'Always call this before monei_pay_bill' and details category-specific routing, including when billerName is required and when it is not. Concrete examples show query-to-argument mapping. It does not explicitly contrast with monei_get_bill_history for history lookups, so it stops short of full when-not/alternative coverage.

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

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

Annotations already establish read-only, idempotent, and non-destructive behavior, so the description's burden is lower. It adds useful context by stating the result includes the native token, all ERC-20 holdings, USD values, and by providing an explicit JSON return shape. No contradictions with the annotations are present.

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 organized into clear sections (purpose, usage, args, returns, examples) and front-loads the core behavior. The Args list somewhat repeats schema information and the Returns block is long, but it compensates for the lack of an output schema and remains scannable.

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?

For a single-parameter read-only tool, the description is complete: it states the exact data returned, provides the full response shape, gives example chainIds with natural-language triggers, and names the alternative tool. Nothing needed to call it correctly is missing.

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 already documents chainId with all eight const values and per-chain descriptions (100% coverage), so the baseline is 3. The description adds practical natural-language mapping examples ('What tokens do I have on BSC?' -> 56) and shorthand common values, though it omits Scroll and Lisk from its list.

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 opening sentence states a specific action ('Returns the full token portfolio') with a precise scope ('EVM wallet on a specific chain') and content ('native token and all ERC-20 holdings with USD values'). This clearly differentiates it from balance-only tools like monei_get_wallet and from Solana-focused siblings.

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 explicitly instructs when to use the tool: 'Use this when the user wants a detailed breakdown of their crypto holdings on a specific EVM network.' It also names the alternative directly: 'For a simple balance check, use monei_get_wallet instead.' This direct routing leaves no ambiguity between siblings.

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

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

The annotations already establish read-only, idempotent, and non-destructive behavior. The description adds useful behavioral context beyond that: it returns a base58-encoded address and clarifies the purpose is for receiving SOL or SPL tokens. It doesn't add unnecessary claims about side effects or rate limits, which is appropriate for such a simple read-only tool.

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-organized and front-loaded. It states the function, gives usage conditions, shows the return shape, and provides examples. Every sentence earns its place, and the examples are genuinely helpful without being redundant.

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?

For a zero-parameter read-only tool with rich annotations and no output schema, the description is complete. It provides the return format, typical use cases, example invocations, and a clear distinction from the relevant sibling tool. An agent has everything needed to select and call it correctly.

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 tool has zero parameters, so there is no parameter semantics to document. The description instead clarifies the output, which is the relevant semantic content. The baseline of 4 for a zero-parameter tool 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 starts with a clear verb and resource: 'Returns the user's Solana wallet address' for receiving SOL or SPL tokens. It also distinguishes itself from the sibling tool by explicitly directing portfolio-related needs to monei_get_solana_portfolio.

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 usage guidance is explicit: it lists concrete trigger phrases like "What's my Solana address?" and "Share my Solana wallet", and explicitly says when NOT to use it (when full portfolio details are needed). This leaves no ambiguity about when to invoke it.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations by stating 'The rate is live — it will be locked when the sell is actually initiated,' which helps set user expectations about rate volatility.

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-organized with purpose, usage guidance, args, returns, and examples. Every section earns its place, the key usage instruction is front-loaded, and the examples are illustrative without padding.

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?

Despite lacking an output schema, the description supplies a return shape with fields and types, which gives the agent a clear picture of what to expect. It also covers the operational context (call before selling), all parameters, and example invocations, making it complete for a read-only quote tool.

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 description coverage is 100%, so the schema already documents token, network, amount, and fiat. The description adds value by restating parameters in plain language and including two concrete natural-language examples that map user phrases to parameter values, which helps an agent extract arguments correctly.

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 opens with a specific verb and resource: 'Gets the current exchange rate and expected NGN payout for selling a specific amount of crypto.' This clearly identifies the tool as a quote-fetching operation and distinguishes it from the related monei_sell_crypto_for_naira, which actually executes the sale.

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 explicitly states when to use the tool: 'Call this before monei_sell_crypto_for_naira to show the user the rate and how much NGN they will receive.' It gives clear contextual instruction, though it does not explicitly enumerate when-not-to-use scenarios or alternative quote-related tools.

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

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

Annotations already declare this as read-only, idempotent, non-destructive, and open-world. The description adds useful behavior context by clarifying that it returns the full portfolio structure, not just a balance, and that the agent should inspect specific fields like tokens[].symbol or nativeBalance for different user intents.

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 and front-loaded: purpose first, usage guidance second, then args, return shape, and examples. Every section adds decision-relevant value, and the examples map natural-language questions to the correct response fields.

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?

There is no output schema, so the description compensates by providing a detailed JSON response shape covering address, native balance, token entries, and total value. Combined with the sibling distinction and clear parameter documentation, nothing essential is missing for an agent to invoke this tool correctly.

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 fully documents the single optional network parameter, including the enum values and default. The description repeats this information but adds no deeper semantics beyond what the schema already provides, so 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 and resource: returns the full Solana token portfolio including SOL and SPL tokens with USD values. It also distinguishes itself from monei_get_wallet by stating its broader scope, so an agent can clearly tell which tool fits the request.

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?

It explicitly says to use this tool when the user wants a breakdown of their Solana holdings and points to monei_get_wallet for a simple balance check. This direct when-to-use and when-not-to-use guidance is exactly what agents need to disambiguate between siblings.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the 'all networks' scope and the exact return fields, which is useful but not a major relational disclosure beyond the annotations. No contradiction exists.

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: a one-sentence purpose, a compact 'Use this when' list, an explicit return shape, and concrete example prompts. Every section earns its place, and the core purpose is front-loaded.

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?

For a zero-parameter read-only lookup tool with no output schema, the description is complete: it defines the purpose, usage triggers, return structure, and field meanings. Combined with the rich annotations, nothing needed for correct invocation is missing.

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?

This tool has zero parameters, so the schema already fully defines the input. Per the rubric, a zero-param tool gets a baseline of 4; the description appropriately notes when to call it without needing to explain any parameter semantics.

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 states a specific verb and resource: 'Returns all EVM blockchain networks supported by Monei, including chain IDs, native tokens, and block explorer URLs.' This clearly distinguishes the tool from siblings like monei_get_banks or monei_get_wallet, which serve different data resources.

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 explicit 'Use this when' scenarios, including looking up chain IDs and helping users choose a network. It does not explicitly mention alternatives or exclusions, but no sibling tool overlaps with this network-listing capability, so the context is clear enough.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds useful behavioral context beyond those annotations: it returns full details in a specified shape, supports current status lookup, and includes an error-handling note for nonexistent references.

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 and front-loaded: purpose first, then usage guidance, then parameters, return shape, examples, and error handling. Each section earns its place and there is no redundant filler.

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?

For a simple one-parameter read-only tool, the description is complete: it explains when to use it, what it returns, includes the return fields, gives examples, and notes error behavior. The annotations cover safety, and the schema covers the parameter definition.

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%, so the schema already documents the reference parameter. The description adds value beyond the schema by providing concrete example values like 'TXN_abc123xyz' and natural-language example queries that map to the required reference argument.

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 a specific verb and resource: 'Returns the full details of a single transaction by its reference string.' It also differentiates itself from monei_get_transaction_history by explicitly noting this tool is for a specific reference, not for browsing recent activity.

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?

Usage is explicitly tied to a concrete user scenario: when the user provides a specific transaction reference and wants status or details. The description also names the alternative tool for browsing recent activity, giving the agent a clear routing decision.

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

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

Annotations already convey read-only, idempotent, non-destructive behavior, so the description only needs to add operational context. It does by documenting the exact response envelope, the type/nature/status enums, and the fact that all transaction types are included. A minor gap is that 'recent' is not quantified and pagination is not mentioned, but this is not critical for a zero-parameter read tool.

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 organized into purpose, usage, return shape, and examples. Every section earns its place, and the return sample is especially valuable because there is no output schema.

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?

It compensates for the missing output schema with a detailed response example and gives enough usage context for a simple read-only call. It is not fully complete because it does not state whether a maximum history length or pagination exists, and the client-side filtering instruction is implicit rather than explicit.

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?

With zero parameters, the baseline is 4, and the schema already covers everything. The description loses a point because the example 'filter by type=OFFRAMP' implies a filtering parameter that does not exist; it should clarify that filtering is done client-side on the returned transactions.

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 opens with a specific action and resource: 'Returns the user's recent transaction history across all transaction types.' It is clear about scope, but it does not explicitly differentiate from the sibling monei_get_transaction, so an agent has to infer the singular-vs-list 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?

It gives concrete use cases ('review past activity, check if a payment went through, or audit recent sends...') and even example user intents. However, the examples say 'filter by type=OFFRAMP' and 'show narration fields,' which could be read as tool-call parameters even though the schema has zero parameters; the description never warns that filtering must happen on the returned list, and no alternative (e.g., monei_get_transaction) is mentioned.

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

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

Annotations already establish readOnly, idempotent, openWorld, and non-destructive behavior. The description adds meaningful context by declaring this the authoritative balance source and specifying the return shape. No contradiction with annotations exists.

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 front-loaded with the core purpose and uses clear sections for args, returns, and examples. It is somewhat longer than necessary because the Args section repeats schema information, but the examples provide real agent-routing value.

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?

With no output schema, the description fully compensates by providing the return object shape and field meanings. It also covers parameter behavior, common user intents, and how to extract balances/addresses, so an agent has enough to invoke and interpret the result correctly.

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 description coverage is 100%, so the baseline is 3. The description's chainId line mostly restates the schema's 'Optional EVM chain ID to scope the portfolio' rather than adding new semantic detail.

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 opens with a specific verb and resource: 'Returns the user's full wallet overview including NGN balance and all subwallets (EVM and Solana).' This clearly distinguishes the tool from siblings like monei_get_evm_portfolio and monei_get_solana_portfolio, which expose only a subset.

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 gives explicit when-to-use guidance: 'Call this at the start of any transaction flow to confirm the user has sufficient balance before attempting sends, swaps, or offramp.' It does not explicitly name alternatives or exclusions, but the 'single source of truth' framing makes the intended primary use clear.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutation behavior is known. The description adds valuable context beyond that: it says the operation moves money, requires sufficient balance, may require pre-validation, and returns statuses. It skips details like failure/rollback behavior, but the category routing and prerequisites are transparent enough.

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?

Long, but every section earns its placegiven the four category-specific argument shapes. It is well-organized: purpose, category routing, prerequisites, args per category, return shape, and examples. The heading/list structure makes it scannable despite its length.

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?

There is no output schema, so the inline return object is essential and present. It also covers prerequisites, optional behavior, category mapping, and natural-language examples. Nothing an agent needs to correctly select and invoke this tool seems missing.

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 is empty, so the description carries the entire parameter burden. It defines category-specific parameters with names, types, and meanings, plus optional scheduling/saveBeneficiary fields. This is exactly the information an agent needs to construct a valid call.

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 specific verbs and resources: pays utility bills, buys airtime, purchases data bundles, and subscribes to cable TV. It clearly differentiates these from sibling tools by framing this as the bill-payment entry point with category-based routing.

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?

It gives explicit pre-call steps: fetch biller codes, confirm NGN balance, and validate customer details for data and cable. It does not explicitly contrast with sibling money-transfer tools like monei_send_naira_to_bank, but the preconditions leave little doubt about when this tool should be used.

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

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.

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

Annotations already indicate destructive, non-read-only behavior; the description adds meaningful operational context: automatic native-vs-ERC20 routing, the requirement for a runtime PIN that must never be stored or logged, and the need for user confirmation before sending. It also discloses the return shape including txHash, which is important since no output schema is present.

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 organized with a clear main statement, a routing rule, numbered pre-call steps, labeled Args, a Returns block, and examples. It is detailed but every section contributes actionable information; nothing is redundant or filler.

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?

For a financial transfer tool with destructive behavior and no output schema, the description covers everything an agent needs: prerequisites, PIN handling, user confirmation, routing rules, parameter semantics, return values, examples, and security guidance. The sibling context is complex, but the description fully positions this EVM send operation.

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?

Input schema coverage is 100%, giving a strong baseline. The description adds value beyond the schema by explaining the reason for using a string amount ('to avoid floating point errors'), clarifying when to include or omit tokenAddress, and providing concrete chainId examples for ETH, BSC, and MATIC.

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 opens with a specific verb and resource: 'Sends cryptocurrency from the user's Monei EVM wallet to an external wallet address.' It further distinguishes the tool's scope by explaining it handles both native tokens and ERC-20s, and the EVM qualifier separates it from the Solana sibling tool.

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 gives clear operational guidance: check balance with monei_get_evm_portfolio, ask for the transaction PIN at runtime, and obtain explicit user confirmation before sending. It does not explicitly state when not to use this tool versus alternatives like send_crypto_solana or swap_tokens_evm, so it falls just short of a 5.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

Annotations signal that this is a non-read-only, destructive operation, and the description adds meaningful behavior beyond those flags: transfers are 'instant between Monei users,' it returns errors for unregistered receivers or insufficient balance, and it warns never to store or log the transaction PIN. This aligns with the annotations and gives an agent a complete safety picture.

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 purpose is front-loaded, and the rest is organized into scannable sections: Before calling, Args, Returns, Examples, Error handling, and Security. Each section is purposeful for a money-movement tool and avoids unnecessary fluff.

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?

Even though there is no output schema, the description supplies the exact return shape, common error cases, required preconditions, and security handling. For a 3-parameter money-transfer tool, nothing an agent needs to select and invoke it correctly is missing.

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 already covers all three parameters at 100%, so the baseline is 3. The description adds real value with natural-language examples that map user phrases like 'Send ₦5,000 to john@gmail.com' to the receiver parameter, and it emphasizes that the transactionPin must be asked for at runtime and passed directly without logging.

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 opens with a specific verb and resource: 'Sends NGN to another Monei user identified by their email address or phone number.' It clearly distinguishes this tool from bank transfers, crypto sends, and bill payments, so an agent can tell what it does without comparing schemas.

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 explicitly states when to use it: 'Use this when the recipient is identified by email or phone rather than a bank account number.' It also gives practical prerequisites, including confirming sufficient balance with monei_get_wallet and asking for the transaction PIN at runtime.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, and the description is consistent with those. It adds useful behavioral context by explaining that the swap uses the user's Monei wallet, that routing is automatic based on provided fields, that user confirmation is required, and that a transaction hash is returned. This goes beyond the annotation flags without contradicting them.

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 and front-loaded with the purpose and routing logic, followed by preconditions, Args, Returns, and Examples. The length is justified by the tool's complexity and lack of an output schema. However, the Args bullet list partly repeats information already in the input schema, and the chainId list in the description omits Scroll and Lisk, so it is not perfectly lean.

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?

For a 5-parameter mutating swap tool with no output schema, this description is complete: it specifies route rules, preconditions such as balance verification and user confirmation, slippage default, supported chains, return shape with txHash, and illustrative examples. An agent can determine how and when to call the tool without needing to guess.

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 description coverage is 100%, so the baseline is 3. The description adds meaningful route-level parameter semantics: which fields to include for native-to-ERC20, ERC20-to-ERC20, and ERC20-to-native swaps, plus worked examples mapping natural-language requests to concrete parameter values. This is genuinely helpful, even though some Args text merely restates schema descriptions.

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 opens with a precise statement of what the tool does: swap one token for another on an EVM network using the user's Monei wallet. The EVM specification in the name and title distinguishes it from the Solana swap sibling, and the three routing combinations clarify the operation beyond a simple tautology.

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 gives explicit pre-call guidance: check balance with monei_get_evm_portfolio, look up contract addresses from the portfolio, and get user confirmation before executing. It also explains exactly how to choose tokenIn/tokenOut fields based on the swap route. It does not explicitly say 'use monei_swap_tokens_solana for Solana', so it stops just short of fully naming alternatives.

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

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

Even with destructiveHint=true and readOnly=false annotations, the description adds meaningful behavioral context: routing is determined automatically by provided fields, a balance check and user confirmation are expected before execution, and the on-chain result is a signature plus explorer URL. This complements the annotations without contradicting them.

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 into routing rules, pre-call steps, argument explanations, return format, and examples. The critical routing logic is front-loaded and every section serves a distinct purpose. It is detailed without being rambling, and it fills the gap left by the absence of an output schema.

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?

For a 4-parameter mutation tool with no output schema, the description is complete. It covers preconditions, parameter combinations, common token addresses, return fields, and realistic examples. An agent has everything needed to invoke the tool correctly and explain the outcome to the user.

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 already 100%, so the baseline is 3. The description goes beyond the schema by adding a routing matrix, worked examples, and actual mint addresses for USDC and USDT. This helps an agent select parameter combinations correctly, though the schema itself already carries most of the parameter meaning.

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 first sentence states a specific verb ('Swaps'), resource ('one token for another'), and network ('on Solana'), using the user's Monei wallet. The 'Solana' qualifier clearly distinguishes it from the EVM swap sibling, and the accompanying examples reinforce the intent.

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 gives explicit pre-call guidance: check the Solana portfolio for sufficient balance, show the user what is being swapped, and get confirmation before executing. It also explains the three routing scenarios based on inputMint and outputMint presence. It does not explicitly name monei_swap_tokens_evm as the EVM alternative or state when not to use this tool, so it falls just short of a 5.

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

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

Beyond annotations, the description explains the possible status lifecycle, typical completion time, and polling cadence, and clarifies that 'completed' means NGN has been sent. It is fully consistent with the readOnly, idempotent, non-destructive annotations.

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 and front-loaded: purpose, usage timing, statuses, arguments, return shape, and examples. Each section adds value, especially the return object since there is no output schema.

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 a single required parameter and no output schema, the description supplies the return shape, all possible status values, timing context, polling advice, and grounded examples. An agent has everything needed to invoke and interpret the tool correctly.

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%, and the description repeats the same reference source already given in the schema. It reinforces that the reference comes from the sell call, but does not add new parameter-level meaning beyond the schema.

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 opens with a specific verb and resource: 'Checks the current status of an offramp transaction by its reference.' This clearly distinguishes it from deposit, wallet, and transfer tools, and ties it directly to monei_sell_crypto_for_naira.

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?

It explicitly says to use this after monei_sell_crypto_for_naira to monitor settlement, and gives polling guidance for waiting users. It does not name alternative status-check tools or state when not to use it, but the intended workflow context is clear.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds meaningful behavioral context on top: error outcomes for invalid account numbers or bank codes, and the recommended user-confirmation workflow. No contradiction with annotations found.

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?

Well-organized: a one-sentence summary, clear when-to-use rationale, structured args, return shape, examples, and error handling. Every section earns its place; the length is justified for a safety-relevant verification 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?

With no output schema, the description fully covers the return format using a JSON example. It also covers required parameters, real-world examples, and failure modes, making the tool safe and self-contained for an agent to invoke correctly.

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 already documents both parameters fully (100% coverage). The description adds practical value by restating that accountNumber is a 10-digit Nigerian account number, giving a concrete bankCode example ('058' for GTBank), and tying bankCode to monei_get_banks.

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?

States a specific verb ('Verifies'), a clear resource ('Nigerian bank account number'), and the key outcome (returns the account holder's name). This immediately distinguishes it from siblings like monei_get_banks (bank metadata) and monei_send_naira_to_bank (sending).

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?

Explicitly instructs to call this before sending naira to a bank account and explains why: surfacing the account name prevents sending to the wrong account. It also points to monei_get_banks as the source for valid bank codes, giving clear routing guidance.

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