Skip to main content
Glama

Taokeh MCP server

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

update_purchase_order_draft

FILES A PENDING DRAFT ONLY — NOTHING CHANGES UNTIL A HUMAN REVIEWS AND APPROVES IT IN TAOKEH. Propose a correction to a PURCHASE ORDER that already exists — a wrong quantity or cost, a missing or extra line, the wrong date, term or notes. An admin or bookkeeper reviews a plain current → proposed DIFF and approves. A purchase order posts nothing and moves no stock, so the correction touches no ledger and no stock; a SENT order stays SENT, and Taokeh emails nobody — sending the corrected order to the supplier is the user's own step. ROUTING — (1) the order should not stand: the owner cancels it in Taokeh (Purchase orders → the PO → Cancel); there is no AI lane for cancelling. (2) the order is wrong and not yet converted: THIS tool — a DRAFT or a SENT order both qualify. (3) the order was already CONVERTED into a bill, or is CANCELLED: it is closed to edits — a converted order's bill is the document now, corrected in Taokeh (Purchases → the bill → Edit). A NEW order is create_purchase_order_draft. WHAT YOU CAN CHANGE: poDate, term (null clears it), notes (null clears them) and lines. A purchase order is taxed at a whole-document rate Taokeh stores only as an amount, so when a taxed order's LINES change you must also send taxRate (see its field). WHAT YOU CANNOT, each refused by name: the SUPPLIER (an order to someone else is a different order), the PO NUMBER, the CURRENCY or exchange rate, the TAX, and marking sent, cancelling or converting. INVENTORY-ONLY lines, as on create_purchase_order_draft. 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.

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 purchase 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 purchase order should show, if the user told you one — cross-checked against the server's own figure and flagged on the review screen.
purchaseOrderIdYesREQUIRED — the purchase order's real id, from search_documents. A PO number is refused.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.9/5.0
Behavior5/5

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

Annotations carry no safety hints (all false), so the description fully discloses behavior: nothing changes until human approval, the document is updated in place on approval, no ledger/stock impact, no emails, staleness refusal, and that a no-op proposal is refused. This goes far beyond what annotations provide.

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 description is long but well-structured with labeled sections (ROUTING, WHAT YOU CAN CHANGE, WHAT YOU CANNOT, WHAT HAPPENS ON APPROVAL, LINES, STALE) and front-loads the key safety point. Some redundancy with the title and schema exists, but every section adds operational detail, so it earns its length.

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?

Covers all necessary context for safe and correct invocation: when to use, what fields can be changed, what is refused, line semantics, staleness handling, and the id requirement. References sibling tools for pre-read steps. No output schema is needed for a draft-filing action, so completeness is high.

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?

Even though schema coverage is 100%, the description adds critical context not in the schema: taxRate is required when lines change on a taxed order, lines is the full replacement set, keep refers to lineNo from search_document_lines, and purchaseOrderId must be the real id from search_documents. This materially improves correct usage.

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 opens with 'FILES A PENDING DRAFT ONLY' and clearly states the tool proposes corrections to an existing purchase order. It explicitly distinguishes from create_purchase_order_draft (new orders) and revise_draft (stale re-proposal), so an agent can pick it without ambiguity.

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?

Contains a dedicated ROUTING section that spells out when to use this tool (wrong, not converted, DRAFT or SENT), when to cancel in Taokeh instead (order should not stand), when it's closed (converted or cancelled), and that new orders go to create_purchase_order_draft. Also instructs to use revise_draft on staleness.

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