Skip to main content
Glama

Taokeh MCP server

File purchase-order draft

create_purchase_order_draft

File a PURCHASE-ORDER draft into Taokeh — an order you intend to PLACE with a supplier, typically read off their quotation. It POSTS NOTHING and MOVES NOTHING: a purchase order is an intent to buy, so approving it creates no journal entry, no stock movement and no amount owing. The books move later, when the goods arrive and the user converts the order into a bill on its page in Taokeh — a step this tool never takes for them. Approval also saves the order as a DRAFT; issuing it to the supplier is the user's own tap, and Taokeh emails nobody. INVENTORY-ONLY — every line must be a product the company stocks; a service or one-off non-stock charge belongs on the manual purchase-order form. NO SST on this draft: it files the order with no tax code and no tax line, and input SST is settled on the bill against the supplier's tax invoice (an SST code the user adds on Taokeh's own purchase-order form taxes the order by its lines' codes, rounded per code on the subtotal, the same as the bill it becomes). Shape the fields with intake_contract(doc_type:'purchase_order') + resolve_vendor + resolve_product first. The server re-computes every line quantity from the tally and the order total — so present your working, but the server's figures are authoritative. Set needsReview and add a SHORT reviewer note in notes (one or two sentences naming what to double-check — not lengthy reasoning) for any doubt. Filed it wrong? Use revise_draft (kind: 'purchase_order') rather than filing a second one. Goods that have ALREADY arrived are not this door — use create_bill_draft. ⛔ 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
termNoThe payment/delivery term line, e.g. 'Net 30'.
linesYes
notesNoA SHORT reviewer note: one or two plain sentences, written in the reviewer's language, flagging what the human should double-check before they order — a quantity you weren't sure of, a supplier name you guessed at, a judgment call you made. The reviewer reads this on a small approval card, so keep it brief and human. Leave it empty when there is nothing to flag.
poDateYes
vendorNo
vendorIdNo
referenceNoThe BUYER'S OWN purchase-order number, if they already have one — it becomes this order's document number. NOT the supplier's quotation number (put that in `notes`). Usually omit it: Taokeh numbers the order itself (POxxxx).
needsReviewNo
expectedDateNoWhen the goods are expected, YYYY-MM-DD. Optional — omit it rather than guess.
printedTotalNo
confirmNewVendorNoSet to true ONLY after the user has EXPLICITLY confirmed this supplier is genuinely new. It skips the near-miss guard (which rejects a name that looks like shorthand for an existing vendor). Never set it to push a near-miss through — ask the user first.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / lines / items / properties / quantity / description
      Previous value: -"The line quantity. On a measurement-profile company (see intake_contract's `measureProfile`) OMIT it whenever you give thickness/width/tally, or write the measure detail into the description ('2x2 = 10/10 12/14') — the server derives the authoritative quantity from those, and a quantity sent alongside a parseable tally is NOT used to compute: it is kept as your advisory figure and shown to the reviewer beside the server's. On the default passthrough company nothing is derived, so this IS the quantity — send it."New value: +"The line quantity. On a measurement-profile company (see intake_contract's `measureProfile`) OMIT it whenever you give thickness/width/tally, or write the measure detail into the description ('2x2 = 10/10 12/14') — the server derives the authoritative quantity from those, and a quantity sent alongside a parseable tally is NOT used to compute: it is kept as your advisory figure and shown to the reviewer beside the server's. On the default passthrough company nothing is derived, so this IS the quantity — send it. On a timber company, for an item kept in tons, a per-ton quantity MORE than the tons a description's size and total feet give ('2x2 = 400'' is 0.2222 ton) is refused, naming the tons — send the tons, never the feet."
  2. Changed1 schema field changed
    • changedInput schema / properties / lines / items / properties / unitCost / description
      Previous value: -"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: +"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
    • addedInput schema / properties / lines / items / properties / unitCost / description
      Added value: +"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. Changed2 schema fields changed
    • changedInput schema / properties / lines / items / properties / tally / description
      Previous value: -"The piece tally as pieces/length_ft pairs — '10/10 12/14' is 10 pieces of 10 ft and 12 of 14 ft. With thickness and width this is what the quantity is derived FROM."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."
    • addedInput schema / properties / lines / items / properties / unit / description
      Added value: +"The unit the PRICE is quoted in. On a timber company: 'feet' = per running foot, 'pcs' = per piece, 'ton' or omitted = per ton. A per-foot/per-piece price is converted to the per-ton rate from thickness/width/tally, or from a cut list in the description ('2x2 = 10/10 12/14'); a description cut list the server cannot read cleanly is refused — send thickness/width/tally instead."
  5. Changed2 schema fields changed
    • addedInput schema / properties / lines / items / additionalProperties
      Added value: +false
    • addedInput schema / properties / lines / items / properties / description / description
      Added value: +"The line text as PRINTED on the supplier's document, when it says more than the product name does — a size, a grade, a pack, a period covered. It rides onto the posted line, so send what the paper says rather than a tidier phrasing of your own. Leave it out when the product name already says it. This is TEXT, not a field: Taokeh has no column for a dimension, a grade or a variant, so anything of that kind belongs here."
  6. Changed2 schema fields changed
    • changedInput schema / properties / lines / items / properties / quantity / description
      Previous value: -"The line quantity. On a measurement-profile workspace (see intake_contract's `measureProfile`) OMIT it whenever you give thickness/width/tally, or write the measure detail into the description ('2x2 = 10/10 12/14') — the server derives the authoritative quantity from those, and a quantity sent alongside a parseable tally is NOT used to compute: it is kept as your advisory figure and shown to the reviewer beside the server's. On the default passthrough workspace nothing is derived, so this IS the quantity — send it."New value: +"The line quantity. On a measurement-profile company (see intake_contract's `measureProfile`) OMIT it whenever you give thickness/width/tally, or write the measure detail into the description ('2x2 = 10/10 12/14') — the server derives the authoritative quantity from those, and a quantity sent alongside a parseable tally is NOT used to compute: it is kept as your advisory figure and shown to the reviewer beside the server's. On the default passthrough company nothing is derived, so this IS the quantity — send it."
    • changedInput schema / properties / lines / items / properties / thickness / description
      Previous value: -"Thickness in inches on a dimensional line — measurement-profile workspaces only (intake_contract shows this workspace's `measureProfile`). Give thickness + width + tally INSTEAD of a quantity and the server computes the authoritative quantity from them."New value: +"Thickness in inches on a dimensional line — measurement-profile companies only (intake_contract shows this company's `measureProfile`). Give thickness + width + tally INSTEAD of a quantity and the server computes the authoritative quantity from them."
  7. Changed4 schema fields changed
    • addedInput schema / properties / lines / items / properties / quantity / description
      Added value: +"The line quantity. On a measurement-profile workspace (see intake_contract's `measureProfile`) OMIT it whenever you give thickness/width/tally, or write the measure detail into the description ('2x2 = 10/10 12/14') — the server derives the authoritative quantity from those, and a quantity sent alongside a parseable tally is NOT used to compute: it is kept as your advisory figure and shown to the reviewer beside the server's. On the default passthrough workspace nothing is derived, so this IS the quantity — send it."
    • addedInput schema / properties / lines / items / properties / tally / description
      Added value: +"The piece tally as pieces/length_ft pairs — '10/10 12/14' is 10 pieces of 10 ft and 12 of 14 ft. With thickness and width this is what the quantity is derived FROM."
    • addedInput schema / properties / lines / items / properties / thickness / description
      Added value: +"Thickness in inches on a dimensional line — measurement-profile workspaces only (intake_contract shows this workspace's `measureProfile`). Give thickness + width + tally INSTEAD of a quantity and the server computes the authoritative quantity from them."
    • addedInput schema / properties / lines / items / properties / width / description
      Added value: +"Width in inches on a dimensional line. Goes with thickness and tally."
  8. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare non-read-only, non-destructive, non-idempotent. The description adds genuinely load-bearing behaviour: nothing is POSTed or moved, no journal/stock/amount owing is created, the order is saved as a DRAFT and Taokeh emails nobody, SST is not applied by this tool, quantities are recomputed server-side and the agent's figures are advisory only, and unknown line keys are now refused by name rather than silently dropped.

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?

Front-loaded with the purpose and the no-posting guarantee, which are the highest-value facts. The remaining bulk is largely earned by the domain's real complexity, though the parenthetical SST sentence and the layered tally/quantity caveats are dense enough to slow an agent down.

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?

No output schema exists, so the description must carry the full return-side story, and it does: it tells the agent the draft is filed, no books move, and the conversion to a bill happens later on Taokeh. Combined with the strict-key warning and the cross-tool routing, an agent has everything needed to call this correctly for an 11-parameter mutation.

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 description coverage is only 45%, but the description compensates for the important gaps: it explains what `notes` should contain (one-to-two-sentence reviewer flag), instructs setting `needsReview`, clarifies that `reference` is the buyer's own PO number and not the supplier's, and that `confirmNewVendor` bypasses the near-miss guard only after explicit user confirmation. It does not add much for `vendor`/`vendorId`/`printedTotal`, keeping it short of a 5.

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 PURCHASE-ORDER draft'), then defines the semantic boundary precisely: an order you intend to place, read off a quotation. It explicitly distinguishes itself from create_bill_draft ('goods that have ALREADY arrived') and from update_purchase_order_draft/revise_draft, so 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 when-to-use (intent to buy, not yet received), when-not (goods already arrived → create_bill_draft; service/non-stock → manual form), prerequisite sequence (intake_contract, resolve_vendor, resolve_product), and the correction path (revise_draft kind:'purchase_order' rather than filing a second one). Nothing material is left to inference.

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