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.

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": {
      "dnDate": "<dnDate>",
      "lines": "<lines>"
    },
    "name": "create_debit_note_draft"
  }
}

Input 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.
dnDateYesThe debit-note date, YYYY-MM-DD in Malaysia time (MYT). Never before the date of the invoice it corrects: an earlier date is refused, naming the invoice's date.
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. 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)."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/ft)\"): 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
    • addedInput schema / properties / dnDate / description
      Added value: +"The debit-note date, YYYY-MM-DD in Malaysia time (MYT). Never before the date of the invoice it corrects: an earlier date is refused, naming the invoice's date."
  3. 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)."
  4. 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."
  5. Changed1 schema field changed
    • addedInput schema / properties / lines / items / additionalProperties
      Added value: +false
  6. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare the generic mutation profile (readOnly=false, destructive=false, idempotent=false); the description adds substantial non-obvious behaviour: it creates a pending draft and does not post to the books, approval increases customer balance and output SST, one-tap approval is refused if the total shifted since filing, reversed Shopee/TikTok/Shopify orders are rejected at file time and at approval, no cap on the charge so the approver sees the original invoice total, no stock/COGS/restock semantics, and no correction lane exists for an already-posted sell-side note. No contradiction with annotations.

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?

Front-loaded well: the purpose, the no-posting behaviour, the prerequisite, and the invoice requirement all land in the first few sentences. But it is a very long block for 11 parameters, with all-caps digressions (the buy-side /debit-notes page, the posted-note correction lane, the line-keys changelog) that are useful for disambiguation yet could be compressed. Redundancy exists between the description's money-only paragraph and the schema's own unitAmount/description warnings.

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?

There is no output schema, and the description compensates by explaining what filing produces (a pending draft, a review screen, a one-tap approval that is refused if the total changed). For a high-risk financial mutation with 11 parameters, it covers failure modes, prerequisites, downstream effects and recovery paths thoroughly.

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 82% and the schema itself already documents unitAmount, quantity, productRef, taxCode and originalDocId well, so much of the description's field guidance is reinforcement. It does add real value beyond the schema on cross-parameter semantics ('the ORIGINAL INVOICE IS REQUIRED', 'every line must name a product that actually appears on that invoice') and supplies usage guidance for needsReview, which is an undocumented bare boolean in the schema. The strict-line-keys warning also constrains the whole lines object rather than a single field.

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 specific verb+resource ('File a SELL-SIDE DEBIT NOTE draft') and immediately defines the concept as an additional charge on an invoice already issued, with three concrete examples of when that applies. It explicitly distinguishes itself from the two nearest siblings: create_credit_note_draft ('unlike a credit note...') and create_invoice_draft ('the right document is a NEW INVOICE'). An agent can route correctly without opening any 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 prerequisites (run intake_contract with doc_type:'sales_debit_note' first; locate the invoice via search_documents), explicit exclusions ('if there is nothing to correct upward, the right document is a NEW INVOICE... so say that rather than filing this'; extra goods delivered -> new invoice), and named alternatives for error recovery (revise_draft with kind 'sales_debit_note' rather than filing a second one). The buy-side vs sell-side routing is also spelled out.

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