Skip to main content
Glama

Taokeh MCP server

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

update_quote_draft

FILES A PENDING DRAFT ONLY — NOTHING CHANGES UNTIL A HUMAN REVIEWS AND APPROVES IT IN TAOKEH. Propose a correction to a QUOTE that already exists — a wrong price or quantity, a missing or extra line, the wrong date, validity, term or notes. An admin or bookkeeper reviews a plain current → proposed DIFF and approves. A quote posts nothing, so the correction touches no ledger, no stock and no e-invoice. ROUTING — (1) the quote should not exist at all: the owner voids it in Taokeh (Quotes → the quote → Void); there is no AI lane for voiding. (2) the quote is wrong and still OPEN: THIS tool. (3) the quote was already CONVERTED into an invoice or a delivery order: it is closed to edits — correct the document it became (update_invoice_draft or update_delivery_order_draft). A NEW quote is create_quote_draft. WHAT YOU CAN CHANGE: quoteDate, validUntil (null clears it), term, notes (null clears it) and lines. WHAT YOU CANNOT, each refused by name: the CUSTOMER (a quote to someone else is a different quote), the QUOTE NUMBER, the CURRENCY or exchange rate, and converting or voiding. ONLY AN OPEN QUOTE can be corrected — checked when you file and again when the reviewer taps. Leave a line's taxCode out and it inherits this quote's own SST code for its product — unless the quote carries that product under more than one code, when you must state it. A quote taxed at a whole-document rate (no SST codes on its lines) needs taxRate whenever its LINES change (see that field). 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.
quoteIdYesREQUIRED — the quote's real id, from search_documents. A quote number is refused: correcting the wrong document silently is worse than asking which one they mean.
proposedYesONLY what you want changed. An unknown or not-patchable key is refused by name; a proposal the quote 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 quote should show, if the user told you one — cross-checked against the server's own figure and flagged on the review screen.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

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 sparse annotations (readOnlyHint false, destructiveHint false). It discloses that nothing changes until human approval, that approval updates the document IN PLACE through the same Edit-screen path, that omitted fields are carried across untouched, that no-op proposals are refused, and that stale edits are refused with both versions shown. No contradiction with annotations.

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?

The description is long but every section earns its place — ROUTING, WHAT YOU CAN CHANGE, WHAT YOU CANNOT, WHAT HAPPENS ON APPROVAL, LINES, STALE. The most critical constraint ('FILES A PENDING DRAFT ONLY') is front-loaded in all caps, and the content is organized so an agent can quickly extract routing and refusal rules.

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 a complex 5-parameter tool with a nested `proposed` object and no output schema, the description covers everything needed to call it correctly: required quoteId semantics, real-id vs number refusal, editable vs immutable fields, line replacement semantics, tax inheritance, stale-draft recovery, and approval-time behavior. Nothing essential is missing.

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 meaning: which fields are patchable, which are refused by name, that `lines` is a FULL replacement set, that `keep` references lineNo from search_document_lines, how omitted taxCode inherits the document's SST code, and the special taxRate requirement. This substantially enriches the bare field definitions.

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 a clear statement: 'FILES A PENDING DRAFT ONLY — NOTHING CHANGES UNTIL A HUMAN REVIEWS AND APPROVES IT IN TAOKEH.' It states a specific verb (propose a correction), a specific resource (an existing QUOTE), and explicitly distinguishes itself from siblings like create_quote_draft, update_invoice_draft, and update_delivery_order_draft.

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 section gives exact when-to-use conditions: use this tool when a quote is wrong and still OPEN; void through Taokeh if it should not exist; correct the converted document if it became an invoice or delivery order; use create_quote_draft for a new quote. It also names revise_draft for stale-draft handling, leaving no ambiguity about alternatives.

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