Skip to main content
Glama

AbaPay

by io.github.investorphem
OverviewDiscussionsAdmin

Pay Bill Batch

pay_bill_batch
Destructive

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pinYesThe PIN set when the API key was created (6 digits for new keys). Required once for the whole batch.
chainNoDefault chain for recipients that don't set their own. Falls back to the chain approved when the API key was created.
tokenNoDefault token for recipients that don't set their own. Falls back to the token approved when the API key was created.
api_keyNoAbaPay MCP API key. NOT needed when the connector is authorized via OAuth — omit it entirely in that case.
recipientsYesAt least 2 recipients (a single recipient should just use pay_bill), at most 20 per call — split a larger batch across several calls.
customer_emailNoOptional — used for receipts if known, applies to the whole batch.
idempotency_keyNoOptional, 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • 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 once for the whole batch."New value: +"The PIN set when the API key was created (6 digits for new keys). Required once for the whole batch."
  2. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations cover the safety profile (destructiveHint=true, readOnlyHint=false), and the description still adds substantial non-obvious behavior: all-or-nothing capacity refusal, per-recipient reporting after capacity clears, one PIN authorizing the whole batch, immediate execution with no scheduling. It does not restate the annotation that retries are non-idempotent, leaving that to the schema's idempotency_key text, which is the only notable gap.

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 capability and scope, then behavior, then exclusions and the DATA prerequisite. It is dense and effective, though the parenthetical rationalizations (e.g. why partial payment is worse) and the doubled 'executes immediately, same as pay_bill' clause add length that could be trimmed without losing meaning.

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 destructive, open-world payment tool with no output schema, the description covers the essentials an agent needs: batch bounds are in the schema, capacity semantics, all-or-nothing failure mode, per-recipient response shape, PIN scope, and the immediate-execution constraint. Nothing material for correct invocation is missing.

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 beyond it: recipients are grouped by (chain, token) and each group's capacity is checked against its own subtotal, plus explicit DATA guidance to call list_plans and supply each recipient's own variation_code. It does not fully explain how batch-level chain/token defaults interact with per-recipient overrides beyond what the schema already says.

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?

Opens with a specific verb+resource+scope: 'Pay airtime or data to multiple recipients in ONE call'. It distinguishes itself from siblings by naming pay_bill (single recipient), schedule_bill (delayed/recurring), and list_plans (DATA prerequisite), so an agent can route correctly without opening any schema.

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 when-to-use (2+ recipients of AIRTIME/DATA in one authorized batch) and when-not: 'electricity, cable, education, and international are not batchable; call pay_bill for those', single recipient should use pay_bill, and delayed/recurring batches should use schedule_bill once per recipient. Alternatives are named with 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 toolsInspect
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.

Resources