Skip to main content
Glama

Pay bills in a batch

purchasing_pay_bills

Pay several bills at once from one bank account, like Xero's batch payments: bills (each with an optional amount, else its balance), or every unpaid bill due on or before due_before (one supplier's with supplier). One payment per bill on date, posted to the books from bank_account (default: where bank transfers land). sepa_file: true adds the SEPA credit transfer file (pain.001) to upload to the bank, paying each supplier's IBAN with the bill's reference; the bank books the batch as one line, which books_bank_lines then suggests matching to all its payments at once. All of it is paid or none. Costs $0.01 per bill paid; nothing if none are found.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "purchasing_pay_bills"
  }
}

Input Schema

NameRequiredDescriptionDefault
dateNoThe day it is paid. Default today.
billsNo
from_bicNo
supplierNoA supplier_id, or the supplier's name.
from_ibanNoThe IBAN it is paid from, when not the bank account's own.
sepa_fileNo
due_beforeNoEvery unpaid bill due on or before this day, instead of bills.
bank_accountNoThe books' bank account it is paid from, by code.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the annotations, the description discloses critical behavior: the operation is atomic ('All of it is paid or none'), has a per-bill cost, can generate a SEPA pain.001 file, and creates payments that books_bank_lines can later match to the bank batch. These are material operational details an agent needs before invoking a financial mutation.

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 front-loaded with the core action and packs in relevant operational context without obvious filler. However, it is a single dense paragraph with a long tangential clause about bank-line matching, which makes it less scannable than ideal.

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

Completeness4/5

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

For a complex financial mutation with eight parameters and no output schema, the description covers the main behavioral concerns: batch selection, atomicity, cost, SEPA file creation, and downstream bank-line matching. It still omits what the tool returns and whether any permissions or prerequisites are required, leaving some contextual gaps.

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?

The description adds useful semantics for key parameters: bills may include an optional amount defaulting to the remaining balance, due_before selects all unpaid bills due by that date, supplier narrows to one supplier, bank_account defaults to where bank transfers land, and sepa_file triggers SEPA file generation. It does not mention from_bic or from_iban, leaving some schema-covered parameters unaddressed.

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?

The description states a specific verb and resource: 'Pay several bills at once from one bank account.' It distinguishes this batch operation from single-bill payment by emphasizing 'several bills at once' and explains the two selection modes: explicit bills or due_before filtering.

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

Usage Guidelines4/5

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

It clearly explains when to use this batch tool: to pay multiple bills, either by passing specific bills or by paying all unpaid bills due on or before due_before, optionally narrowed to one supplier. It does not explicitly name purchasing_pay_bill as the alternative for single-bill payments, so it falls short of a full 5.

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.

Resources