Skip to main content
Glama

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
pinYes4-6 digit PIN set when the API key was created. 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.