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 document: a purchase order in Taokeh carries no tax code and no tax line, and input SST is settled on the bill against the supplier's tax invoice. 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

Name	Required	Description
`term`	No	The payment/delivery term line, e.g. 'Net 30'.
`lines`	Yes
`notes`	No	A 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.
`poDate`	Yes
`vendor`	No
`vendorId`	No
`reference`	No	The 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).
`needsReview`	No
`expectedDate`	No	When the goods are expected, YYYY-MM-DD. Optional — omit it rather than guess.
`printedTotal`	No
`confirmNewVendor`	No	Set 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. Dates show when Glama detected each change.

Changed2 schema fields changedSep 9, 2026

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."

Changed2 schema fields changedSep 6, 2026

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."

Changed4 schema fields changedSep 2, 2026

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."

AddedAug 13, 2026

TDQS

A5/5.0

Behavior5/5

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

The description goes far beyond the annotations by disclosing concrete side effects and non-effects: no journal entry, no stock movement, no amount owing, no email to the supplier, approval only saves a draft, and the server recomputes quantities authoritatively. It also claries that no SST or tax line exists on the purchase order.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Dense but well-structured: it opens with the core definition, then states non-effects, exclusions, preparation steps, server authority, and error-recovery routing. Every sentence carries a distinct constraint or decision rule without redundant filler.

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 11 parameters, no output schema, and a large sibling set, the description covers what to send, how to prepare the data, what the user must still do, what the server will override, and which alternative tool to use fpr different situations. An agent has enough to call and interpret the tool correctly.

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?

With schema coverage at only 45%, the description compensates substantially. It explains the reference field as the buyer's own PO number rather than the supplier quotation, dictates the length and purpose of notes, explains needsReview, describes how quantity is either derived from tally or treated as advisory, and tells the agent to omit expectedDate rather than guess.

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?

The description states a specific action: 'File a PURCHASE-ORDER draft into Taokeh', and immediately explains what that means — an intent to place with a supplier. It distinguishes this from a bill by explicitly saying it posts nothing and moves nothing, and from create_bill_draft by noting arrived goods belong to that tool.

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 routing rules: use revise_draft if filed wrong, use create_bill_draft if goods have already arrived, and use the manual purchase-order form for non-stock items. It also directs the agent to prepare fields with intake_contract, resolve_vendor, and resolve_product first.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Taokeh MCP server tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?