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

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. Changed2 schema fields changed
    • removedInput schema / properties / lines / items / properties / discount / anyOf
      Removed value: -[
      -  {
      -    "type": "number"
      -  },
      -  {
      -    "type": "string"
      -  }
      -]
    • addedInput schema / properties / lines / items / properties / discount / type
      Added value: +[
      +  "number",
      +  "string"
      +]
  2. 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. 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."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'' and '2\" x 2\" = 400'' are 0.2222 ton) is refused, naming the tons — send the tons, never the feet. Beside a cut list ('2x2 = 15/10 12/8') your quantity is replaced by the cut list's tons; where it cannot be (inch marks on the size, a named size such as 'Nepek = 15/10', spaces around the '/'), a quantity more than the cut list's tons is refused the same way."
  3. 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."
  4. 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."
  5. 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."
  6. 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."
  7. 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."
  8. 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."
  9. 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."
  10. Added

TDQS

A4.5/5.0
Behavior4/5

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

Goes far beyond the annotations: no journal entry, no stock movement, no amount owing, approval leaves it a DRAFT, no supplier email, no SST applied, and the server recomputes quantities so its figures are authoritative. Also discloses a hard failure mode (unknown line keys are refused by name and nothing is filed). Docked one point because the SST parenthetical is dense and partly redundant with the schema's tax notes.

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-loads the most decision-critical fact (posts nothing, moves nothing) and the routing exclusions, but the block is long and mixes uppercase emphasis, em-dashes and a nested SST tangent that is harder to parse than it needs to be. Most sentences earn their place; the tax-code aside and the 'working' aside could be tightened.

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 an 11-parameter draft-creation tool with no output schema, it covers creation contract, prerequisites, review workflow, correction path, exclusion cases, and the authoritative-quantity behavior. An agent has everything needed to call it correctly or to know it should not.

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 only 45%, so the description must compensate; it does add real meaning for the review parameters ('Set needsReview and add a SHORT reviewer note in `notes`... one or two sentences naming what to double-check') and for the quantity-precedence rule. It does not explain term, vendor vs vendorId, or printedTotal, leaving several undocumented parameters without narrative guidance.

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') and immediately scopes it as an intent to buy with no posting or movement. It explicitly separates itself from create_bill_draft ('goods that have ALREADY arrived are not this door') and from update/revise paths, so an agent can route correctly without reading another 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 concrete when-to-use prerequisites (shape fields with intake_contract(doc_type:'purchase_order') + resolve_vendor + resolve_product first), an explicit exclusion (services/non-stock charges belong on the manual form), a correction path (revise_draft kind:'purchase_order' rather than filing twice), and the alternative for received goods (create_bill_draft).

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