Skip to main content
Glama

Taokeh MCP server

File a pending recurring-invoice draft (human approves in Taokeh)

create_recurring_invoice_draft

FILES A PENDING DRAFT ONLY — NOTHING IS CREATED UNTIL A HUMAN REVIEWS AND APPROVES IT IN TAOKEH. Propose a NEW recurring invoice — a billing schedule that issues the same invoice to the same customer every month, quarter or year (a retainer, a subscription, a maintenance contract, rent). This does NOT create anything: it files a pending DRAFT the owner reviews and approves; only that tap saves the schedule. Give the customer (customerId from resolve_customer, or customer as an EXACT existing customer name — this tool never creates a customer), the lines (each a real catalogue product by productId or exact sku, with the quantity and the agreed unit price that will be billed EVERY cycle), the cadence, and the startDate — whose day of the month becomes the billing anchor (a 31st anchor lands on the 28th/29th/30th in shorter months). Optionally endDate, maxOccurrences, title, notes and paymentMethod (CREDIT = the customer owes it and pays later, CASH = settled at issue; these book differently, so ask rather than guess). A CASH schedule's money is booked where the schedule's "Paid into" says: the owner picks it on the schedule's own page, never this tool, and a schedule proposed here starts on the default (the Cash account for a walk-in customer, otherwise the account the company books cash sales to, usually its main bank). ⛔ WHAT IT CANNOT DO: it cannot set issueMode: "auto" — a schedule you propose files an invoice DRAFT each cycle for a person to approve, and nothing proposed through this connector may buy itself the right to post invoices unattended; the owner switches that on themselves if they want it. It cannot set MFRS 15 revenue spreading (recognition), which is an accounting-policy decision on the schedule's own page. It cannot set the next issue date directly — that is derived from the start date and the cadence, and the review page tells the owner the exact date the FIRST invoice would be issued before they approve. BE HONEST: never guess a contracted price or a start date — leave the schedule unproposed and ask.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "lines": "<lines>",
      "cadence": "<cadence>",
      "startDate": "<startDate>"
    },
    "name": "create_recurring_invoice_draft"
  }
}

Input Schema

NameRequiredDescriptionDefault
linesYesWhat gets billed every cycle. Every line must be a real catalogue product. A line carrying Taokeh's printed per-foot or per-piece note (like "(400' @ RM 1.60/ft)") is refused: a schedule holds no size or tally, so it would bill without its rounding line every cycle. Raise those invoices with create_invoice_draft in their filed form. On an update, such a line already on the schedule may be sent back unchanged. ⛔ LINE KEYS ARE STRICT: a key this schema does not list is REFUSED BY NAME and NOTHING is filed.
notesNoA SHORT reviewer note, in the reviewer's language: what this schedule bills and what they should double-check.
titleNoA short label for the schedule, e.g. 'Monthly retainer — Acme'. Optional; it never prints on the invoice.
cadenceYes
endDateNoStop issuing after this date. Optional.
customerNoAn EXACT existing customer name. A name that matches nobody is refused — this tool never creates a customer.
startDateYesThe first billing date. Its DAY OF THE MONTH becomes the anchor for every later cycle. A date in the past does not backfill — the first invoice lands on the first cycle on or after today.
customerIdNoThe customer id from resolve_customer. Give this OR `customer`.
needsReviewNoSet true when something gave you pause — a price the user was unsure about, a start date you inferred.
paymentMethodNoCREDIT (default) = the customer owes it. CASH = settled at issue. Ask the user; these book differently.
maxOccurrencesNoStop after this many invoices. Optional.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / lines / description
      Previous value: -"What gets billed every cycle. Every line must be a real catalogue product. A line carrying Taokeh's printed per-foot or per-piece note (like \"(400' @ RM 1.60/feet)\") is refused: a schedule holds no size or tally, so it would bill without its rounding line every cycle. Raise those invoices with create_invoice_draft in their filed form. On an update, such a line already on the schedule may be sent back unchanged. ⛔ LINE KEYS ARE STRICT: a key this schema does not list is REFUSED BY NAME and NOTHING is filed."New value: +"What gets billed every cycle. Every line must be a real catalogue product. A line carrying Taokeh's printed per-foot or per-piece note (like \"(400' @ RM 1.60/ft)\") is refused: a schedule holds no size or tally, so it would bill without its rounding line every cycle. Raise those invoices with create_invoice_draft in their filed form. On an update, such a line already on the schedule may be sent back unchanged. ⛔ LINE KEYS ARE STRICT: a key this schema does not list is REFUSED BY NAME and NOTHING is filed."
  2. Changed1 schema field changed
    • changedInput schema / properties / lines / description
      Previous value: -"What gets billed every cycle. Every line must be a real catalogue product. ⛔ LINE KEYS ARE STRICT: a key this schema does not list is REFUSED BY NAME and NOTHING is filed."New value: +"What gets billed every cycle. Every line must be a real catalogue product. A line carrying Taokeh's printed per-foot or per-piece note (like \"(400' @ RM 1.60/feet)\") is refused: a schedule holds no size or tally, so it would bill without its rounding line every cycle. Raise those invoices with create_invoice_draft in their filed form. On an update, such a line already on the schedule may be sent back unchanged. ⛔ LINE KEYS ARE STRICT: a key this schema does not list is REFUSED BY NAME and NOTHING is filed."
  3. Changed1 schema field changed
    • changedInput schema / properties / lines / items / properties / unitPrice / description
      Previous value: -"The agreed price per unit, in ringgit, billed every cycle. This replays exactly as stored — it does not follow the product’s list price."New value: +"The agreed price per unit, in ringgit, billed every cycle. This replays exactly as stored — it does not follow the product’s list price. Two decimals at most (whole sen, or whole cents in another currency); put a discount or tax in its own field, never folded into the price."
  4. Changed2 schema fields changed
    • changedInput schema / properties / lines / description
      Previous value: -"What gets billed every cycle. Every line must be a real catalogue product."New value: +"What gets billed every cycle. Every line must be a real catalogue product. ⛔ LINE KEYS ARE STRICT: a key this schema does not list is REFUSED BY NAME and NOTHING is filed."
    • addedInput schema / properties / lines / items / additionalProperties
      Added value: +false
  5. Added

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare non-readOnly, non-destructive, non-idempotent, so the description correctly spends its words on the human-approval gate ('nothing is created until a human reviews and approves') and on downstream effects annotations cannot express — CASH money booked to a default Cash account, no backfill for past start dates, anchor-day clamping in short months. It stops short of saying whether resubmitting identical input creates a duplicate schedule, which matters given idempotentHint=false.

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 critical constraint is front-loaded in the first clause, and each later sentence carries new information (customer resolution, line requirements, anchor behavior, payment booking, the three prohibitions). It loses a point for moderate redundancy and shouty formatting — 'FILES A PENDING DRAFT ONLY' is immediately restated as 'This does NOT create anything', and the ⛔/BE HONEST markers add noise without adding 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 an 11-parameter mutation with no output schema and real accounting consequences, the description covers the draft-filing lifecycle, the required pre-resolution steps, the strict line-key refusal, the prohibited settings, and the honesty rule on prices and dates. Nothing an agent needs to invoke this correctly or avoid the common failure modes 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 91%, so the baseline is 3; the description still earns above that by explaining derived semantics the schema omits — startDate's day-of-month becoming the billing anchor and rolling to the 28th/29th/30th, and that paymentMethod CASH vs CREDIT book differently so the agent should ask. Customer and line constraints (exact existing name, never creates a customer, never creates a product) are reinforced beyond the schema.

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 ('propose a NEW recurring invoice') plus a concrete definition of what a recurring invoice is (billing schedule issuing the same invoice on a cadence). It distinguishes itself from the per-invoice sibling by naming create_invoice_draft as the tool for lines with printed per-foot notes, and from update_recurring_invoice_draft by framing itself as proposing new schedules.

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 tells the agent to use resolve_customer and resolve_product first, to route per-foot/per-piece lines to create_invoice_draft instead, and to leave the schedule unproposed and ask when price or start date is unknown. The 'WHAT IT CANNOT DO' block names the exact fields (issueMode auto, recognition, next issue date) that must be set by the owner on the schedule page rather than here.

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