Simpler.Asia

invoice_create

ONE call creates the whole document: client_name + items [{description, quantity, unit_price}], each price as written ("5000.00"). It claims the next invoice number and writes every line; client_name finds or creates the client. A 'paid' birth needs items in the same call. 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 invoice as copy-ready text, shown with a Copy button where the host draws MCP Apps; if the user says they cannot see the invoice, give them that block word for word; share:true adds a client link, only when the user asks for one. NEXT: invoice_payment_record to record money-in.

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": "invoice_create"
  }
}

Input Schema

Name	Required	Description
`force`	No	Confirms 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).
`items`	No	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.
`notes`	No
`share`	No	Only when the user asks for a link: true also returns share_url (the client's link to view the invoice) and the full document in this same call. Where this environment has no public address, share_path and share_url_unavailable come back instead of share_url. Nothing is sent.
`status`	No
`paid_at`	No
`sent_at`	No
`currency`	No
`due_date`	No
`cash_sale`	No
`client_id`	No
`source_id`	No
`issue_date`	No
`line_items`	No	Alias of items.
`tax_scheme`	No	sg_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_name`	No	Client by NAME — resolves to an existing client or creates one (no client_id lookup needed).
`source_type`	No
`fx_rate_date`	No	The date the fx rate is for, YYYY-MM-DD. Send with fx_rate_to_sgd.
`tax_rate_bps`	No
`payment_terms`	No
`ready_to_send`	No	When the user wants to give the client the invoice (forward it, send it, get it ready): true issues it (status 'sent': it is owed from now and counts in receivables) and returns handoff, invoice_handoff's result: the client link, the PDF and the prepared message. Needs items. Nothing is sent: the user forwards it.
`fx_rate_to_sgd`	No	sg_gst invoices in a currency other than SGD: Singapore dollars per 1 unit of the invoice currency as a decimal string, up to 6 decimals ("1.3502"), from a source IRAS accepts (MAS, a local bank, Bloomberg, Reuters, Oanda) for the date of supply. Send with fx_rate_date. Or send fx_rate_to_sgd_ppm (1.3502 → 1350200).
`invoice_number`	No
`payment_method`	No
`fx_rate_to_sgd_ppm`	No
`prices_include_tax`	No	true = unit prices already include the tax (the tax is worked back out of each line). Default false. Needs a tax_scheme, except on a cash sale (cash_sale 1): its total is then the amount taken, with tax_rate_bps (or your default rate) worked out inside it, as the Quick Sale keypad records it.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 4, 2026

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

addedInput schema / properties / ready_to_send

Added value: +{
+  "description": "When the user wants to give the client the invoice (forward it, send it, get it ready): true issues it (status 'sent': it is owed from now and counts in receivables) and returns handoff, invoice_handoff's result: the client link, the PDF and the prepared message. Needs items. Nothing is sent: the user forwards it.",
+  "type": "boolean"
+}

First observedOct 23, 2026

TDQS

A3.6/5.0

Behavior4/5

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

With annotations only declaring the safe-mutation profile, the description adds real behavioral context: it claims the next invoice number, silently finds or creates the client from client_name, refuses certain tax_code/tax_scheme combinations, and emits a second content block that should be echoed verbatim if the user cannot see the invoice. Remaining gap: it never states what happens to a claimed invoice number on a failed or retried call, so duplicate-creation risk is only indirectly signalled.

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 core call shape and price convention are front-loaded in the first sentence, and each subsequent sentence addresses a distinct concern (numbering, tax, the copy-ready block, sharing, the follow-up tool). Some phrasing is idiosyncratic ('a paid birth') and the middle sentences pack several ideas together, but there is no filler.

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

Completeness3/5

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

For a 26-parameter mutation tool with no output schema, the description does cover the key behaviors and compensates partly for the missing return schema by describing the second content block and share outputs. It is still thin on the many date, currency, status and FX parameters, and never explains how 'done' looks on a plain success.

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?

With 26 parameters and only 38% schema description coverage, the description does useful reduction work by defining the core call as client_name + items and reinforcing the 'price as written' decimal-string convention. Beyond that it adds little the schema does not already say, and many parameters (due_date, issue_date, currency, cash_sale, source_id, payment_terms, payment_method, line_items alias) remain undocumented in both places.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence names a specific verb and resource ('ONE call creates the whole document') and immediately enumerates the minimal inputs (client_name + items), so an agent knows exactly what the tool produces. Sibling differentiation is only partial: it forward-routes to invoice_payment_record but never contrasts itself with quote_create or invoice_recurring_create, so the boundary with those is left implicit.

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

Usage Guidelines3/5

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

Conditional usage rules are given at the field level — share:true 'only when the user asks for one', a 'paid' birth requires items in the same call, and the next step is named (invoice_payment_record for money-in). However, there is no guidance on when to choose this tool over quote_create or invoice_recurring_create, which is the selection decision an agent most needs.

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

All Simpler.Asia tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?