Skip to main content
Glama

quote_create

ONE call creates the whole document: client_name + items [{description, quantity, unit_price}], each price as written ("5000.00"). It claims the next atomic quote number and writes every line together; client_name finds or creates the client. tax_scheme sg_gst or my_sst taxes each line by its tax_code (refusals: see tax_scheme). When present, the second content block is the quote as copy-ready text, shown with a Copy button where the host draws MCP Apps; if the user says they cannot see the quote, give them that block word for word; make a client link with quote_share only when the user asks for one. NEXT: quote_convert to turn the quote into its invoice.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "quote_create"
  }
}

Input Schema

NameRequiredDescriptionDefault
forceNoConfirms a create whose notes or single line item read like a payment RECEIVED or a write-off rather than a new bill — resend the SAME call with force:true to create it anyway. No effect on quote_create (the intent trap is invoice-only).
itemsNoONE call creates the whole document — each line's unit_price is its price exactly as written, a decimal string ("5000.00" for $5,000), and the platform stores the cents itself; or send unit_price_cents in integer CENTS ($15.00 → 1500). quantity takes up to 3 decimals (1.5 hours → 1.5); unit is an optional label (hr, kg); discount_bps is an optional line discount (10% → 1000). tax_code is the line's tax under the document's tax_scheme (sg_gst: standard, zero_rated, exempt, out_of_scope, default standard; my_sst: sales_10, sales_5, service_8, service_6, exempt, required); refused without a tax_scheme.
notesNo
statusNo
currencyNo
client_idNo
issue_dateNo
line_itemsNoAlias of items.
tax_schemeNosg_gst (Singapore GST) or my_sst (Malaysia SST): each line is taxed by its tax_code at the rate in force on the issue date. Under a scheme, a tax_rate_bps other than that rate, an unknown tax_code and a my_sst line without one are refused, naming the valid codes and the rate's source. "none" = no scheme, priced by tax_rate_bps. Left out = your sales settings' tax_scheme.
client_nameNoClient by NAME — resolves to an existing client or creates one (no client_id lookup needed).
valid_untilNo
quote_numberNo
tax_rate_bpsNo
prices_include_taxNotrue = unit prices already include the tax (the tax is worked back out of each line). Default false. Needs a tax_scheme.
converted_invoice_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / items / description
      Previous value: -"ONE call creates the whole document — line items in integer CENTS ($15.00 → 1500), or unit_price as a decimal string. quantity takes up to 3 decimals (1.5 hours → 1.5); unit is an optional label (hr, kg); discount_bps is an optional line discount (10% → 1000). tax_code is the line's tax under the document's tax_scheme (sg_gst: standard, zero_rated, exempt, out_of_scope, default standard; my_sst: sales_10, sales_5, service_8, service_6, exempt, required); refused without a tax_scheme."New value: +"ONE call creates the whole document — each line's unit_price is its price exactly as written, a decimal string (\"5000.00\" for $5,000), and the platform stores the cents itself; or send unit_price_cents in integer CENTS ($15.00 → 1500). quantity takes up to 3 decimals (1.5 hours → 1.5); unit is an optional label (hr, kg); discount_bps is an optional line discount (10% → 1000). tax_code is the line's tax under the document's tax_scheme (sg_gst: standard, zero_rated, exempt, out_of_scope, default standard; my_sst: sales_10, sales_5, service_8, service_6, exempt, required); refused without a tax_scheme."
  2. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Annotations only state readOnly=false, idempotent=false, destructive=false. The description adds substantial context beyond that: it claims the next atomic quote number, explains that client_name may create a client as a side effect, enumerates refusal conditions for tax_code/tax_scheme, and discloses that a second content block contains copy-ready text to relay verbatim if the user cannot see the rendered quote.

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 first clause is front-loaded with the essential claim, and sentences are dense but purposeful. The copy-ready-text/Copy-button passage is slightly long for what it conveys, but it encodes a real instruction the agent must follow, so it largely earns its space.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 15-parameter create tool with no output schema, the description covers the creation flow, client resolution, tax behavior, and the shape of the response (second content block) plus the next step. What is missing is the identity of the created record in the response and the defaults for status/currency/issue_date, which would help an agent call it without guessing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is low (40%) across 15 parameters, and the description compensates well for the hardest ones — unit_price as a decimal string vs unit_price_cents, quantity decimals, discount_bps, tax_code per scheme, prices_include_tax. However, several parameters (issue_date and valid_until as bare integers, status, currency, quote_number, converted_invoice_id, notes) get no explanation of format or default in either place, so the compensation is only partial.

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 specific verb and resource plus its key differentiator: "ONE call creates the whole document", listing exactly what is supplied (client_name + items). This implicitly and effectively distinguishes it from the sibling quote_item_create / quote_update path where lines are added separately.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives real routing guidance: client_name resolves or creates so no client_id lookup is needed, quote_share should be used "only when the user asks for one", and "NEXT: quote_convert" names the follow-on tool. It stops short of explicitly saying when to prefer quote_create over the incremental quote_item_create route, but the "ONE call" framing covers most of that.

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