splitbill

Create a split bill

create_split

Create a payment page for a shared bill and return the manage URL plus the share URLs. The PayNow recipient is already saved with this connection — never ask the user for it. All you need is a total (total) or the receipt lines (items), plus the head count (people). Children can pay half: "4 adults and 3 kids" is people=7 with children=3. By default the user is treated as having paid up front: they count towards the head count but get no payment link (pass i_paid=false to turn that off). Paste a share URL into the group chat and everyone sees their own amount and a PayNow QR code.

Input Schema

TableJSON Schema

Name	Required	Description
`note`	No	A short note shown to the payers.
`items`	No	Receipt lines. Their sum becomes the total. Payers can see them.
`names`	No	Names of the others (only the ones you know). Empty slots get filled in by the payers themselves.
`title`	No	What the bill was for (e.g. Friday dinner). Defaults to the date and time.
`total`	No	The total. If items are given, their sum wins.
`custom`	No	Charge one person a different amount (e.g. someone who did not drink). The rest is re-split automatically.
`i_paid`	No	Did the user pay up front? (default: true) They count towards the head count but are not billed.
`people`	No	How many people share the bill, INCLUDING the user who paid up front.
`my_name`	No	What to call the user in the list (default: Me).
`children`	No	How many of people are children. A child pays half of what an adult pays. "4 adults and 3 kids" is people=7, children=3. When names are given, the LAST ones on the list are taken to be the children.
`rounding`	No	Rounding. ceil-all = round everyone up to whole dollars and let the user absorb the difference; one-extra = split exactly and let one person carry the remainder.

Output Schema

TableJSON Schema

Name	Required	Description
`total`	Yes	The total.
`paynow`	Yes	Who collects the money (saved with this connection).
`people`	Yes	How many share the bill, including whoever paid up front.
`summary`	Yes	A one-line summary to read out (how much each, how many people).
`warnings`	No	Anything worth mentioning about rounding or head count.
`next_step`	Yes	What to do next.
`manage_url`	Yes	Manage URL. FOR THE ORGANISER ONLY — it can change the split.
`share_urls`	Yes	Share URLs — one per amount.
`status_url`	No	Read-only URL. Safe to share.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 29, 2026

addedInput schema / properties / children

Added value: +{
+  "description": "How many of people are children. A child pays half of what an adult pays. \"4 adults and 3 kids\" is people=7, children=3. When names are given, the LAST ones on the list are taken to be the children.",
+  "type": "number"
+}

First observedSep 18, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations mark it as a non-destructive write, but the description adds crucial behavior: returns manage and share URLs, the PayNow recipient is pre-saved and must not be asked for, the user defaults to having paid up front with i_paid=false as opt-out, and children pay half. This goes well beyond the annotations without contradicting them.

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 first sentence front-loads the action and return values. Subsequent sentences cover the PayNow constraint, input combinations, defaults, and sharing outcome with no wasted filler. The length is appropriate for an 11-parameter tool.

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?

Annotations and the output schema already cover safety and return structure, and the description fully explains defaults, valid input combinations, and sharing behavior. Nothing critical for correctly invoking the tool is missing.

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 baseline is 3. The description adds cross-parameter semantics: total versus items precedence, people includes the user, children count with half-payment, i_paid default, and custom re-split behavior. It does not cover every parameter, but it meaningfully supplements the schema.

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 states a specific verb and resource: 'Create a payment page for a shared bill' and notes it returns the manage URL plus share URLs. Sibling tools get_split and list_splits are retrieval operations, so the creation purpose is clearly distinct.

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?

It explains inputs and defaults ('All you need is a total or the receipt lines, plus head count'), giving clear context. However, it never explicitly says when to use this versus get_split or list_splits, nor does it provide when-not conditions or alternative routing.

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

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