Skip to main content
Glama

Split a bill

split_bill
Read-onlyIdempotent

Use this when the user wants to split a restaurant bill, check, receipt, takeout order, or any single bill between people: evenly or item by item (who had what), with tax, tip, service charge, coupons, delivery fees, or rounding up. Tax, tip, and service charge are shared in proportion to each person's pre-tax subtotal; every share is exact to the cent and the shares add up exactly to the total (largest-remainder rounding). Optional paid_by lists who owes the payer. Does not read receipt photos (pass the items as text), handle several payers or many bills (use settle_group_expenses), or convert currencies.

Input Schema

NameRequiredDescriptionDefault
itemsNoLine items from the receipt with who shared each one. Example: [{"description": "Pizza", "price": 24, "shared_by": ["Ana", "Ben"]}, {"description": "Salad", "price": 12, "shared_by": ["Chloe"]}]. Omit and use bill_amount to split one total evenly.
titleNoOptional label, e.g. "Dinner at Luigi's".
peopleNoEveryone splitting the bill, e.g. ["Ana", "Ben", "Chloe"]. Needed when some items are shared by everyone or when someone had nothing. Optional if every item lists shared_by.
paid_byNoWho paid the whole bill, e.g. "Ana". Adds a list of who owes them how much.
currencyNoISO 4217 code, e.g. USD, EUR, GBP, JPY. Defaults to USD. JPY has no decimals, KWD has three.
tip_baseNoWhat tip_percent applies to: pre_tax (default, subtotal after discounts) or post_tax (subtotal plus service charge plus tax).
tax_amountNoTax in money exactly as printed on the receipt, e.g. 7.38. Shared in proportion to each person's subtotal.
tip_amountNoTip in money, e.g. 25. Shared in proportion to each person's subtotal.
bill_amountNoUse instead of items to split one amount evenly, e.g. 120. It is the amount before any tax_percent or tip_percent you add here; if the bill already includes tax, leave tax out.
round_up_toNoRound each person's share up to a multiple of this amount, e.g. 1 for whole dollars or 5. The extra is shown separately.
tax_percentNoSales tax or VAT rate added on top of the item subtotal (after any discount), e.g. 8.875. Use tax_amount instead when the receipt shows the tax in money.
tip_percentNoTip rate, e.g. 18 or 20. Calculated on the pre-tax subtotal unless tip_base is post_tax.
people_countNoNumber of people when names are not given, e.g. 5. They are labelled Person 1 to Person 5.
discount_amountNoCoupon or deal on the whole bill in money, applied before tax, e.g. 15.
discount_percentNoCoupon or deal on the whole bill in percent, applied before tax, e.g. 10.
equal_fee_amountNoA flat fee split equally rather than by what people ordered, e.g. a 6.99 delivery fee or a cover charge.
service_charge_amountNoService charge in money, e.g. 9.75.
service_charge_percentNoService charge rate added by the restaurant, e.g. 12.5. Shared in proportion to each person's subtotal.

Output Schema

NameRequiredDescriptionDefault
kindYes
owesYes
checkYes
hintsYes
itemsYes
titleYes
labelsYes
peopleYes
totalsYes
displayYes
paid_byYes
currencyYes
settingsYes
warningsYes
minor_unitsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

The description adds substantial behavior beyond the annotations: tax, tip, and service charge are shared proportionally to pre-tax subtotal, shares are exact to the cent using largest-remainder rounding, and paid_by produces who-owes-whom output. It also discloses practical limitations such as no photo OCR and no currency conversion.

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 front-loaded with the primary use case and then layers in exclusions and behavioral notes. Despite covering a complex 18-parameter tool, every sentence carries actionable information.

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?

Given the rich input schema, existing output schema, and clear annotations, the description supplies the remaining high-value context an agent needs. It covers when to use it, key calculation behavior, and the main boundaries relative to alternatives.

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 even without extra parameter explanation. The description adds useful semantics around proportional sharing and exact cent rounding, though it does not discuss most of the 18 parameters directly.

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 uses a specific verb and resource, 'split ... bill', and defines scope as a single bill between people, including even or itemized splitting. It also distinguishes itself from the sibling tool settle_group_expenses for many bills or several payers.

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 explicitly states when to use the tool, including restaurant bills, receipts, takeout orders, and single bills. It also gives clear exclusions and alternatives: no receipt-photo reading, no multiple payers or many bills (use settle_group_expenses), and no currency conversion.

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