Skip to main content
Glama

Taokeh MCP server

Customer statement

customer_statement
Read-only

One customer's statement of account — the same rows, running balance and closing figure as the Statement PDF on the customer's page. Give customerId (from resolve_customer) or customer (a name, resolved like open_invoices: an ambiguous name returns candidates — ask which one). Optional from / to (YYYY-MM-DD). Each line in lines is what the PDF prints, in its order: document (an invoice, credit note or debit note — charge is what it put on the customer's account, which can be LOWER than the invoice total, e.g. a marketplace order's net payout, and is negative on a credit note), payment (money applied to the document above it, on or before to), and on_account (a payment received but not yet applied — in payment — or a refund paid out and not applied — in charge). balance is the running balance after each line and closingBalance the TOTAL OUTSTANDING the PDF prints. With no from, the statement covers the whole history and its closing equals the customer's A/R aging total as of to (except where a bank line was matched to invoices for more than it booked to A/R — an internal fix on that bank line, never printed for the customer). With from, it lists only documents and on-account payments dated from then, with NO balance brought forward, so its closing is the period's own figure — say so. With no to, the statement runs to the later of today and the customer's latest document or payment; period states the dates used. Lines are capped at 300; when more is true the closing and totals are still exact — give a later from to see the rest.

Input Schema

NameRequiredDescriptionDefault
toNo
fromNo
customerNoA customer name, resolved against this company's customers.
customerIdNoThe customer id from resolve_customer. Give this OR `customer`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already cover safety (readOnlyHint=true, openWorldHint=false), yet the description still adds substantial behavior: the 300-line cap with `more` true still yields exact closing/totals, no-`from` vs with-`from` produce a balance-brought-forward figure vs a period-only figure, and no-`to` defaults to later of today or latest activity. It even discloses the one known discrepancy case (bank line matched to invoices for more than booked to A/R) and that it is never printed for the customer.

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?

Purpose is front-loaded in the first clause and no sentence is pure filler, but the middle is heavily nested with parentheticals (the marketplace net-payout aside, the internal-fix caveat) that make it slow to parse. One or two of the corrections could be a short structured list rather than comma-stacked prose.

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 read-only, 4-parameter, no-output-schema tool this is fully sufficient: the description documents the returned fields (`lines`, `document`, `payment`, `on_account`, `balance`, `closingBalance`, `period`, `more`), their ordering, the sign convention for credit notes, and pagination behavior — so the agent can consume the result without an output schema.

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

Parameters5/5

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

Schema coverage is only 50% (from/to have pattern but no description), and the description fully compensates: `from`/`to` are YYYY-MM-DD with explicit inclusion rules and the open-ended defaults, (`customerId` vs `customer`) are given as an either/or with a resolution path for the name variant. A reader does not need the schema to understand the parameters.

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?

Opening clause gives a specific verb+resource with a crisp equivalence: 'One customer's statement of account — the same rows, running balance and closing figure as the Statement PDF on the customer's page.' This distinguishes it from ar_aging (aggregate aging) and open_invoices (outstanding docs only) without opening either schema.

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 names the required precondition (give `customerId` from resolve_customer, or a name resolved like open_invoices) and tells the agent what to do on ambiguity ('ask which one'). It also spells out the conditional behaviors of `from` and `to`. What's missing is explicit routing versus siblings — nothing says when to prefer ar_aging or open_invoices over this statement.

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