Skip to main content
Glama

Issue a quotation, billing note or receipt PDF (th + en) from a Sales & Billing deal

issue_sales_document

Issue a quotation, billing note or receipt PDF (th + en) from a Sales & Billing deal.

Ask the user for the customer's name, address and tax ID before issuing, and show the lines and VAT mode for approval; never invent them. kind quotation = whole deal; billing_note = one installment (give installment_key): it sets that installment's invoice_no and invoiced_at (marks it invoiced); receipt = a PAID installment only (after paid_at, else 409 installment_not_paid), not a tax invoice. BoardMark issues no tax invoices. revise_of re-issues the latest quotation or billing note as -R2. Numbers are automatic. Needs the company tax profile (else 409 seller_incomplete: tell a company admin). Both PDFs are attached to the deal; reply gives their paths.

Issue a quotation / billing note / receipt (D149). First ask the user for the customer's name, address and tax ID, and the lines and VAT mode — never invent them — and show them before issuing. A billing note marks the installment invoiced; a receipt only after the installment is paid; BoardMark issues no tax invoices (tell the user to use their accounting system for those). Numbers are automatic and permanent. The result lists the files (attachment_id, th + en): give them to get_download_url when the user wants the PDF. 409 seller_incomplete → a company admin must complete the tax profile in the web app.

Input Schema

NameRequiredDescriptionDefault
kindYesKind of a sales document (spec D149): `quotation` (ใบเสนอราคา, one per deal), `billing_note` (ใบวางบิล, per installment), `receipt` (ใบเสร็จรับเงิน, per paid installment; never a tax invoice). Default number series QT / BN / RC; BoardMark issues no tax invoice.
noteNo
linesYes
reasonNoSpec D144: why you make this change (≤ 200 characters). Optional, but give it when you act as an agent account — it is shown in the agent's run log ("moved KJ-12 To Do → In Progress because <reason>"). board-mcp records it in `agent.run`; board-core / board-files accept it and ignore it (it never changes the file, the version or the history).
note_enNo
paymentNoReceipt only: how the money was received.
customerYesThe buyer printed on the document. Name is required when issuing (empty -> 400 `validation_failed`); the rest is optional. `*_en` empty -> the EN file uses the Thai text.
vat_modeYesVAT on a sales document (spec D149): `include` = prices already include 7 % VAT, `add` = 7 % is added to the subtotal, `none` = no VAT. The rate is fixed at 7 % this round.
issue_keyYesIssue key `{PROJECT}-{n}`, e.g. `KJ-101`.
revise_ofNoSales document id (spec D149): `sdoc_` + ULID, owned by board-core.
project_keyYesProject key, e.g. `KJ`. 2–10 chars, uppercase letters and digits, starts with a letter.
valid_untilNo
installment_keyNoIssue key `{PROJECT}-{n}`, e.g. `KJ-101`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=false / idempotentHint=false; the description goes far beyond them by disclosing side effects (it sets the installment's invoice_no and invoiced_at, marking it invoiced), that numbers are automatic and permanent, that both PDFs are attached to the deal, and the two named 409 outcomes with their remedy (seller_incomplete → tell a company admin). That is exactly the mutation context annotations cannot convey.

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-loaded and information-dense, but the description is roughly 250 words and the second paragraph substantially restates the first (customer data, VAT mode, no tax invoices, automatic numbers, seller_incomplete 409). The duplication is the main structural flaw; the tool could say the same thing in about half the 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?

No output schema exists, and the description compensates by describing the return value (attachment_id for th + en files, plus paths) and routing to get_download_url. Given 13 params with nested customer/lines/payment objects, the description covers the operational prerequisites and failure modes an agent needs before calling it.

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 69% and the description adds real meaning for the tricky parameters: kind semantics per enum value, installment_key's role for billing_note, and revise_of's -R2 re-issue behavior. It does not touch payment, valid_until, or the note/note_en fields, but the schema already carries those descriptions, so the gap is minor.

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 (issue) and resource (quotation / billing note / receipt PDF, th + en) scoped to a Sales & Billing deal, and explicitly distinguishes itself from a tax invoice ('BoardMark issues no tax invoices'), which is the most likely confusion with a sibling/finance tool. An agent can tell exactly what this creates versus list_sales_documents or get_download_url.

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 per-kind selection rules: quotation = whole deal, billing_note = one installment (requires installment_key), receipt = paid installment only (else 409 installment_not_paid). It also adds a mandatory pre-step ('ask the user for customer name, address, tax ID... never invent them; show the lines and VAT mode for approval') and names the follow-up sibling (get_download_url) for retrieving the PDFs.

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