AbaPay

Pay Bill

pay_bill

Destructive

Pay a real bill — Nigerian (airtime, data, electricity, cable TV, a WAEC/JAMB education PIN) or international airtime/data across 140+ 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. 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.

Input Schema

TableJSON Schema

Name	Required	Description
`pin`	Yes	The PIN set when the API key was created (6 digits for new keys). 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)
`idempotency_key`	No	Optional, strongly recommended: a unique id you choose for THIS payment (8-128 chars, e.g. a UUID). Retrying with the same key returns the first result instead of paying again; reusing it with different arguments is refused (409). Without one, an identical call within 2 minutes is treated as a retry.
`product_type_id`	No	Required for service: INTERNATIONAL — from list_international_options.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 30, 2026

addedInput schema / properties / idempotency_key

Added value: +{
+  "description": "Optional, strongly recommended: a unique id you choose for THIS payment (8-128 chars, e.g. a UUID). Retrying with the same key returns the first result instead of paying again; reusing it with different arguments is refused (409). Without one, an identical call within 2 minutes is treated as a retry.",
+  "type": "string"
+}

changedInput schema / properties / pin / description

Previous value: -"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."New value: +"The PIN set when the API key was created (6 digits for new keys). Required on EVERY payment, including over an OAuth connection — ask the human for it each time."

First observedSep 11, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already mark destructive=true and openWorld=true, and the description adds critical context beyond them: money moves for real, requires human confirmation of amount/provider/account, PIN mandatory on every call even over OAuth, and no delay/schedule capability exists on this connection. It also explains the idempotency_key retry semantics (2-minute identical-call window), which the idempotentHint=false annotation does not convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

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

Front-loaded with the core purpose and the highest-risk constraints (list_plans prerequisites, PIN, no scheduling). It is dense and mostly earns its length, though the PIN-every-time warning is restated in the same paragraph and echoed again in the pin schema description — minor redundancy.

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

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 16-parameter, irreversible, open-world mutation with no output schema, the definition covers routing, prerequisites, safety gating, irreversibility, and the scheduling gap. An agent has everything needed to decide whether and how to call it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema carries the baseline; the description still adds cross-parameter dependency rules not spelled out per-field, notably that INTERNATIONAL uses country/product_type_id/operator_id instead of provider/amount_ngn, and that variation_code is needed for CABLE only when changing package.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (pay a real bill from the linked wallet) and enumerates the exact bill categories, including the Nigerian vs international split. It is clearly distinguished from sibling pay_bill_batch and schedule_bill by noting this is the single, immediate payment path.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent: call list_plans first for DATA/CABLE-package-change/EDUCATION, list_international_options for INTERNATIONAL, and never guess country/product_type_id/operator_id. It also states the when-not case for future-dated requests and names the alternatives (AbaPay app, Telegram/WhatsApp/X agent).

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

All AbaPay tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Pay Bill

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources