Split bills and collect payments through PayNow (Singapore) from your AI. MCP server for SplitBill.
Scored across 3 tools
create_split, get_split, and list_splits target three clearly distinct lifecycle actions (create, retrieve one, enumerate many) with no overlap in purpose. An agent can trivially select the right tool based on intent.
All three tools follow a strict verb_noun snake_case pattern (create_split, get_split, list_splits), making the surface fully predictable.
Three tools is slightly thin but each earns its place and the domain (create a split, view it, list splits) is narrow enough to justify a minimal surface. No redundancy or filler tools.
Create and read paths are covered, but there is no update/delete, no way to close a split, edit amounts, or send reminders. These are notable gaps, though the create-and-share workflow means some are workaroundable.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
| 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. |
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.
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.
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.
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.
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.
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.
Return one split in full: who owes what, whether they have paid, the notes they left, and the share URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| admin_token | Yes | The t= value from the manage URL, or the whole manage URL. |
| Name | Required | Description |
|---|---|---|
| title | Yes | |
| total | Yes | |
| paynow | Yes | |
| people | Yes | |
| members | Yes | |
| collected | Yes | How much has come in. |
| share_urls | Yes | |
| status_url | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds useful context about what the response contains (balances, payment status, notes, share URLs) but says nothing about auth scope or error behavior beyond what the token implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; every clause names a distinct part of the returned payload. Nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 not be enumerated, yet the description lists them anyway – harmless and mildly redundant. Combined with full annotation coverage and a single well-documented parameter, an agent has what it needs; only explicit sibling routing is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With one parameter at 100% schema description coverage, the schema already documents that admin_token is the t= value or full manage URL. The description adds no additional meaning about the token's format, validity, or scope, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Return one split in full') and enumerates the payload contents, which cleanly distinguishes it from the sibling list_splits and create_split. It stops short of explicitly naming the siblings, so it doesn't reach a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Return one split' implies retrieval of a single known split, but there is no explicit when-to-use guidance, no statement of prerequisites, and no reference to list_splits or create_split as alternatives. Usage is left to inference from the name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the splits created with this connection, newest first, with how much has been collected, how many people are still to pay, and the read-only URL. Use this to find a split again when the organiser has lost the link.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many to return (default 10, max 50). |
| Name | Required | Description |
|---|---|---|
| note | No | |
| splits | Yes | Newest first. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds behavioral context by specifying the ordering ('newest first') and the exact return fields, which goes beyond the schema. It does not contradict the annotations and provides useful operational detail for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence front-loads the core purpose and output, and the second adds a practical usage hint. Every word earns its place, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a straightforward list operation with one optional parameter and an output schema present, so return values are already structured. The description covers purpose, ordering, output fields, and a typical use case, making it fully sufficient for an agent to select and invoke the tool correctly. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'limit' is fully documented in the schema with its type, default, and max value. Schema description coverage is 100%, so the description does not need to add further parameter details. The baseline of 3 is appropriate because the schema carries the entire parameter explanation and the description adds no additional semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Return'), a clear resource ('the splits created with this connection'), and enumerates the exact output fields (collected amount, number of payers remaining, read-only URL). It also frames a concrete use case ('find a split again when the organiser has lost the link'), which effectively distinguishes it from the sibling create_split and get_split tools without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear scenario for use ('when the organiser has lost the link'), which signals the appropriate context. However, it does not explicitly contrast with get_split (e.g., 'for a single split use get_split') or state when not to use this tool. The implicit guidance is strong but not fully explicit about alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
create_split1 field changedInput schema / properties / childrenAdded 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"
+}get_split2 fields changedOutput schema / properties / members / items / properties / adultsAdded value: +{
+ "description": "Adults in this household (default 1).",
+ "type": "number"
+}Output schema / properties / members / items / properties / childrenAdded value: +{
+ "description": "Children in this household. A child pays half an adult.",
+ "type": "number"
+}create_splitget_splitlist_splitsSplit bills from your AI: read bills & balances, create equal splits, request settlements.
MCP server for AI dialogue using various LLM models via AceDataCloud
MCP server for Sendbird — chat users, channels, members, and messages from your AI client.
Billing proxy for MCP servers. Adds Stripe and x402 crypto payments without writing billing code.
Add one secure layer between your agents and this server.