Skip to main content
Glama

Taokeh MCP server

File a pending correction draft for a posted supplier debit note (human approves in Taokeh)

update_supplier_debit_note_draft

FILES A PENDING DRAFT ONLY — NOTHING CHANGES UNTIL A HUMAN REVIEWS AND APPROVES IT IN TAOKEH. Propose a correction to a BUY-SIDE DEBIT NOTE already posted in Taokeh — a purchase return raised against a SUPPLIER's bill (Taokeh's /debit-notes page). This is NOT the sell-side debit note that create_debit_note_draft files (an additional charge on your own invoice); that document has no correction lane at all — the owner voids it and issues a new one. An ADMIN reviews this as a DIFF (current → proposed) and approves; only that tap re-books the note, and it keeps the SAME debit-note number, the bill it was raised against and any attached document. Pass debitNoteId, the note's REAL id from search_documents (docType debit_note). ROUTING — (1) THE RETURN NEVER HAPPENED (keyed twice, wrong bill): the owner VOIDS the note in Taokeh (Debit notes → the note → Void); voiding keeps it on the register marked VOID. A note VALIDATED on MyInvois cannot be voided: any further correction goes through LHDN against the validated document. (2) THE RETURN IS RIGHT BUT TYPED WRONG (a wrong line, quantity, cost, date or reason): THIS tool. (3) MORE GOODS WENT BACK LATER: a new debit note, raised by the owner in Taokeh — there is no AI lane for creating a buy-side debit note. WHAT YOU CAN CHANGE: dnDate, reason, and lines — the FULL REPLACEMENT SET. ⛔ EVERY LINE MUST ANSWER goodsReturned (true = these goods physically went back to the supplier and leave stock, false = money only). There is no default. Your answer only PRE-FILLS the admin's per-line question on the full review page; a ONE-TAP approval never moves stock and is refused whenever the note already took goods off the shelf or any line says goods went back. Stock only ever leaves for a product the BILL actually received, never more than the bill still has standing. SST is inherited from the bill — there is no tax code to send. A NOTE WITH A DISCOUNTED LINE (search_document_lines shows discount on it): its lines cannot be corrected here at all — any lines proposal on it is refused, and the owner changes them in Taokeh (Debit notes → Edit); a date or reason correction (no lines) still works and reposts the note's own lines, discounts included. WHAT YOU CANNOT, each refused by name: the SUPPLIER, the debit-note NUMBER, the BILL it was raised against. BLOCKED OUTRIGHT, checked when you file (the server runs the real correction and rolls it back) and again when the admin taps: the note is voided; it is validated or exported for MyInvois as a self-billed document; a supplier refund is allocated to it; the bill it was raised against is gone; its date is inside a LOCKED period; or the corrected note would credit more than the bill still owes. A proposal that changes nothing is refused. If the note is edited after you read it, the one-tap approval is refused — call revise_draft (kind 'supplier_debit_note_update').

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
notesNoA SHORT reviewer note: what was wrong, what you changed, and whether the goods really went back.
proposedYesONLY what you want changed. An unknown or not-patchable key is refused by name.
debitNoteIdYesREQUIRED — the posted BUY-side debit note's real id, from search_documents (docType debit_note).
needsReviewNoSet true when something gave you pause.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / proposed / properties / lines / description
      Previous value: -"The FULL replacement line set. Omit it entirely when you are only correcting the date or the reason."New value: +"The FULL replacement line set. Omit it entirely when you are only correcting the date or the reason. A line carrying a converted per-foot or per-piece cost's printed note (like \"(400' @ RM 1.60/feet)\") is refused unless the bill has that very line with no discount: its rounding sits in the bill line's discount, which this tool cannot send, so that change is made on Taokeh's Edit screen (Debit notes → Edit)."
  2. Changed1 schema field changed
    • changedInput schema / properties / proposed / properties / lines / items / properties / unitCost / description
      Previous value: -"Ringgit per unit (the bill’s cost), POSITIVE. Two decimals at most (whole sen, or whole cents in another currency), exactly as invoiced; put a discount or tax in its own field, never folded into the cost."New value: +"Ringgit per unit (the bill’s cost), POSITIVE. Up to four decimals (e.g. 0.0325), exactly as invoiced — but a per-foot or per-piece price that Taokeh converts to tons: two decimals. Put a discount or tax in its own field, never folded into the cost."
  3. Changed1 schema field changed
    • changedInput schema / properties / proposed / properties / lines / items / properties / unitCost / description
      Previous value: -"Ringgit per unit (the bill’s cost), POSITIVE."New value: +"Ringgit per unit (the bill’s cost), POSITIVE. Two decimals at most (whole sen, or whole cents in another currency), exactly as invoiced; put a discount or tax in its own field, never folded into the cost."
  4. Added

TDQS

A4.6/5.0
Behavior4/5

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

Goes far beyond the annotations: explains that nothing posts until an admin taps, that approval is refused on stale reads, and enumerates each refusal by name. This is consistent with destructiveHint=false and idempotentHint=false rather than contradicting them. It stops short of describing the response shape, but no output schema exists so that is a minor gap.

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 caveat and the tool's identity are front-loaded, and the routing/blocked lists are well-organized with headers. It is very long and re-explains goodsReturned that the schema already documents, so a little trimming is possible, but most sentences carry decision-relevant behavior.

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 complex mutation-with-approval tool with a nested schema and no output schema, the description covers what changes, what is refused, when, and by whom. An agent has everything needed to file a correctable draft.

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 100%, so the baseline is 3, but the description adds real semantics: 'lines' is the FULL replacement set, must be omitted for date/reason-only fixes, must answer goodsReturned with no default, and is refused on discounted lines. It also constrains debitNoteId to search_documents. Some of this duplicates the schema's own descriptions.

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+resource (propose a correction to a posted buy-side supplier debit note) and explicitly distinguishes itself from the sibling create_debit_note_draft ('this is NOT the sell-side debit note'). The scope ('FILES A PENDING DRAFT ONLY') is front-loaded before any detail.

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?

Provides an explicit three-way routing decision (void vs. this tool vs. new note) keyed to the real-world condition that selects each, plus a named alternative (revise_draft) for stale reads. When-to-use, when-not-to-use, and blockers are all 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