CourtSplit
Server Details
Split court costs, settle up and plan fair rotations for pickup games. Free.
- Status
- Healthy
- Uptime
- 99.9% over 22 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Server Listing
- Sahadeva
TDQS
Scored across 4 tools
rotation_plan is clearly distinct (court scheduling), and the three cost tools have documented boundaries (settle_up for 'who owes whom' with prepaid amounts, split_costs for a single booking, split_series for recurring sessions). There is mild overlap since split_costs also produces settle-up payments, but the descriptions steer selection well.
All names use snake_case and are readable, with three following a verb_noun pattern (settle_up, split_costs, split_series). rotation_plan is a minor deviation in ordering (noun_verb) but still fits the overall convention.
Four tools is a tight, well-scoped set for pickup-game logistics covering both rotation planning and cost splitting. It is on the lean side but each tool earns its place with no redundancy.
Covers the core lifecycle: rotation planning, single-event splitting, recurring-series splitting, and settlement. Roster/player management and payment recording are implicit inputs rather than tools, which is a minor gap but not a dead end.
Available Tools
4 toolsrotation_planRotation planARead-onlyIdempotentInspect
Plan fair player rotations for pickup games: who plays on each court every round and who sits out, balancing games played across the roster. Use when more players show up than court spots. Does not split money; for costs use split_costs or split_series.
| Name | Required | Description | Default |
|---|---|---|---|
| courts | No | Number of courts in use at once (default 1) | |
| rounds | Yes | Number of rounds to schedule, 1-50 | |
| players | Yes | Unique roster names, at least capacity x courts of them, e.g. ["Asha","Dev","Mira","Sam","Lee","Kai"] | |
| capacity | Yes | Players per court: 2 for singles, 4 for doubles, 10 for 5v5 basketball |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | Yes | Whether the rotation is perfectly balanced |
| format | Yes | Format label with players per side and courts, e.g. '2v2 on 2 court(s)' for capacity 4 (doubles), '1v1' for capacity 2; odd capacity shows 'N player(s) per court' |
| rounds | Yes | Number of rounds scheduled |
| fairness | Yes | Games-played balance across the roster |
| schedule | Yes | One entry per round |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so the safety profile is covered structurally. The description adds genuinely useful behavioral intent beyond that: the fairness objective (balancing games played) and that the plan covers both court assignments and sit-outs. It does not discuss determinism of tie-breaking or how many rounds constrain output, but with annotations and an output schema present the bar is lower.
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?
Three tight sentences with zero filler: purpose and output first, then the usage trigger, then the explicit boundary against sibling tools. Each sentence earns its place and the most decision-relevant information is front-loaded.
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?
With annotations covering the safety profile and an output schema covering return shape, the description only needs to convey purpose, trigger, and boundaries — all of which it does. Minor gap: it does not hint that the roster must be at least capacity × courts (a real failure mode), though that constraint is stated in the schema.
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% and every parameter is documented in the schema itself (courts default, rounds 1-50, capacity meaning for singles/doubles/5v5, players roster). The description adds no syntax or format detail beyond that, so the baseline 3 for a fully documented schema is correct.
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 ('Plan fair player rotations for pickup games') and spells out the concrete output semantics: who plays on each court every round, who sits out, and that games played are balanced across the roster. It also explicitly distinguishes itself from the money-oriented siblings by declaring 'Does not split money,' so an agent can separate it from split_costs/split_series without opening any schema.
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?
Gives an explicit trigger condition ('Use when more players show up than court spots') and names the correct alternatives for the adjacent money domain ('for costs use split_costs or split_series'). That is direct when-to-use plus when-to-use-something-else routing, leaving little to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
settle_upSettle upARead-onlyIdempotentInspect
Given a shared total and who already paid what, compute each player's balance and the minimal set of payments (who pays whom, how much) to settle everyone. Use when the question is 'who owes whom'. For recurring sessions with different attendees use split_series.
| Name | Required | Description | Default |
|---|---|---|---|
| shares | No | Optional positive relative weights, one per participant in the same order, e.g. [2,1,1]; omit for an equal split | |
| currency | No | Currency code used only for display, e.g. USD, EUR, GBP (default USD) | |
| total_cost | Yes | Total court/venue cost in currency units, e.g. 96 for $96.00 | |
| participants | Yes | At least 2 players with unique names; include 'paid' for anyone who already paid, e.g. [{"name":"Asha","paid":96},{"name":"Dev"}] |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | Yes | Plain-language summary of the settlement |
| balances | Yes | Per-player paid, owed share and net balance |
| currency | Yes | Currency code used for display |
| transfers | Yes | Minimal list of payments that settles the group |
| total_cost | Yes | Total shared cost, rounded to cents |
| transfer_count | Yes | Number of payments in transfers |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is fully covered structurally. The description adds only that the output is a minimal payment set, which is also implied by the output schema, so incremental behavioral disclosure is modest.
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?
Two sentences: the core computation first, then the routing rule. No filler, no repetition of the schema, and the most decision-relevant content is front-loaded.
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 described; annotations carry the safety profile; the schema fully documents all four parameters. Nothing an agent needs to select or call this 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 the baseline is 3; the schema already documents total_cost, participants, paid, shares, and currency with examples. The description restates the total/paid concept but adds no format or edge-case detail beyond 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?
States a specific computation: given a total and prior payments, compute balances and the minimal settlement payments. That verb+resource phrasing makes it immediately distinguishable from split_costs/split_series, which partition a cost rather than net out balances.
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?
Explicitly gives the trigger ('Use when the question is "who owes whom"') and routes one alternative (split_series for recurring sessions with different attendees). It does not differentiate against split_costs or rotation_plan, which are plausible near-neighbors, so it falls short of a full when/when-not map.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
split_costsSplit costsARead-onlyIdempotentInspect
Split one total court or venue cost across players, equally or by relative weights, and show each player's share plus the fewest payments to settle up. Use for a single booking or event. For recurring sessions with changing attendance use split_series.
| Name | Required | Description | Default |
|---|---|---|---|
| shares | No | Optional positive relative weights, one per participant in the same order, e.g. [2,1,1]; omit for an equal split | |
| currency | No | Currency code used only for display, e.g. USD, EUR, GBP (default USD) | |
| total_cost | Yes | Total court/venue cost in currency units, e.g. 96 for $96.00 | |
| participants | Yes | At least 2 players with unique names; include 'paid' for anyone who already paid, e.g. [{"name":"Asha","paid":96},{"name":"Dev"}] |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | Yes | Plain-language summary of the split |
| split | Yes | Whether the split was equal or by relative weights |
| currency | Yes | Currency code used for display |
| per_head | Yes | Equal share per player, or null for a weighted split |
| settle_up | Yes | Fewest payments that settle everyone (empty if nobody paid yet or all square) |
| total_cost | Yes | Total cost that was split, rounded to cents |
| participants | Yes | Per-player paid, owed share and balance |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds behavioral value beyond that by disclosing what the computation produces — per-player shares and a minimized set of settlement payments — which is not implied by the annotations. It stops short of any detail on ordering, rounding, or error behavior when weights do not match participants.
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?
Three tight sentences: the action and its output first, then scope, then the alternative. Every sentence earns its place and the routing information is front-loaded.
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?
For a pure computation tool with a complete input schema and an output schema, the description supplies everything an agent still needs: what it computes, what it returns conceptually, and when to pick it over split_series. Nothing required for correct invocation 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 the schema already documents total_cost, participants, paid, shares, and currency with examples. The description only echoes the equal-vs-weights distinction, adding no syntax, ordering, or default detail beyond the schema. Baseline 3 is correct when the schema carries the parameter burden.
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 (split) and resource (one total court/venue cost) plus the two modes (equally or by relative weights) and the output (each share plus fewest settling payments). It also names the sibling split_series as the thing it is not, so an agent can distinguish it without opening a schema.
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?
Explicit scope statement — 'Use for a single booking or event' — paired with an explicit exclusion and alternative: 'For recurring sessions with changing attendance use split_series.' Both the when and the when-not are stated, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
split_seriesSplit seriesARead-onlyIdempotentInspect
Split a series of recurring sessions where attendance varies: each session's cost is shared only by that session's attendees, then payments already made are netted into balances and minimal settle-up transfers. Use for weekly games or leagues. For a single event use split_costs.
| Name | Required | Description | Default |
|---|---|---|---|
| players | No | Optional full roster, so players who missed every session still appear with a zero balance | |
| currency | No | Currency code used only for display, e.g. USD (default USD) | |
| payments | No | Optional list of who already paid what across the series, e.g. [{"name":"Asha","paid":120}] | |
| sessions | Yes | Sessions in order, each with its cost and the names who attended |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | Yes | Explanation of how the series was split |
| players | Yes | Per-player paid, owed, balance and sessions attended |
| currency | Yes | Currency code used for display |
| sessions | Yes | Per-session cost breakdown |
| transfers | Yes | Fewest payments that settle everyone |
| total_cost | Yes | Sum of all session costs |
| session_count | Yes | Number of sessions processed |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a read-only, idempotent, non-destructive computation, so safety is covered. The description goes beyond them by disclosing the actual computation model: per-session cost sharing by that session's attendees, netting of payments already made, and minimal settle-up transfers, which tells the agent what the numbers mean. It stops short of stating rounding or edge-case handling.
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?
Three sentences, all load-bearing: mechanism first, typical use second, sibling routing last. No restatement of the tool name or filler.
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?
With an output schema present and annotations covering the safety profile, the description only needs to convey intent and routing, which it does. Minor gaps remain around rounding of indivisible shares and degenerate inputs (e.g. a session with attendees absent from the roster), but nothing an agent needs to invoke it correctly 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 coverage is 100%, so the baseline is 3, but the description adds real meaning to two parameters: it clarifies that 'attendees' determines who bears each session's cost and that 'payments' are netted against those shares rather than subtracted per session. That linkage is not expressed in the schema descriptions.
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 (split) and resource (a series of recurring sessions) and specifies the scope that makes it distinct: per-session attendee sharing rather than whole-series pooling. It also names the sibling it is not (split_costs) for the single-event case, so an agent can route 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives both a positive trigger ('Use for weekly games or leagues') and an explicit alternative for the adjacent case ('For a single event use split_costs'). The only unaddressed siblings are settle_up and rotation_plan, which are not the near-miss here.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- Changed
rotation_plan1 field changed- changed
Output schema / properties / format / descriptionPrevious value: -"Format label built from capacity and courts, e.g. '4v4 on 2 court(s)'"New value: +"Format label with players per side and courts, e.g. '2v2 on 2 court(s)' for capacity 4 (doubles), '1v1' for capacity 2; odd capacity shows 'N player(s) per court'"
4 tool updates
- Changed
rotation_plan13 fields changed- changed
Input schema / properties / capacity / descriptionPrevious value: -"Players per court (2 singles, 4 doubles)"New value: +"Players per court: 2 for singles, 4 for doubles, 10 for 5v5 basketball" - added
Input schema / properties / capacity / minimumAdded value: +1 - changed
Input schema / properties / capacity / typePrevious value: -"number"New value: +"integer" - changed
Input schema / properties / courts / descriptionPrevious value: -"Number of courts available for the rotation plan"New value: +"Number of courts in use at once (default 1)" - added
Input schema / properties / courts / minimumAdded value: +1 - changed
Input schema / properties / courts / typePrevious value: -"number"New value: +"integer" - changed
Input schema / properties / players / descriptionPrevious value: -"Roster names"New value: +"Unique roster names, at least capacity x courts of them, e.g. [\"Asha\",\"Dev\",\"Mira\",\"Sam\",\"Lee\",\"Kai\"]" - added
Input schema / properties / players / minItemsAdded value: +2 - changed
Input schema / properties / rounds / descriptionPrevious value: -"Number of rounds to be scheduled in the rotation plan"New value: +"Number of rounds to schedule, 1-50" - added
Input schema / properties / rounds / maximumAdded value: +50 - added
Input schema / properties / rounds / minimumAdded value: +1 - changed
Input schema / properties / rounds / typePrevious value: -"number"New value: +"integer" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "fairness": { + "description": "Games-played balance across the roster", + "properties": { + "max_games": { + "description": "Most games any player gets", + "type": "integer" + }, + "min_games": { + "description": "Fewest games any player gets", + "type": "integer" + }, + "spread": { + "description": "max_games minus min_games", + "type": "integer" + } + }, + "required": [ + "min_games", + "max_games", + "spread" + ], + "type": "object" + }, + "format": { + "description": "Format label built from capacity and courts, e.g. '4v4 on 2 court(s)'", + "type": "string" + }, + "note": { + "description": "Whether the rotation is perfectly balanced", + "type": "string" + }, + "rounds": { + "description": "Number of rounds scheduled", + "type": "integer" + }, + "schedule": { + "description": "One entry per round", + "items": { + "properties": { + "courts": { + "description": "Players on each court this round", + "items": { + "items": { + "type": "string" + }, + "type": "array" + }, + "type": "array" + }, + "round": { + "description": "Round number starting at 1", + "type": "integer" + }, + "sitting": { + "description": "Players sitting out this round", + "items": { + "type": "string" + }, + "type": "array" + } + }, + "required": [ + "round", + "courts", + "sitting" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "format", + "rounds", + "fairness", + "schedule", + "note" + ], + "type": "object" +}
- Changed
settle_up11 fields changed- changed
Input schema / properties / currency / descriptionPrevious value: -"Currency code, as a string, ISO 4217"New value: +"Currency code used only for display, e.g. USD, EUR, GBP (default USD)" - changed
Input schema / properties / participants / descriptionPrevious value: -"List of participant names, as strings in an array"New value: +"At least 2 players with unique names; include 'paid' for anyone who already paid, e.g. [{\"name\":\"Asha\",\"paid\":96},{\"name\":\"Dev\"}]" - added
Input schema / properties / participants / items / properties / name / descriptionAdded value: +"Player name, unique within the list, e.g. 'Asha'" - added
Input schema / properties / participants / items / properties / paid / descriptionAdded value: +"Amount this player already paid toward the total, in currency units (default 0)" - added
Input schema / properties / participants / items / properties / paid / minimumAdded value: +0 - added
Input schema / properties / participants / minItemsAdded value: +2 - changed
Input schema / properties / shares / descriptionPrevious value: -"Each participant's share of the total cost, as numbers in an array"New value: +"Optional positive relative weights, one per participant in the same order, e.g. [2,1,1]; omit for an equal split" - added
Input schema / properties / shares / items / exclusiveMinimumAdded value: +0 - changed
Input schema / properties / total_cost / descriptionPrevious value: -"Total amount spent, as a number"New value: +"Total court/venue cost in currency units, e.g. 96 for $96.00" - added
Input schema / properties / total_cost / exclusiveMinimumAdded value: +0 - changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "balances": { + "description": "Per-player paid, owed share and net balance", + "items": { + "properties": { + "balance": { + "description": "paid minus owed; positive = gets money back, negative = owes money", + "type": "number" + }, + "name": { + "description": "Player name", + "type": "string" + }, + "owed": { + "description": "This player's fair share of the cost", + "type": "number" + }, + "paid": { + "description": "Amount this player paid", + "type": "number" + } + }, + "required": [ + "name", + "paid", + "owed", + "balance" + ], + "type": "object" + }, + "type": "array" + }, + "currency": { + "description": "Currency code used for display", + "type": "string" + }, + "note": { + "description": "Plain-language summary of the settlement", + "type": "string" + }, + "total_cost": { + "description": "Total shared cost, rounded to cents", + "type": "number" + }, + "transfer_count": { + "description": "Number of payments in transfers", + "type": "integer" + }, + "transfers": { + "description": "Minimal list of payments that settles the group", + "items": { + "properties": { + "amount": { + "description": "Amount to transfer, rounded to cents", + "type": "number" + }, + "from": { + "description": "Player who pays", + "type": "string" + }, + "to": { + "description": "Player who receives", + "type": "string" + } + }, + "required": [ + "from", + "to", + "amount" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "currency", + "total_cost", + "balances", + "transfers", + "transfer_count", + "note" + ], + "type": "object" +}
- Changed
split_costs11 fields changed- changed
Input schema / properties / currency / descriptionPrevious value: -"Currency code for display, default USD"New value: +"Currency code used only for display, e.g. USD, EUR, GBP (default USD)" - changed
Input schema / properties / participants / descriptionPrevious value: -"Players in the split"New value: +"At least 2 players with unique names; include 'paid' for anyone who already paid, e.g. [{\"name\":\"Asha\",\"paid\":96},{\"name\":\"Dev\"}]" - added
Input schema / properties / participants / items / properties / name / descriptionAdded value: +"Player name, unique within the list, e.g. 'Asha'" - added
Input schema / properties / participants / items / properties / paid / descriptionAdded value: +"Amount this player already paid toward the total, in currency units (default 0)" - added
Input schema / properties / participants / items / properties / paid / minimumAdded value: +0 - added
Input schema / properties / participants / minItemsAdded value: +2 - changed
Input schema / properties / shares / descriptionPrevious value: -"Optional relative weights, one per participant"New value: +"Optional positive relative weights, one per participant in the same order, e.g. [2,1,1]; omit for an equal split" - added
Input schema / properties / shares / items / exclusiveMinimumAdded value: +0 - changed
Input schema / properties / total_cost / descriptionPrevious value: -"Total court/venue cost"New value: +"Total court/venue cost in currency units, e.g. 96 for $96.00" - added
Input schema / properties / total_cost / exclusiveMinimumAdded value: +0 - changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "currency": { + "description": "Currency code used for display", + "type": "string" + }, + "note": { + "description": "Plain-language summary of the split", + "type": "string" + }, + "participants": { + "description": "Per-player paid, owed share and balance", + "items": { + "properties": { + "balance": { + "description": "paid minus owed; positive = gets money back, negative = owes money", + "type": "number" + }, + "name": { + "description": "Player name", + "type": "string" + }, + "owed": { + "description": "This player's fair share of the cost", + "type": "number" + }, + "paid": { + "description": "Amount this player paid", + "type": "number" + } + }, + "required": [ + "name", + "paid", + "owed", + "balance" + ], + "type": "object" + }, + "type": "array" + }, + "per_head": { + "description": "Equal share per player, or null for a weighted split", + "type": [ + "number", + "null" + ] + }, + "settle_up": { + "description": "Fewest payments that settle everyone (empty if nobody paid yet or all square)", + "items": { + "properties": { + "amount": { + "description": "Amount to transfer, rounded to cents", + "type": "number" + }, + "from": { + "description": "Player who pays", + "type": "string" + }, + "to": { + "description": "Player who receives", + "type": "string" + } + }, + "required": [ + "from", + "to", + "amount" + ], + "type": "object" + }, + "type": "array" + }, + "split": { + "description": "Whether the split was equal or by relative weights", + "enum": [ + "equal", + "weighted" + ], + "type": "string" + }, + "total_cost": { + "description": "Total cost that was split, rounded to cents", + "type": "number" + } + }, + "required": [ + "currency", + "total_cost", + "split", + "per_head", + "participants", + "settle_up", + "note" + ], + "type": "object" +}
- Changed
split_series15 fields changed- changed
Input schema / properties / currency / descriptionPrevious value: -"Currency code (ISO 4217) for all transactions"New value: +"Currency code used only for display, e.g. USD (default USD)" - changed
Input schema / properties / payments / descriptionPrevious value: -"Array of payment objects, each with payer, payee, and amount"New value: +"Optional list of who already paid what across the series, e.g. [{\"name\":\"Asha\",\"paid\":120}]" - added
Input schema / properties / payments / items / properties / name / descriptionAdded value: +"Player who paid, e.g. the person who fronted court fees" - added
Input schema / properties / payments / items / properties / paid / descriptionAdded value: +"Total amount this player has paid across the series, in currency units" - added
Input schema / properties / payments / items / properties / paid / minimumAdded value: +0 - changed
Input schema / properties / payments / items / requiredPrevious value: -[ - "name" -]New value: +[ + "name", + "paid" +] - changed
Input schema / properties / players / descriptionPrevious value: -"Array of player names or IDs"New value: +"Optional full roster, so players who missed every session still appear with a zero balance" - changed
Input schema / properties / sessions / descriptionPrevious value: -"Array of session objects, each with date, attendees, and cost"New value: +"Sessions in order, each with its cost and the names who attended" - added
Input schema / properties / sessions / items / properties / attendees / descriptionAdded value: +"Unique names of players present at this session" - added
Input schema / properties / sessions / items / properties / attendees / minItemsAdded value: +1 - added
Input schema / properties / sessions / items / properties / cost / descriptionAdded value: +"Cost of this session in currency units, e.g. 60" - added
Input schema / properties / sessions / items / properties / cost / exclusiveMinimumAdded value: +0 - added
Input schema / properties / sessions / items / properties / label / descriptionAdded value: +"Optional session label, e.g. 'Tue 7pm' (default 'session N')" - added
Input schema / properties / sessions / minItemsAdded value: +1 - changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "currency": { + "description": "Currency code used for display", + "type": "string" + }, + "note": { + "description": "Explanation of how the series was split", + "type": "string" + }, + "players": { + "description": "Per-player paid, owed, balance and sessions attended", + "items": { + "properties": { + "balance": { + "description": "paid minus owed; positive = gets money back, negative = owes money", + "type": "number" + }, + "name": { + "description": "Player name", + "type": "string" + }, + "owed": { + "description": "This player's fair share of the cost", + "type": "number" + }, + "paid": { + "description": "Amount this player paid", + "type": "number" + }, + "sessions_played": { + "description": "Number of sessions this player attended", + "type": "integer" + } + }, + "required": [ + "name", + "paid", + "owed", + "balance", + "sessions_played" + ], + "type": "object" + }, + "type": "array" + }, + "session_count": { + "description": "Number of sessions processed", + "type": "integer" + }, + "sessions": { + "description": "Per-session cost breakdown", + "items": { + "properties": { + "attendees": { + "description": "Number of attendees", + "type": "integer" + }, + "cost": { + "description": "Session cost", + "type": "number" + }, + "label": { + "description": "Session label", + "type": "string" + }, + "per_head": { + "description": "Cost per attendee for this session", + "type": "number" + } + }, + "required": [ + "label", + "cost", + "attendees", + "per_head" + ], + "type": "object" + }, + "type": "array" + }, + "total_cost": { + "description": "Sum of all session costs", + "type": "number" + }, + "transfers": { + "description": "Fewest payments that settle everyone", + "items": { + "properties": { + "amount": { + "description": "Amount to transfer, rounded to cents", + "type": "number" + }, + "from": { + "description": "Player who pays", + "type": "string" + }, + "to": { + "description": "Player who receives", + "type": "string" + } + }, + "required": [ + "from", + "to", + "amount" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "currency", + "total_cost", + "session_count", + "sessions", + "players", + "transfers", + "note" + ], + "type": "object" +}
4 tool updates
- Changed
rotation_plan1 field changed- changed
Output schema / (root)Previous value: -{ - "properties": { - "balance": { - "description": "Balance of games played by each player", - "properties": { - "players": { - "description": "List of players with their respective games played", - "items": { - "properties": { - "gamesPlayed": { - "description": "The number of games the player has played", - "type": "number" - }, - "name": { - "description": "The player's name", - "type": "string" - } - }, - "required": [ - "name", - "gamesPlayed" - ], - "type": "object" - }, - "type": "array" - } - }, - "required": [ - "players" - ], - "type": "object" - }, - "rounds": { - "description": "List of rounds with players assigned to each court", - "items": { - "properties": { - "courts": { - "description": "List of courts with players assigned to each", - "items": { - "properties": { - "courtNumber": { - "description": "The court number", - "type": "number" - }, - "players": { - "description": "List of players assigned to this court", - "items": { - "type": "string" - }, - "type": "array" - } - }, - "required": [ - "courtNumber", - "players" - ], - "type": "object" - }, - "type": "array" - }, - "roundNumber": { - "description": "The round number", - "type": "number" - } - }, - "required": [ - "roundNumber", - "courts" - ], - "type": "object" - }, - "type": "array" - } - }, - "required": [ - "rounds", - "balance" - ], - "type": "object" -}New value: +null
- Changed
settle_up1 field changed- changed
Output schema / (root)Previous value: -{ - "properties": { - "balances": { - "description": "The net balance for each participant after settling up.", - "items": { - "properties": { - "balance": { - "description": "The net balance for the participant.", - "type": "number" - }, - "name": { - "description": "The name of the participant.", - "type": "string" - } - }, - "required": [ - "name", - "balance" - ], - "type": "object" - }, - "type": "array" - }, - "transactions": { - "description": "The minimal set of transactions to settle up all balances.", - "items": { - "properties": { - "amount": { - "description": "The amount being transferred.", - "type": "number" - }, - "from": { - "description": "The name of the participant paying.", - "type": "string" - }, - "to": { - "description": "The name of the participant receiving.", - "type": "string" - } - }, - "required": [ - "from", - "to", - "amount" - ], - "type": "object" - }, - "type": "array" - } - }, - "required": [ - "balances", - "transactions" - ], - "type": "object" -}New value: +null
- Changed
split_costs1 field changed- changed
Output schema / (root)Previous value: -{ - "properties": { - "currency": { - "description": "The currency code used for display.", - "type": "string" - }, - "individual_costs": { - "description": "The cost owed by each participant.", - "items": { - "properties": { - "amount": { - "description": "The amount each participant owes.", - "type": "number" - }, - "name": { - "description": "The name of the participant.", - "type": "string" - } - }, - "required": [ - "name", - "amount" - ], - "type": "object" - }, - "type": "array" - }, - "settlements": { - "description": "The list of settle-up payments to balance the costs.", - "items": { - "properties": { - "amount": { - "description": "The amount to be paid.", - "type": "number" - }, - "payee": { - "description": "The name of the person receiving the payment.", - "type": "string" - }, - "payer": { - "description": "The name of the person making the payment.", - "type": "string" - } - }, - "required": [ - "payer", - "payee", - "amount" - ], - "type": "object" - }, - "type": "array" - }, - "total_cost": { - "description": "The total cost that was split.", - "type": "number" - } - }, - "required": [ - "total_cost", - "currency", - "settlements", - "individual_costs" - ], - "type": "object" -}New value: +null
- Changed
split_series1 field changed- changed
Output schema / (root)Previous value: -{ - "properties": { - "individualOwed": { - "additionalProperties": { - "type": "number" - }, - "description": "Amount each player owes after all settlements.", - "type": "object" - }, - "individualPaid": { - "additionalProperties": { - "type": "number" - }, - "description": "Amount each player has paid.", - "type": "object" - }, - "settlements": { - "description": "List of individual settlements between players.", - "items": { - "properties": { - "amount": { - "description": "The amount of money to be transferred from 'from' to 'to'.", - "type": "number" - }, - "currency": { - "description": "The currency in which the amount is specified.", - "type": "string" - }, - "from": { - "description": "The name of the player who owes money.", - "type": "string" - }, - "to": { - "description": "The name of the player who is owed money.", - "type": "string" - } - }, - "required": [ - "from", - "to", - "amount", - "currency" - ], - "type": "object" - }, - "type": "array" - }, - "summary": { - "description": "Summary of the total amounts owed and paid.", - "properties": { - "totalCost": { - "description": "The total cost of all sessions.", - "type": "number" - }, - "totalOwed": { - "description": "The total amount still owed after payments.", - "type": "number" - }, - "totalPaid": { - "description": "The total amount paid by all players.", - "type": "number" - } - }, - "required": [ - "totalCost", - "totalPaid", - "totalOwed" - ], - "type": "object" - } - }, - "required": [ - "summary", - "settlements", - "individualOwed", - "individualPaid" - ], - "type": "object" -}New value: +null
3 tool updates
- Changed
rotation_plan2 fields changed- added
Input schema / properties / courts / descriptionAdded value: +"Number of courts available for the rotation plan" - added
Input schema / properties / rounds / descriptionAdded value: +"Number of rounds to be scheduled in the rotation plan"
- Changed
settle_up4 fields changed- added
Input schema / properties / currency / descriptionAdded value: +"Currency code, as a string, ISO 4217" - added
Input schema / properties / participants / descriptionAdded value: +"List of participant names, as strings in an array" - added
Input schema / properties / shares / descriptionAdded value: +"Each participant's share of the total cost, as numbers in an array" - added
Input schema / properties / total_cost / descriptionAdded value: +"Total amount spent, as a number"
- Changed
split_series4 fields changed- added
Input schema / properties / currency / descriptionAdded value: +"Currency code (ISO 4217) for all transactions" - added
Input schema / properties / payments / descriptionAdded value: +"Array of payment objects, each with payer, payee, and amount" - added
Input schema / properties / players / descriptionAdded value: +"Array of player names or IDs" - added
Input schema / properties / sessions / descriptionAdded value: +"Array of session objects, each with date, attendees, and cost"
4 tool updates
- Changed
rotation_plan1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "balance": { + "description": "Balance of games played by each player", + "properties": { + "players": { + "description": "List of players with their respective games played", + "items": { + "properties": { + "gamesPlayed": { + "description": "The number of games the player has played", + "type": "number" + }, + "name": { + "description": "The player's name", + "type": "string" + } + }, + "required": [ + "name", + "gamesPlayed" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "players" + ], + "type": "object" + }, + "rounds": { + "description": "List of rounds with players assigned to each court", + "items": { + "properties": { + "courts": { + "description": "List of courts with players assigned to each", + "items": { + "properties": { + "courtNumber": { + "description": "The court number", + "type": "number" + }, + "players": { + "description": "List of players assigned to this court", + "items": { + "type": "string" + }, + "type": "array" + } + }, + "required": [ + "courtNumber", + "players" + ], + "type": "object" + }, + "type": "array" + }, + "roundNumber": { + "description": "The round number", + "type": "number" + } + }, + "required": [ + "roundNumber", + "courts" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "rounds", + "balance" + ], + "type": "object" +}
- Changed
settle_up1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "balances": { + "description": "The net balance for each participant after settling up.", + "items": { + "properties": { + "balance": { + "description": "The net balance for the participant.", + "type": "number" + }, + "name": { + "description": "The name of the participant.", + "type": "string" + } + }, + "required": [ + "name", + "balance" + ], + "type": "object" + }, + "type": "array" + }, + "transactions": { + "description": "The minimal set of transactions to settle up all balances.", + "items": { + "properties": { + "amount": { + "description": "The amount being transferred.", + "type": "number" + }, + "from": { + "description": "The name of the participant paying.", + "type": "string" + }, + "to": { + "description": "The name of the participant receiving.", + "type": "string" + } + }, + "required": [ + "from", + "to", + "amount" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "balances", + "transactions" + ], + "type": "object" +}
- Changed
split_costs1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "currency": { + "description": "The currency code used for display.", + "type": "string" + }, + "individual_costs": { + "description": "The cost owed by each participant.", + "items": { + "properties": { + "amount": { + "description": "The amount each participant owes.", + "type": "number" + }, + "name": { + "description": "The name of the participant.", + "type": "string" + } + }, + "required": [ + "name", + "amount" + ], + "type": "object" + }, + "type": "array" + }, + "settlements": { + "description": "The list of settle-up payments to balance the costs.", + "items": { + "properties": { + "amount": { + "description": "The amount to be paid.", + "type": "number" + }, + "payee": { + "description": "The name of the person receiving the payment.", + "type": "string" + }, + "payer": { + "description": "The name of the person making the payment.", + "type": "string" + } + }, + "required": [ + "payer", + "payee", + "amount" + ], + "type": "object" + }, + "type": "array" + }, + "total_cost": { + "description": "The total cost that was split.", + "type": "number" + } + }, + "required": [ + "total_cost", + "currency", + "settlements", + "individual_costs" + ], + "type": "object" +}
- Changed
split_series1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "individualOwed": { + "additionalProperties": { + "type": "number" + }, + "description": "Amount each player owes after all settlements.", + "type": "object" + }, + "individualPaid": { + "additionalProperties": { + "type": "number" + }, + "description": "Amount each player has paid.", + "type": "object" + }, + "settlements": { + "description": "List of individual settlements between players.", + "items": { + "properties": { + "amount": { + "description": "The amount of money to be transferred from 'from' to 'to'.", + "type": "number" + }, + "currency": { + "description": "The currency in which the amount is specified.", + "type": "string" + }, + "from": { + "description": "The name of the player who owes money.", + "type": "string" + }, + "to": { + "description": "The name of the player who is owed money.", + "type": "string" + } + }, + "required": [ + "from", + "to", + "amount", + "currency" + ], + "type": "object" + }, + "type": "array" + }, + "summary": { + "description": "Summary of the total amounts owed and paid.", + "properties": { + "totalCost": { + "description": "The total cost of all sessions.", + "type": "number" + }, + "totalOwed": { + "description": "The total amount still owed after payments.", + "type": "number" + }, + "totalPaid": { + "description": "The total amount paid by all players.", + "type": "number" + } + }, + "required": [ + "totalCost", + "totalPaid", + "totalOwed" + ], + "type": "object" + } + }, + "required": [ + "summary", + "settlements", + "individualOwed", + "individualPaid" + ], + "type": "object" +}
4 tool updates
- First observed
rotation_plan - First observed
settle_up - First observed
split_costs - First observed
split_series
Related MCP Connectors
Split rent and utilities by room, settle up and generate roommate agreements. Free.
Split shared expenses in a group — no account needed. See who owes whom and settle up.
Round-robin fixtures, standings and match-day plans for league organizers. Free.
Track and split shared expenses across trips, events, and groups. Create groups, add expenses, and…
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceEnables AI agents to organize weekly football games by creating balanced teams and fixtures, managing squads and invites, setting games, tracking availability, entering results, and sharing vote links.1MIT
- AlicenseAqualityDmaintenanceSchedules, scores, odds, splits & explainable AI bet confidence — 8+ sports, free instant key.1611MIT
- AlicenseBqualityDmaintenanceA Model Context Protocol server that helps track expenses and calculate reimbursements for social events, making it easy to settle balances between friends.11Apache 2.0
- AlicenseAqualityBmaintenanceEnables group expense management and fair settlement via MCP, allowing creation of groups, recording expenses, viewing balances, and computing minimal transfers to settle debts.8MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.