Skip to main content
Glama

Taokeh MCP server

A/P aging

ap_aging
Read-only

Whom you owe money and how overdue it is — your accounts-payable aging by supplier, aged from each bill's DUE date (its own date when it states no term). WHAT A ROW IS: the PAYABLE each document created on the accounts-payable control account, less what has been paid against it by asOf — never the bill's gross total. UNMATCHED PAYMENTS: a bank payment posted to a supplier but not yet matched to a bill is already inside that supplier's bucket figures and total as a NEGATIVE amount, aged from the date it left, and listed under the row's unmatchedPayments with a kind: payment (negative), refund (a supplier refund not yet matched — positive), or booked_outside (the bank line was matched to bills for more than it booked to accounts payable — positive; the fix is on the bank line). A payment that IS matched, but to a bill dated after asOf — an advance paid to the supplier before the bill — is listed here too, kind payment, with paysLater ([{reference, date, amount}]) naming the bill(s) and the date it pays them: it sits on the supplier's account until that date and applies then, so do not suggest matching it. unmatchedPaymentsTotal is their sum, less the paysLater part (that part is paysLaterTotal), and documentTotals the buckets of the bills alone — quote documentTotals for what is OVERDUE. So a row's total is what you owe NET and can be negative. With them, this report equals the control-account balance to the cent, except for a manual journal posted straight to the control account, the period-end unrealized FX revaluation on its own date, and a bank line whose allocations were saved but which is not posted yet. Look for manual entries on the control account before doubting either figure. A cash bill, or a bill settled from somewhere other than the supplier account (an owner-paid bill booked to a shareholder loan), created no payable and is absent however its payment method reads; a debit note nets its supplier down. A figure here can therefore be lower than the same bill's total in search_documents — say which you are quoting.

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": "ap_aging"
  }
}

Input Schema

NameRequiredDescriptionDefault
asOfNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Goes far beyond the readOnlyHint annotation by disclosing what a row actually represents (net payable, not gross bill total), that totals can be negative, that unmatched payments/refunds/booked_outside appear as signed amounts, and the precise reconciliation exceptions (manual journals to control account, FX revaluation, unposted saved allocations). It also discloses which documents are absent entirely (cash bills, owner-paid bills) and why figures can differ from search_documents. Consistent with readOnlyHint=true.

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 a plain-language summary, then a WHAT A ROW IS anchor, then progressively finer caveats. Every block carries real information (no filler), but the mid-section is dense and would benefit from more sentence breaks given the volume of sign conventions and exception clauses packed together.

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 carries the full burden and does so: it effectively documents the response shape (total, documentTotals, unmatchedPayments with kind, unmatchedPaymentsTotal, paysLater/paysLaterTotal) inline. An agent can interpret results correctly without any return-value schema.

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

Parameters3/5

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

Only one parameter, asOf, with 0% schema description coverage — the schema gives the regex pattern but no meaning, optionality or default. The description uses asOf in context ('paid against it by asOf') but never defines it as the cutoff date or states what happens when omitted. Partial compensation only.

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 concrete verb+resource framing: 'Whom you owe money and how overdue it is — your accounts-payable aging by supplier', aged from the bill's due date. It is immediately distinguishable from the sibling ar_aging (receivables) and from search_documents, which it names explicitly later.

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?

Gives concrete decision guidance: 'quote documentTotals for what is OVERDUE', 'do not suggest matching' a paysLater payment, and 'Look for manual entries on the control account before doubting either figure'. It also tells the agent to state which figure it is quoting versus search_documents. It stops short of an explicit 'use this tool when X instead of Y' statement, so it is strong context rather than full routing.

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