Skip to main content
Glama

Taokeh MCP server

File a pending delivery-order correction draft (human approves in Taokeh)

update_delivery_order_draft

FILES A PENDING DRAFT ONLY — NOTHING CHANGES UNTIL A HUMAN REVIEWS AND APPROVES IT IN TAOKEH. Propose a correction to a DELIVERY ORDER that already exists and has not been invoiced — a wrong quantity or price, a missing or extra line, the wrong date or notes. An admin or bookkeeper reviews a plain current → proposed DIFF and approves. A delivery order posts nothing and moves NO stock (stock moves when it is invoiced), so the correction touches no ledger and no stock. ⚠ Approving re-captures each line's cost from the products' CURRENT average cost — exactly what Taokeh's own Edit screen does; it is a dispatch-time reference that posts nothing. ROUTING — (1) the delivery never happened: the owner voids the DO in Taokeh (Delivery orders → the DO → Void); there is no AI lane for voiding. (2) the DO is wrong and still OPEN: THIS tool. (3) the DO has already been INVOICED: it is closed to edits — correct the invoice instead (update_invoice_draft). WHAT YOU CAN CHANGE: doDate, notes (null clears them) and lines. WHAT YOU CANNOT, each refused by name: the CUSTOMER, the DO NUMBER, the CURRENCY or exchange rate, and invoicing or voiding. ONLY AN OPEN DELIVERY ORDER can be corrected — checked when you file and again when the reviewer taps. Leave a line's taxCode out and it inherits this DO's own SST code for its product — unless the DO carries that product under more than one code, when you must state it. WHAT HAPPENS ON APPROVAL: the document is updated IN PLACE — same id, same number — through the SAME update Taokeh's own Edit screen runs. Every field you leave out is carried across exactly as it stands (the party, the attention contact, the currency and its frozen exchange rate, the tax) and is never reset. LINES: lines is the FULL replacement set. READ THE LINES FIRST with search_document_lines — each row's lineNo is what a { keep: } entry refers to, and keep is how a line that is already right survives untouched (a measured line keeps its frozen unit and its rounding row). A changed or new line is written in full, in the create tool's line shape, and the server re-derives its quantity and amount. A proposal that changes nothing is refused rather than filed as an empty diff. STALE: if a person edits the document after you read it, the one-tap approval is refused and the reviewer is shown both versions — call revise_draft with this draft's kind to re-read and re-propose. Pass the document's REAL id from search_documents; a document number is refused. A line Taokeh converted from a per-foot or per-piece price prints in tons at a whole-ringgit rate under a note like "(150' @ RM 0.50/feet)": send such a line in its FILED form — thickness, width, tally, unit 'feet' or 'pcs', the per-foot or per-piece price (on a purchase, the supplier's cost) and only the grade as the description, never the printed note. On a correction, a PURCHASE line may instead be sent back exactly as it stands on the document; a SELLING line sent back exactly as it stands is read back into its filed form only when its note's price reproduces it (otherwise keep it with { keep: } where offered, or correct the header only); any other line carrying the note follows the rule for a new line — a selling line read back only at its own tons and rate with no discount, a purchase line refused.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
notesNoA SHORT reviewer note in the reviewer's language: what was wrong, what you changed, and anything they should check before approving.
proposedYesONLY what you want changed. An unknown or not-patchable key is refused by name; a proposal the delivery order already agrees with is refused rather than filed.
needsReviewNoSet true when something gave you pause — a quantity you inferred, a price the user was unsure about. It flags the draft for the reviewer.
printedTotalNoThe grand total the corrected delivery order should show, if the user told you one — cross-checked against the server's own figure and flagged on the review screen.
deliveryOrderIdYesREQUIRED — the delivery order's real id, from search_documents. A DO number is refused.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / proposed / properties / lines / items / properties / keep / description
      Previous value: -"Keep an EXISTING line exactly as it stands: { keep: <lineNo> } and nothing else beside it — lineNo from search_document_lines. The stored line rides across VERBATIM (its frozen unit, its discount, its SST code) and, on a measured line, the engine's rounding row under it comes along automatically. Use this for every line that is already right."New value: +"Keep an EXISTING line exactly as it stands: { keep: <lineNo> } and nothing else beside it — lineNo from search_document_lines. The stored line rides across VERBATIM (its frozen unit, its discount, its SST code) and, on a measured line, the engine's rounding row under it comes along automatically. Use this for every line that is already right. A line Taokeh converted from a per-foot or per-piece price prints in tons at a whole-ringgit rate under a note like \"(150' @ RM 0.50/feet)\": send such a line in its FILED form — thickness, width, tally, unit 'feet' or 'pcs', the per-foot or per-piece price (on a purchase, the supplier's cost) and only the grade as the description, never the printed note. On a correction, a PURCHASE line may instead be sent back exactly as it stands on the document; a SELLING line sent back exactly as it stands is read back into its filed form only when its note's price reproduces it (otherwise keep it with { keep: <lineNo> } where offered, or correct the header only); any other line carrying the note follows the rule for a new line — a selling line read back only at its own tons and rate with no discount, a purchase line refused."
  2. Changed1 schema field changed
    • changedInput schema / properties / proposed / properties / lines / items / properties / unitPrice / description
      Previous value: -"The selling price per unit, in the document's own currency."New value: +"The selling price per unit, in the document's own currency. 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
    • changedInput schema / properties / proposed / properties / lines / items / properties / tally / description
      Previous value: -"The piece tally (dimensional lines)."New value: +"The tally as pieces/length_ft pairs — '10/10 12/14' is 10 pieces of 10 ft and 12 of 14 ft — OR the total running feet like 400' when the paper gives no cut list. Never invent a cut list (no '1/400'). With thickness and width this is what the quantity is derived FROM. Every token must be a pieces/length pair — a tally with anything else in it (a grade word, a stray number, '=') is refused; put grade words in the description. A total-feet tally needs thickness and width (or a named size) to work out the tons, and has no pieces, so it cannot carry a per-piece price — both are refused."
  4. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover only the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false); the description carries far more. It discloses that approval re-captures each line's cost from current average cost, that nothing posts to ledger or stock, that updates happen in place with unspecified fields carried across, that an empty diff is refused, and that a concurrent human edit invalidates the one-tap approval.

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 mandatory warning is correctly front-loaded in caps, but the body is very long and the per-foot/per-piece conversion rule is stated twice almost verbatim — once in the description proper and again inside the `keep` schema description. For a complex tool some length is earned, but the duplication and the ALL-CAPS clause stacking cost readability.

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?

Given the nested `proposed.lines` object, a 100%-covered schema, no output schema, and sibling update_* tools, the description closes every gap an agent needs: precondition, allowed/forbidden fields, full-vs-keep line semantics, stale handling, and post-approval document behavior.

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 100%, so the baseline is 3, but the description goes well beyond it: it names what is patchable (doDate, notes, lines) versus refused (customer, DO number, currency, invoicing/voiding), explains why deliveryOrderId must be a real id and not a number, defines `lines` as a full replacement set requiring a prior search_document_lines read, and explains taxCode inheritance and keep-line semantics.

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 and resource ('File a pending delivery-order correction draft') and immediately bounds the effect ('NOTHING CHANGES UNTIL A HUMAN REVIEWS AND APPROVES IT'). It explicitly distinguishes itself from siblings: voiding has 'no AI lane', and invoiced DOs route to update_invoice_draft. An agent can select this tool 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?

The ROUTING block is a textbook when/when-not decision tree: (1) delivery never happened → void in Taokeh, (2) wrong and still OPEN → this tool, (3) already INVOICED → update_invoice_draft. It also states the precondition (only an OPEN DO) is re-checked at approval time, and points at revise_draft for the stale case.

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