InvoiceGen

Calculate totals

calculate_totals

Read-onlyIdempotent

Compute subtotal, discount, tax and total for a list of line items (discount applied before tax, amounts rounded to 2 dp). Use for quick totals math without building an invoice. Do NOT use to produce an invoice document; use create_invoice.

Input Schema

TableJSON Schema

Name	Required	Description
`items`	Yes	Line items (at least one), each {description, quantity, unit_price}; line amount = quantity x unit_price.
`discount_pct`	No	Discount in percent of the subtotal, 0-100, e.g. 10 for 10% off. Default 0.
`tax_rate_pct`	No	Tax rate in percent, 0-100, applied after the discount, e.g. 18 for 18% GST. Default 0.

Output Schema

TableJSON Schema

Name	Required	Description
`tax`	Yes	Tax amount = (subtotal - discount) x tax_rate_pct / 100.
`total`	Yes	Final amount = subtotal - discount + tax.
`discount`	Yes	Discount amount = subtotal x discount_pct / 100.
`subtotal`	Yes	Sum of quantity x unit_price, rounded to 2 dp.

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedOct 10, 2026

changedInput schema / properties / discount_pct / description

Previous value: -"Discount rate as a percent, e.g. 10 for 10%"New value: +"Discount in percent of the subtotal, 0-100, e.g. 10 for 10% off. Default 0."

addedInput schema / properties / discount_pct / maximum
```
Added value: +100
```
addedInput schema / properties / discount_pct / minimum
```
Added value: +0
```

changedInput schema / properties / items / description

Previous value: -"List of items, each with name, quantity, and price"New value: +"Line items (at least one), each {description, quantity, unit_price}; line amount = quantity x unit_price."

addedInput schema / properties / items / items

Added value: +{
+  "properties": {
+    "description": {
+      "description": "What was sold or done, e.g. \"Logo design\" or \"Consulting hours\"",
+      "minLength": 1,
+      "type": "string"
+    },
+    "quantity": {
+      "description": "Quantity or hours, must be > 0, e.g. 10",
+      "exclusiveMinimum": 0,
+      "type": "number"
+    },
+    "unit_price": {
+      "description": "Price per unit in the invoice currency, >= 0, e.g. 50",
+      "minimum": 0,
+      "type": "number"
+    }
+  },
+  "required": [
+    "description",
+    "quantity",
+    "unit_price"
+  ],
+  "type": "object"
+}

addedInput schema / properties / items / minItems
```
Added value: +1
```

changedInput schema / properties / tax_rate_pct / description

Previous value: -"Tax rate as a percent, e.g. 8 for 8%"New value: +"Tax rate in percent, 0-100, applied after the discount, e.g. 18 for 18% GST. Default 0."

addedInput schema / properties / tax_rate_pct / maximum
```
Added value: +100
```
addedInput schema / properties / tax_rate_pct / minimum
```
Added value: +0
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "discount": {
+      "description": "Discount amount = subtotal x discount_pct / 100.",
+      "type": "number"
+    },
+    "subtotal": {
+      "description": "Sum of quantity x unit_price, rounded to 2 dp.",
+      "type": "number"
+    },
+    "tax": {
+      "description": "Tax amount = (subtotal - discount) x tax_rate_pct / 100.",
+      "type": "number"
+    },
+    "total": {
+      "description": "Final amount = subtotal - discount + tax.",
+      "type": "number"
+    }
+  },
+  "required": [
+    "subtotal",
+    "discount",
+    "tax",
+    "total"
+  ],
+  "type": "object"
+}

Changed1 schema field changedOct 10, 2026

changedOutput schema / (root)

Previous value: -{
-  "properties": {
-    "discount_amount": {
-      "description": "The total discount applied to the subtotal.",
-      "type": "number"
-    },
-    "subtotal": {
-      "description": "The sum of all item prices before any discounts or taxes.",
-      "type": "number"
-    },
-    "tax_amount": {
-      "description": "The total tax applied to the subtotal after discount.",
-      "type": "number"
-    },
-    "total": {
-      "description": "The final amount after applying discount and tax to the subtotal.",
-      "type": "number"
-    }
-  },
-  "required": [
-    "subtotal",
-    "discount_amount",
-    "tax_amount",
-    "total"
-  ],
-  "type": "object"
-}New value: +null

Changed4 schema fields changedOct 6, 2026

addedInput schema / properties / discount_pct / description

Added value: +"Discount rate as a percent, e.g. 10 for 10%"

addedInput schema / properties / items / description

Added value: +"List of items, each with name, quantity, and price"

addedInput schema / properties / tax_rate_pct / description
```
Added value: +"Tax rate as a percent, e.g. 8 for 8%"
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "discount_amount": {
+      "description": "The total discount applied to the subtotal.",
+      "type": "number"
+    },
+    "subtotal": {
+      "description": "The sum of all item prices before any discounts or taxes.",
+      "type": "number"
+    },
+    "tax_amount": {
+      "description": "The total tax applied to the subtotal after discount.",
+      "type": "number"
+    },
+    "total": {
+      "description": "The final amount after applying discount and tax to the subtotal.",
+      "type": "number"
+    }
+  },
+  "required": [
+    "subtotal",
+    "discount_amount",
+    "tax_amount",
+    "total"
+  ],
+  "type": "object"
+}

First observedOct 1, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower; the description earns credit by disclosing the computation semantics the annotations cannot: discount is applied before tax and amounts are rounded to 2 dp. It does not cover edge behavior (e.g., empty or zero-value results, currency selection), so it falls short of a 5.

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?

Two sentences, zero filler. The core computation and its ordering rule come first, and the routing exclusion follows immediately after.

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?

An output schema exists, so return values need no explanation, and the schema fully documents the three parameters. With computation order, rounding, and the create_invoice boundary all stated, an agent has everything needed to call this correctly.

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 description coverage is 100%, so the baseline is 3 and the schema already documents units, ranges and defaults. The description adds meaning beyond the schema by fixing the ordering of discount_pct and tax_rate_pct ('discount applied before tax') and the rounding rule, which the field descriptions alone do not state.

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 names a precise verb and the exact outputs ('subtotal, discount, tax and total') over a defined input ('list of line items'), and explicitly distinguishes itself from the sibling create_invoice. An agent can route between the two tools without opening either schema.

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?

It states the positive case ('quick totals math without building an invoice') and an explicit exclusion with a named alternative ('Do NOT use to produce an invoice document; use create_invoice'). This is textbook when/when-not/alternative guidance.

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

All InvoiceGen 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.

Calculate totals

Input Schema

Output Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources