AbaPay

Schedule Bill

schedule_bill

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.

Input Schema

TableJSON Schema

Name	Required	Description
`pin`	Yes	The PIN set when the API key was created (6 digits for new keys). 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.
`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.
`schedule_in_minutes`	No	Required when frequency is "once" — minutes from now to run it a single time.

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 to create a schedule, same as pay_bill."New value: +"The PIN set when the API key was created (6 digits for new keys). Required to create a schedule, same as pay_bill."

First observedSep 11, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Adds substantial context beyond the annotations: PIN is ALWAYS required because this creates a standing spend, nothing is charged at execution time, money only moves when the schedule fires and only with a funded on-chain allowance, and the schedule becomes auto-pay vs. notify-only based on the current agent limit. It also notes the response discloses which mode applies.

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

Conciseness4/5

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

The description is dense and long, but nearly every sentence carries actionable information and the critical constraint (nothing charged at run time) is front-loaded in the middle. A few clauses (e.g. the Telegram/WhatsApp/X parity remark) are decorative rather than load-bearing.

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 mutation tool with no output schema, the description covers prerequisites (PIN, list_plans, allowance funding), the two possible schedule modes, and what the response discloses, leaving no critical gap for correct invocation.

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 baseline is 3, but the description adds real semantic value on top: it explains the PIN requirement's rationale, the list_plans dependency for variation_code, and that the auto-pay/notify-only outcome is reported in the response. It does not add syntax detail for the remaining parameters, keeping it at 4 rather than 5.

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 ('Set up a recurring or future one-off bill payment') and enumerates exactly which services are schedulable (airtime, data, electricity, cable vs. EDUCATION/INTERNATIONAL). Clearly differentiates from the sibling pay_bill by its recurring/future scope.

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?

Explicit routing instructions: call list_plans first for DATA, or CABLE when changing package, use pay_bill directly for EDUCATION/INTERNATIONAL, and use list_schedules/cancel_schedule to inspect or remove schedules. Names both alternatives and the conditions that select them.

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.

Schedule Bill

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources