Non-custodial stablecoin bill-pay rails on Celo & Base for AI agents, settled on-chain via MCP.
Scored across 10 tools
Each tool targets a clearly distinct operation: pay_bill, pay_bill_batch, and schedule_bill are separated by single vs. batch vs. recurring/future execution, while list_plans and list_international_options are separated by domestic vs. international service domain. Descriptions reinforce boundaries and explicitly state prerequisites, leaving no meaningful ambiguity.
Most names follow a consistent snake_case verb_noun pattern (e.g., cancel_schedule, check_balance, list_plans, pay_bill). The only deviation is transaction_history, which is a noun phrase rather than an action, but the overall convention remains predictable.
10 tools are well-scoped for a multi-service bill payment connector, covering discovery, payment, scheduling, cancellation, balance, and history without bloat. Each tool earns its place and there are no redundant entries.
The surface covers the main bill-payment lifecycle: pay, schedule, cancel schedules, list schedules, check balance, list purchasable options, and view transaction history. Minor gaps include no update/modify operation for existing schedules, and international/education payments are intentionally excluded from batch and scheduling, but these are documented limitations rather than dead ends.
Cancel one or more active schedules for the linked wallet. Call list_schedules first to get a real id. Pass id to cancel exactly one; pass provider to cancel every active schedule for that provider; omit both to cancel ALL active schedules for this wallet. No PIN required, matching chat.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | The exact schedule id from list_schedules. Cancels only that one schedule. | |
| api_key | No | AbaPay MCP API key. NOT needed when the connector is authorized via OAuth — omit it entirely in that case. | |
| provider | No | Cancel every active schedule for this provider, e.g. "mtn". Ignored if id is also given. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint, idempotentHint, and openWorldHint, so the risk profile is covered. The description adds genuinely useful non-annotation context: 'No PIN required, matching chat,' which clarifies the authentication expectation for this destructive call.
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?
Three sentences, fully front-loaded with the action and scope, then the prerequisite, then the parameter decision tree. No filler and every sentence carries operational 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?
For a destructive, no-required-param tool with no output schema, the description covers the prerequisite, auth note, and parameter precedence well. It could state what the caller receives on success (e.g., cancelled count or ids), but annotations otherwise carry the safety profile.
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 real semantics beyond the schema: the mutual-exclusion precedence ('provider ignored if id is also given') and the omit-both default that cancels ALL schedules, which the schema does not state.
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+resource ('Cancel ... schedules') and precisely scopes it (one, per-provider, or all) for the linked wallet, distinguishing it from sibling list_schedules and schedule_bill.
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 list_schedules first to obtain a real id, and gives clear selection rules for each parameter combination including the omit-both case. Alternatives and precedence are spelled out, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a linked wallet's stablecoin balances and remaining agent spending allowance. Works with no arguments once this connector is authorized via OAuth; otherwise pass the api_key created in the AbaPay app's Agent Hub (MCP).
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Defaults to the chain approved when the key was created. | |
| api_key | No | AbaPay MCP API key (starts with aba_mcp_). NOT needed when the connector is authorized via OAuth — omit it entirely in that case; only supply it if this server asked you to authenticate and OAuth is unavailable. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing the OAuth-vs-api_key authorization path and the consequence of omitting the key, which an agent cannot infer from the annotations alone.
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?
Two sentences: the first front-loads what is returned (balances, spending allowance), the second handles the auth precondition. Efficient, though the second sentence partially duplicates the api_key schema description, adding mild redundancy.
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-required-parameter read tool with no output schema, the description adequately conveys what comes back (stablecoin balances plus remaining allowance) and how to authenticate. Nothing essential to invoking it correctly is missing, though return shape specifics are absent.
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 both parameters are fully documented in the schema, including the chain default and the 'omit when OAuth' note. The description largely restates the api_key guidance already present in the schema, adding no new syntax or format detail — 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?
States a specific verb and resource: 'Check a linked wallet's stablecoin balances and remaining agent spending allowance.' An agent can tell this apart from pay_bill or schedule_bill, but it never distinguishes itself from transaction_history, the closest sibling, leaving a small ambiguity about balance-snapshot vs. history retrieval.
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 explains the two auth modes (OAuth connector vs. passing an api_key) and that no arguments are needed when authorized, which is genuine call-time guidance. However, it offers no when-to-use/when-not guidance relative to siblings like transaction_history, so usage selection is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List what AbaPay can pay (airtime, data, electricity, cable, etc.), any services currently paused, and example requests. Call this first if unsure what is supported.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds only that the listing includes currently paused services and example requests, which is mild additional context about dynamic output but nothing beyond what annotations provide regarding behavior.
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?
Two sentences, both earning their place: the first enumerates the returned content, the second gives the routing hint. The most actionable instruction ("call this first") is placed last as a clear call to action with no 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 zero-parameter discovery tool with no output schema, the description usefully previews the return content (categories, paused services, examples), which is what an agent needs to decide whether to call it. It could be slightly richer about the response shape, but it is adequate for the tool's simplicity.
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. There is nothing for the description to compensate for, and the schema correctly commits to an empty object with additionalProperties false.
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 ("List") and enumerates the resources returned: payment categories (airtime, data, electricity, cable), paused services, and example requests. This is concrete and distinct from the sibling list_* tools, which return plans or options rather than a capability overview, though it doesn't explicitly name those alternatives.
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?
"Call this first if unsure what is supported" gives a clear triggering condition for invocation. It stops short of naming when NOT to use it or which sibling to prefer once capabilities are known, but the guidance is explicit enough to route an uncertain agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse the REAL, live international top-up catalogue (170+ countries) one level at a time. Call with no country to see supported countries. Add country to see its product types. Add product_type_id to see operators. Add operator_id too to see real, currently purchasable plans with their exact codes, foreign-currency price, and NGN-equivalent cost. ALWAYS call this before pay_bill with service: INTERNATIONAL, and pass back the exact country/product_type_id/operator_id/variation_code shown — never guess any of them. Only plans marked fixed-price can be paid via pay_bill right now; flexible-amount plans must be completed in the AbaPay app.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | Country name or ISO code, e.g. "Ghana" or "GH". Omit to list all supported countries. | |
| operator_id | No | An operator_id returned for this country + product_type_id — the network to top up. Omit to list operators. | |
| product_type_id | No | A product_type_id returned for this country — e.g. which kind of top-up (airtime vs a data bundle). Omit to list the country's product types. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, open-world behavior, so the safety profile is covered. The description adds genuinely new behavioral context: the data is live and currently purchasable, the drill-down must be done stepwise, and only fixed-price plans are payable downstream. It does not discuss pagination or result-size limits, minor for a read-only listing 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?
Five short sentences, front-loaded with the resource, then the drill-down progression, then the critical routing and hard constraint. Every sentence carries a distinct instruction and none is 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?
No output schema exists, and the description compensates by naming what each level returns (countries, product types, operators, plans with exact codes, foreign-currency price, NGN-equivalent cost). Combined with the payment constraints, an agent has everything needed to call this 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 baseline is 3. The description adds value by explaining the sequential dependency between the parameters — each value is an output of the previous level and must be passed back verbatim rather than invented — which the per-field schema text does not convey as a whole.
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 and resource — browsing the live international top-up catalogue — and immediately clarifies scope (170+ countries, hierarchical drill-down). An agent can distinguish this from list_plans (domestic plans) without opening either schema, because the description explicitly frames it as the international catalogue feeding pay_bill with service: INTERNATIONAL.
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?
Gives an explicit prerequisite ('ALWAYS call this before pay_bill with service: INTERNATIONAL'), an explicit anti-pattern ('never guess' the identifiers), and the alternative path for unsupported cases (flexible-amount plans must be completed in the AbaPay app). This is about as complete as when-to-use guidance gets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the REAL, currently purchasable plans for a service that needs one — DATA bundles, CABLE packages, or EDUCATION products (WAEC/JAMB) — with their exact codes and current VTpass prices. ALWAYS call this before pay_bill for these three services and pass back one of the returned codes as variation_code. Never guess a plan, a code, or a price — if this returns nothing usable, say so rather than inventing one.
| Name | Required | Description | Default |
|---|---|---|---|
| service | Yes | Which service to list plans for. Electricity and airtime are free-amount and have no plan list. | |
| provider | Yes | e.g. mtn, airtel, glo, 9mobile (data); dstv, gotv, startimes (cable); waec, waec-registration, jamb (education) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower; the description still adds that prices are current/volatile and that an empty result must be reported rather than fabricated. It does not discuss pagination or failure modes, but for a read-only listing this is solid added context.
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?
Two compact sentences with the core listing purpose front-loaded, followed by the mandatory pre-pay_bill sequencing. Every clause carries actionable instruction and there is no 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?
There is no output schema, and the description fills that gap by saying what comes back (exact codes and current prices) and what to do when nothing usable returns. Enough for an agent to invoke and consume 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 coverage is 100%, so the baseline is 3; the description goes beyond it by tying the returned codes to the variation_code argument of pay_bill, which is not derivable from this schema alone. The service/provider formats are already documented in the schema, so the added semantics come mainly from that cross-tool linkage.
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 (list) and resource (plans) scoped to three named services, and clarifies it returns exact codes and current prices. It is clearly distinguishable from siblings like list_international_options, list_schedules, and pay_bill, which share the 'list/pay' vocabulary.
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 says to ALWAYS call this before pay_bill for DATA/CABLE/EDUCATION and to pass one of the returned codes as variation_code, plus notes that electricity and airtime have no plan list. This gives both the when-to-use trigger and the downstream call pattern.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List active recurring/one-off bill schedules for the linked wallet — same data as the AbaPay app and Telegram/WhatsApp "show my schedules". Read-only, no PIN required. Returns each schedule's id — pass that to cancel_schedule to remove one.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | AbaPay MCP API key. NOT needed when the connector is authorized via OAuth — omit it entirely in that case. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, but the description adds genuinely new context: no PIN required and parity with the AbaPay app and Telegram/WhatsApp 'show my schedules' output. That reconciles the tool with surfaces the user already knows.
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?
Three tight clauses, front-loaded with what is listed, then the safety/permission profile, then the actionable id handoff. Nothing is redundant and no sentence could be cut without losing routing or behavioral 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 partially carries the return burden by disclosing that each schedule comes with an id usable by cancel_schedule. It doesn't enumerate the remaining returned fields (amount, date, frequency), so there is a minor gap for a list 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% and the single api_key parameter is fully documented in the schema, including the OAuth omission case, so the description needn't repeat it. Baseline 3 applies since the description adds no parameter-level detail beyond what structured data provides.
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?
Specific verb + resource + scope: 'List active recurring/one-off bill schedules for the linked wallet.' It also distinguishes itself from sibling cancel_schedule by stating the id handoff relationship, so an agent can place it in the workflow without opening another 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?
Names the downstream alternative (cancel_schedule) and the condition that links them — pass the returned id to remove a schedule — which effectively tells the agent when to use this tool. It lacks an explicit when-not-to-use, but the discovery-then-cancel flow is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pay a real bill — Nigerian (airtime, data, electricity, cable TV, a WAEC/JAMB education PIN) or international airtime/data across 170+ countries — from the linked wallet, settled on-chain and delivered via the same pipeline as the AbaPay app. For DATA, CABLE (when changing package), and EDUCATION, call list_plans first and use a real variation_code from it. For service: INTERNATIONAL, call list_international_options first and pass back its exact country/product_type_id/operator_id/variation_code — never guess any of these. ALWAYS requires the PIN — including when this connector is authorized via OAuth; ask the human for it every time and never guess or reuse a remembered one. The api_key is only needed when OAuth is not in use. Money moves for real — only call this once the human has clearly confirmed the exact amount, provider, and account. EXECUTES IMMEDIATELY, with no delay/schedule parameter of any kind — there is no way to queue this call for later on this connection. If the human asks to pay "in N minutes", "later today", "tomorrow", or any other future time, do NOT call this now: ask them to confirm they want it sent immediately instead, or tell them delayed/recurring automations can only be set up from the AbaPay app or by messaging the AbaPay agent on Telegram/WhatsApp/X — never silently pay right away when a delay was requested.
| Name | Required | Description | Default |
|---|---|---|---|
| pin | Yes | 4-6 digit PIN set when the API key was created. Required on EVERY payment, including over an OAuth connection — ask the human for it each time. | |
| chain | No | Defaults to the chain approved when the API key was created. Only override this if the default chain lacks balance/allowance and check_balance shows funds on the other one. | |
| token | No | Which stablecoin to pay with. Defaults to the token approved when the API key was created. If that one is short on balance or on-chain allowance, call check_balance first to see what else is available on this chain, then retry with this field set — e.g. if USD₮ is short but the wallet holds USDC with its own approved limit, pass token: "USDC". | |
| api_key | No | AbaPay MCP API key. NOT needed when the connector is authorized via OAuth — omit it entirely in that case. | |
| country | No | Required for service: INTERNATIONAL — country name or ISO code, from list_international_options. | |
| service | Yes | Which kind of bill | |
| provider | No | e.g. mtn, airtel, glo, ikeja-electric, dstv, gotv, startimes, waec, waec-registration, jamb. Not used for service: INTERNATIONAL — use country/product_type_id/operator_id instead. | |
| amount_ngn | No | Amount in Naira. Not needed for service: INTERNATIONAL — the NGN-equivalent is derived from the live plan you picked via list_international_options. | |
| meter_type | No | Required for ELECTRICITY | |
| operator_id | No | Required for service: INTERNATIONAL — from list_international_options. | |
| customer_name | No | Optional — used for the receipt if known | |
| account_number | Yes | Phone number (airtime/data), meter number (electricity), smartcard/IUC number (cable), JAMB profile ID (education: jamb), the buyer's phone number (education: waec), or the destination phone number abroad (international) | |
| customer_email | No | Required for service: INTERNATIONAL (the receipt goes here). Optional otherwise. | |
| variation_code | No | Plan/bundle/product code — required for DATA, EDUCATION, and INTERNATIONAL, and for CABLE when changing package (not needed to renew the current one) | |
| product_type_id | No | Required for service: INTERNATIONAL — from list_international_options. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructive/openWorld/non-idempotent, and the description goes further: it discloses that money moves irreversibly and immediately, that PIN is always required even under OAuth, that api_key is only needed without OAuth, and that no queue/schedule parameter exists. That is material context beyond 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?
Front-loaded with the core action and the anti-scheduling warning, and every paragraph carries safety-relevant content. It is long and repeats the PIN requirement and the 'never guess' instruction, but for a destructive, irreversible payment tool the redundancy is defensible rather than wasteful.
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?
Covers the full decision surface for a 15-parameter destructive tool: per-service required fields, prerequisite lookups, auth modes, confirmation requirement, and the scheduling exception. No output schema exists, but the description does not need to explain return values for an agent to 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?
Schema coverage is 100%, so the baseline is 3. The description adds cross-parameter workflow constraints the schema cannot express on its own — which fields are mandatory per service and that country/product_type_id/operator_id/variation_code must be copied verbatim from list_international_options and never guessed. It is largely corroborative of schema text, so it lands above baseline but not at 5.
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 concrete verb+resource and enumerates the bill categories covered (airtime, data, electricity, cable, education, international), plus the settlement path (linked wallet, on-chain). It is clearly distinguishable from siblings like schedule_bill and pay_bill_batch, especially given the explicit 'EXECUTES IMMEDIATELY, no scheduling' clause.
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?
Explicit routing to alternatives and prerequisites: call list_plans first for DATA/CABLE/EDUCATION, list_international_options for INTERNATIONAL, and it names the delay path (AbaPay app / Telegram/WhatsApp/X) as the alternative to this call. It also states the human-confirmation precondition before invoking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pay airtime or data to multiple recipients in ONE call — the same multi-recipient batch Telegram/WhatsApp/X support ("send 500 to X and 1000 to Y"). One PIN authorizes the whole batch. Recipients are grouped by (chain, token); each group's capacity (balance + approved agent limit) is checked against that group's own subtotal — but if ANY group is short, the ENTIRE batch is refused before anything moves (all-or-nothing on capacity; paying 6 of 8 recipients because the 7th was under-funded is worse than one clear error up front). Once capacity clears, recipients are paid one at a time and the response reports each individually, since a single vend failure partway through must not be reported as if the whole batch failed. AIRTIME and DATA only — electricity, cable, education, and international are not batchable; call pay_bill for those, one at a time. For DATA, call list_plans first and give each recipient needing one its own real variation_code. EXECUTES IMMEDIATELY: no delay/schedule option, same as pay_bill — for a delayed/recurring batch, call schedule_bill once per recipient instead.
| Name | Required | Description | Default |
|---|---|---|---|
| pin | Yes | 4-6 digit PIN set when the API key was created. Required once for the whole batch. | |
| chain | No | Default chain for recipients that don't set their own. Falls back to the chain approved when the API key was created. | |
| token | No | Default token for recipients that don't set their own. Falls back to the token approved when the API key was created. | |
| api_key | No | AbaPay MCP API key. NOT needed when the connector is authorized via OAuth — omit it entirely in that case. | |
| recipients | Yes | At least 2 recipients (a single recipient should just use pay_bill), at most 20 per call — split a larger batch across several calls. | |
| customer_email | No | Optional — used for receipts if known, applies to the whole batch. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial behavior beyond annotations: one PIN authorizes the whole batch, capacity is checked all-or-nothing per group before anything moves, payments execute sequentially with per-recipient reporting, and execution is immediate. Annotations already declare destructive/non-idempotent, so the description usefully explains the semantics behind those flags rather than repeating 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?
Front-loads the core action and the one-call scope, then layers constraints efficiently. It is dense and long with several parenthetical asides, but nearly every clause carries operational information rather than 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?
With no output schema, the description compensates by explaining that the response reports each recipient individually and why partial failures must surface per-recipient. Combined with the capacity-check and exclusivity rules, an agent has everything needed to 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?
Schema coverage is 100%, so baseline is 3, but the description adds real meaning: the PIN's batch-wide scope, the group-by-(chain, token) subtotal logic, and that DATA recipients each need their own real variation_code. It doesn't restate enum values, which the schema handles.
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 and resource ('Pay airtime or data to multiple recipients in ONE call') and immediately distinguishes itself from pay_bill and schedule_bill. The grouping model by (chain, token) further clarifies the operation's shape.
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 routes the agent: AIRTIME/DATA only, call pay_bill for electricity/cable/education/international, call list_plans before DATA recipients, call schedule_bill for delayed/recurring. The schema also notes a single recipient should use pay_bill. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set up a recurring or future one-off bill payment — daily/weekly/monthly airtime, data, electricity, or cable — the same automation Telegram/WhatsApp/X support. Validates exactly like pay_bill (call list_plans first for DATA, or CABLE when changing package, to get a real variation_code) and ALWAYS requires the PIN, since this creates a standing spend. Nothing is charged when this tool runs — money only moves later, when the schedule actually fires, and only if the wallet still has a funded on-chain allowance at that time. If the approved agent limit already covers the amount right now, the schedule is created to auto-pay itself each time it is due; otherwise it is saved as notify-only and someone must call pay_bill manually when it comes due — the response says which. EDUCATION and INTERNATIONAL cannot be scheduled; pay those directly with pay_bill. Use list_schedules to see what is set up and cancel_schedule to remove one.
| Name | Required | Description | Default |
|---|---|---|---|
| pin | Yes | 4-6 digit PIN set when the API key was created. Required to create a schedule, same as pay_bill. | |
| chain | No | Defaults to the chain approved when the API key was created. | |
| token | No | Defaults to the token approved when the API key was created. | |
| api_key | No | AbaPay MCP API key. NOT needed when the connector is authorized via OAuth — omit it entirely in that case. | |
| service | Yes | Which kind of bill to schedule. EDUCATION and INTERNATIONAL are not schedulable — use pay_bill directly for those. | |
| provider | No | e.g. mtn, airtel, glo, 9mobile, ikeja-electric, dstv, gotv, startimes | |
| frequency | Yes | How often this runs. "once" fires exactly one time, schedule_in_minutes from now. | |
| amount_ngn | Yes | Amount in Naira to charge each time the schedule runs. | |
| meter_type | No | Required for ELECTRICITY | |
| day_of_week | No | Required when frequency is "weekly" — 0 (Sunday) through 6 (Saturday). | |
| day_of_month | No | Required when frequency is "monthly" — 1 through 28. | |
| account_number | Yes | Phone number (airtime/data), meter number (electricity), or smartcard/IUC number (cable) | |
| customer_email | No | Where to send a notification when this runs. MCP has no persistent channel to message back into a conversation — without this, you'll need to poll list_schedules or transaction_history yourself to see what happened. | |
| variation_code | No | Plan/bundle/product code — required for DATA, and for CABLE when changing package (not needed to renew the current one). Get a real one from list_plans first. | |
| schedule_in_minutes | No | Required when frequency is "once" — minutes from now to run it a single time. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only establish that this is a non-read-only, non-idempotent, open-world write. The description adds far more: no charge occurs at creation time, funds move only when the schedule fires, payment depends on a funded on-chain allowance then, PIN is always required, and the outcome is either auto-pay or notify-only. This is exactly the mutation-side context annotations cannot 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 purpose is front-loaded in the first clause, followed by prerequisites, side-effect timing, and the fallback path, in that order. Despite its length every sentence carries distinct operational information; there is no 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 15-parameter write tool with no output schema, the description covers the workflow end to end: validation model, required credentials, when money actually moves, the two possible schedule modes, and even what the response reports. An agent has enough to call it correctly and interpret the result.
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 each field; the baseline is 3. The description nevertheless adds cross-parameter reasoning — the pay_bill validation model, the list_plans dependency for variation_code, the mandatory PIN — and explains that customer_email exists because the channel cannot push notifications back. Some of this restates the schema, but the interaction guidance is genuine added 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 opening sentence states a specific verb (set up) plus resource (recurring/future one-off bill payment) and enumerates the covered service types. It immediately distinguishes itself from the sibling pay_bill by scope — this creates a standing schedule rather than paying now.
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 prerequisites (call list_plans first for DATA/CABLE variation codes), explicit exclusions (EDUCATION and INTERNATIONAL cannot be scheduled — use pay_bill), and explicit sibling routing (list_schedules to view, cancel_schedule to remove). Nothing about when to choose this tool is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent real transactions for the linked wallet — same data as the AbaPay app's History tab (service, provider, amount, status, tx hash). Read-only, no PIN required. The interactive card's own Next/Previous buttons page through results by re-calling this tool with a different offset — pass offset yourself only when asked for something like "the next page" or "transactions before that" in plain text.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many recent transactions to return. Defaults to 10, max 25. | |
| offset | No | How many of the most recent transactions to skip before listing — 0 (default) starts at the newest. Used for paging: offset=10 with the default limit gets the next 10 after the first page. | |
| api_key | No | AbaPay MCP API key. NOT needed when the connector is authorized via OAuth — omit it entirely in that case. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so safety is covered. The description adds genuinely new context: no PIN is required, the payload matches the app's History tab, and that the UI card pages by re-invoking the same tool. It does not mention rate limits or freshness/latency of the data.
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?
Two sentences, purpose front-loaded in the first clause with the returned-field list as parenthetical support. The second sentence is long with several nested clauses, but each carries actionable paging guidance rather than 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?
With no output schema, the description compensates by enumerating the returned fields (service, provider, amount, status, tx hash); auth is covered by the api_key parameter description and safety by annotations. Paging, scope, and auth are all addressed, leaving nothing essential an agent needs before calling 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%, so the baseline is 3; the description earns an extra point by clarifying the decision boundary for offset (agent should not set it when the card handles paging) rather than merely restating the offset/limit mechanics the schema already documents. It adds no detail on api_key beyond the schema's OAuth note.
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 and resource ('List recent real transactions for the linked wallet') and pins the exact scope by equating it to the app's History tab and enumerating returned fields. 'Real transactions' implicitly separates it from the schedule-oriented siblings (list_schedules, cancel_schedule), so an agent can route without opening the 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?
Gives an explicit conditional for the one ambiguous case: let the interactive card's Next/Previous re-call the tool, and only pass offset manually when the user asks in plain text for 'the next page' or 'transactions before that'. No explicit when-not or sibling-by-name routing (e.g. schedules vs real transactions) is stated, keeping it 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
cancel_schedulecheck_balancedescribe_capabilitieslist_international_optionslist_planslist_schedulespay_billpay_bill_batchschedule_billtransaction_historyNon-custodial USDC yield vaults on Base mainnet with 9 MCP tools for AI agent treasury.
Complete financial infrastructure for AI agents — payments, lending, escrow & more.
Payment rails for AI agents. Pay merchants in USDC on Base. Dual-protocol: x402 + OKX APP.
MCP for AI agents: financing, skills, lending on Base
