Skip to main content
Glama

Taokeh MCP server

File debit-note draft

create_debit_note_draft

File a SELL-SIDE DEBIT NOTE draft into Taokeh — an ADDITIONAL CHARGE on an invoice this business already issued (an undercharge, a price revised upward after delivery, a surcharge that was missed). This does NOT post to the books: it creates a pending draft the user reviews and approves in Taokeh, and only then does it increase what the customer owes and the output SST. Shape the fields with intake_contract(doc_type:'sales_debit_note') first. THE ORIGINAL INVOICE IS REQUIRED: find it with search_documents and pass its id as originalDocId. There is no allowance or standalone shape here — unlike a credit note, a debit note with no invoice behind it is not a document; if there is nothing to correct upward, the right document is a NEW INVOICE (create_invoice_draft), so say that rather than filing this. CHARGE THE SHORTFALL, NOT THE NEW PRICE: unitAmount is the amount being ADDED per unit, and quantity defaults to 1 because an additional charge is usually one line of money. Every line must name a product that actually appears on that invoice; anything else is refused. MONEY ONLY, ALWAYS — a debit note moves no stock, touches no COGS, and has no restock option anywhere in Taokeh (there is no goodsReturned field on this tool and no checkbox on its review screen), so a one-tap approval is money-only by construction and not by fence — and posts only the figure the user saw: if the draft now works out to a different total (for example an SST change since you filed it), the one tap is refused and the user posts it from the full review page. If EXTRA GOODS were delivered, raise a new invoice instead. There is NO cap on the charge, so the approver is shown the original invoice's own total beside yours — keep the figure defensible. An invoice already REVERSED from a Shopee, TikTok or Shopify Returns page is refused when you file and again at approval (its reversing journal entry has cancelled the order in the books, so a debit note would charge an order that no longer exists). Set needsReview and add a SHORT reviewer note in notes (one or two sentences naming what to double-check) for any doubt. Filed it wrong? Use revise_draft (kind: 'sales_debit_note') rather than filing a second one. This is the SELL side; Taokeh's /debit-notes page is the separate BUY side (a purchase return against a supplier bill), which has no AI lane for CREATING one — a buy-side note already posted can only be corrected, with update_supplier_debit_note_draft. A sell-side debit note already posted has no correction lane at all: the owner voids it in Taokeh and a new one is filed. ⛔ LINE KEYS ARE STRICT (2026-09-09): a key this schema does not list is REFUSED BY NAME — with the key it probably meant — and NOTHING is filed. Unknown keys used to be dropped in silence, which let a line through with its price or its tax code missing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
linesYes
notesNoA SHORT reviewer note: one or two plain sentences, in the reviewer's language, naming what the human should double-check before approving — which invoice you matched it to, where the figure came from. Not lengthy reasoning.
dnDateYes
reasonNoWhy more is charged — 'price revised upward after delivery', 'surcharge missed'. It prints on the note.
customerNoOPTIONAL CROSS-CHECK: the customer you believe the invoice belongs to. The customer comes FROM the invoice; sending a name that does not match is refused, which is exactly what it is for.
referenceNoThe debit-note number already printed on paper, if any. Leave it out and Taokeh numbers it (DN…).
customerIdNoThe resolved customer id, as the same cross-check.
needsReviewNo
printedTotalNoThe total printed on the paper, if any. Cross-check only — the server computes the real total and flags a mismatch on the approval screen.
originalDocIdNoREQUIRED (this or originalDocNumber): the ORIGINAL invoice's id, from search_documents. The server verifies it exists, is an INVOICE and whose it is — it never guesses, and it will not file a debit note without one.
originalDocNumberNoThe printed invoice number, when you have no id. Refused if more than one document carries it — find the right one with search_documents.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / lines / items / properties / description / description
      Previous value: -"What the extra charge is for, as it should print."New value: +"What the extra charge is for, as it should print. Never copy a per-foot or per-piece line's printed note here (like \"(400' @ RM 1.60/feet)\"): it is refused. A money charge is quantity 1 at the amount with a plain description; more timber is a new invoice (create_invoice_draft)."
  2. Changed1 schema field changed
    • changedInput schema / properties / lines / items / properties / unitAmount / description
      Previous value: -"The ADDITIONAL ringgit per unit — the shortfall being charged, NOT the corrected full price. Filing the full price charges the whole line a second time."New value: +"The ADDITIONAL ringgit per unit — the shortfall being charged, NOT the corrected full price. Filing the full price charges the whole line a second time. 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."
  3. Changed1 schema field changed
    • addedInput schema / properties / lines / items / additionalProperties
      Added value: +false
  4. Added

TDQS

A4.5/5.0
Behavior4/5

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

Annotations only cover the safety profile (non-readonly, non-destructive, non-idempotent), and the description goes well beyond them: it discloses that nothing posts to the books until a human approves, that one-tap approval is refused if the computed total drifted, that reversed orders from Shopee/TikTok/Shopify pages are refused at file and approval, and that strict line-key validation now rejects unknown keys by name. Missing are rate limits or auth/permission specifics, but the behavioral picture is unusually rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and the invoice requirement are front-loaded, which is good, but the text is long, heavily used with caps, em-dash asides and an emoji warning, and several rules (money-only, no restock, charge-the-shortfall) are restated in more than one place. Every rule is real, yet the same information could be delivered in materially fewer sentences.

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 nested-line, 11-parameter mutation tool with no output schema, the description covers everything an agent needs: prerequisites (intake_contract, search_documents), the approval/return semantics of the pending draft, failure modes (reversed invoice, unknown line keys, mismatched customer, total drift), and correction paths. Nothing material is left to inference.

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 73%, so the schema already carries most per-field meaning, but the description adds non-obvious semantics: originalDocId is effectively required (verified to exist, be an invoice, and belong to the right party), unitAmount is the ADDITIONAL per-unit shortfall rather than the corrected price, quantity defaults to 1, and productRef must resolve to a product already on that invoice. It stops short of documenting dnDate's format or the customer/customerId refusal interaction in any detail.

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 ('File a SELL-SIDE DEBIT NOTE draft'), defines what the document economically is (an additional charge on an already-issued invoice, not a stock or goods event), and explicitly distinguishes it from siblings: credit note, new invoice, and the buy-side /debit-notes flow. An agent can route correctly without opening the schema.

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?

Gives explicit when-to-use and when-NOT-to-use with named alternatives: shape with intake_contract first, find the invoice with search_documents, use create_invoice_draft when there is nothing to correct upward, revise_draft on a misfile, update_supplier_debit_note_draft for an already-posted buy-side note. Exclusions are stated, not implied.

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