A
licenseA
qualityB
maintenanceEnables voice-first shared household expense tracking through Alexa+, letting flatmates record purchases, check balances, and settle debts in the fewest payments.
8
MIT
RoomSplit
Server Details
Split rent and utilities by room, settle up and generate roommate agreements. Free.
If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Uptime
- 100.0% over 22 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Server Listing
- Sahadeva
TDQS
A4.4/5.0
Scored across 4 tools
Disambiguation4/5
The tools have distinct purposes: roommate_agreement for drafting legal docs, split_rent for rent division, split_utilities for bills, and settle_up for balance reconciliation. However, split_utilities and settle_up both involve splitting costs and could be confused without careful reading; descriptions mitigate this with explicit cross-references but the overlap is notable.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern (roommate_agreement is a noun but functions as a verb-like action; settle_up is verb_particle; split_rent and split_utilities are verb_noun). The naming is predictable and cohesive, with no mixing of conventions.
Tool Count4/5
Four tools is appropriate for a niche domain (roommate finance and agreements), covering the core operations without bloat. However, it is on the lower end; an extra tool for tracking payments or reminders might be useful, but the current set is well-scoped.
Completeness4/5
The tools cover agreement drafting, rent splitting, utility splitting, and settlement—a complete lifecycle for shared living finances. Minor gaps exist: no tool to handle deposits or security deposits beyond the agreement template, and no way to record actual payments, but the core surface is solid.
Available Tools
4 toolsroommate_agreementRoommate agreementARead-onlyIdempotentInspect
Draft a plain-language shared-living agreement (parties, term, equal rent shares, deposit, utilities, house rules, notice, signature lines) plus a pre-signing checklist. Use when housemates want house terms in writing. Not legal advice. Do NOT use to compute unequal rent (use split_rent) or bill shares (use split_utilities).
| Name | Required | Description | Default |
|---|---|---|---|
| deposit | Yes | Total deposit amount, 0 or more (0 = no deposit) | |
| tenants | Yes | Unique names of all tenants (at least 2), e.g. ["Asha","Dev"] | |
| house_rules | No | Custom house rules, one sentence each; default covers quiet hours, guests, cleaning rota and shared supplies | |
| monthly_rent | Yes | Total monthly rent for the home, positive; split equally between tenants in the text | |
| move_in_date | Yes | Move-in date YYYY-MM-DD, e.g. 2026-11-01 | |
| property_address | Yes | Street address of the shared home, e.g. '12 Elm Street, Flat 3' | |
| room_assignments | No | Optional: who sleeps in which room, one room per tenant; names must match tenants | |
| utilities_policy | No | One sentence on how utilities are shared; default: split equally between tenants unless agreed otherwise | |
| notice_period_months | No | Notice period in whole months, default 1 |
Output Schema
| Name | Required | Description |
|---|---|---|
| agreement | Yes | Full agreement text, numbered sections and signature lines |
| checklist | Yes | Practical steps to complete before signing |
| disclaimer | Yes | Not-legal-advice disclaimer for the template |
TDQS
A4.4/5.0
Behavior4/5
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 structurally. The description adds context annotations cannot: that output is a drafted document plus a pre-signing checklist, and that it carries no legal weight. It stops short of describing return format, which is acceptable given an output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the core purpose before usage and exclusions, and every sentence carries routing or scope information. The parenthetical section list is somewhat long and partially duplicates what the schema already documents, but it is not waste.
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?
With 100% schema coverage, an output schema, and full annotations, the description only needs to supply purpose, usage, exclusions and output nature — all of which it does. An agent has everything required to select and call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 9 parameters including defaults (notice_period_months, utilities_policy, house_rules) are already documented in the schema. The description's section list (parties, term, deposit, utilities, house rules, notice) loosely maps to parameters but adds no syntax or format meaning beyond the schema. Baseline 3 is appropriate.
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?
Specific verb (Draft) plus resource (plain-language shared-living agreement), and it enumerates the exact sections produced plus a pre-signing checklist. The three siblings (split_rent, split_utilities, settle_up) are all about money math, and this tool is clearly the document-generation one.
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?
States when to use it ('when housemates want house terms in writing'), a scope caveat ('Not legal advice'), and explicit negative routing with named alternatives ('Do NOT use to compute unequal rent (use split_rent) or bill shares (use split_utilities)'). Nothing is left 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
Split shared costs equally between housemates, compare with what each already paid, and compute balances plus the fewest payments that settle everyone. Use after people fronted money for the group. Computes only; moves no money. Do NOT use for usage-weighted bills (use split_utilities).
| Name | Required | Description | Default |
|---|---|---|---|
| costs | Yes | Shared costs, split equally between everyone in payments (names must be unique), e.g. [{"name":"Groceries","amount":140}] | |
| payments | Yes | Every housemate sharing the costs and what they already paid (include people who paid 0), e.g. [{"name":"Asha","paid":150},{"name":"Mira","paid":0}] |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | Yes | Summary of how many payments settle the group |
| people | Yes | Per-housemate paid, owed and balance |
| transfers | Yes | Fewest payments that settle all balances (empty when settled) |
| total_costs | Yes | Sum of all shared costs |
TDQS
A4.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds meaningful context beyond them by stating 'Computes only; moves no money', which tells the agent no financial side effect occurs. It stops short of describing the output shape, but an output schema exists.
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?
Three tight sentences: what it does, when to use it, then the exclusion. The core computation is front-loaded and no sentence is filler.
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?
For a two-parameter computation tool with full schema coverage and an output schema, the description supplies purpose, trigger, exclusion, and the no-side-effect guarantee. Nothing needed 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline would be 3, but the description adds the crucial relationship semantics: costs are split equally across everyone listed in payments, and payments are compared against those costs. That linkage between the two parameters is not inferable from either schema field alone.
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?
States a specific verb+resource: splitting shared costs equally, comparing against what each person paid, and computing balances plus the minimum set of settling payments. It explicitly contrasts itself with split_utilities, so an agent can separate it from siblings without reading schemas.
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?
Gives a clear trigger ('Use after people fronted money for the group') and an explicit exclusion with the correct alternative ('Do NOT use for usage-weighted bills (use split_utilities)'). Both when-to-use and when-not-to-use are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
split_rentSplit rentARead-onlyIdempotentInspect
Split a fixed monthly rent across rooms, equally or weighted by room size, and divide a shared room's rent equally between its occupants. Use when deciding who pays how much rent. Do NOT use for utility bills (use split_utilities) or to settle who already paid what (use settle_up).
| Name | Required | Description | Default |
|---|---|---|---|
| rooms | Yes | Every room that pays rent (room names must be unique), e.g. [{"name":"Master","size":20,"occupants":["Asha","Dev"]}] | |
| method | No | 'equal' (same rent per room) or 'by_size' (proportional to size). Default: by_size when every room has a size, else equal | |
| total_rent | Yes | Monthly rent for the whole home, positive number in any currency, e.g. 2400 |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | Yes | Plain-language explanation of how the rent was split |
| rooms | Yes | Per-room rent shares, in input order; they sum to total_rent |
| method | Yes | Split method actually applied |
| total_rent | Yes | Total monthly rent that was split, rounded to cents |
TDQS
A4.5/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, closed-world), so the bar is lower. The description adds the useful behavioral detail that a shared room's rent is divided equally among its occupants, and it hints at the default method logic. It stops short of describing output shape, but that is largely covered elsewhere.
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 tight sentences, front-loaded with the operation, followed by routing guidance. Every clause earns its place with no redundancy.
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?
For a pure computation tool with full schema coverage and an output schema, the description supplies everything an agent needs: what it computes, the two modes, the occupant rule, and when to pick a sibling instead.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents total_rent, rooms, occupants, size and the method enum with its default rule. The description restates the same semantics rather than adding new meaning, so the baseline 3 is appropriate.
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 (split) and resource (fixed monthly rent) and enumerates both allocation modes (equal, by size) plus the occupant sub-split. It is immediately distinguishable from split_utilities and settle_up.
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 gives an explicit trigger ('Use when deciding who pays how much rent') and two explicit exclusions with named alternatives: utility bills go to split_utilities, settling past payments goes to settle_up. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
split_utilitiesSplit utilitiesARead-onlyIdempotentInspect
Split utility and household bills across housemates, each bill equally, by occupants, or by usage weight, and total what each person owes. Use for recurring shared bills such as electricity, gas or internet. Do NOT use for rent (use split_rent) or to settle who already paid (use settle_up).
| Name | Required | Description | Default |
|---|---|---|---|
| bills | Yes | Bills to split (names must be unique), e.g. [{"name":"Electricity","amount":120,"split":"by_usage"}] | |
| people | Yes | Housemates sharing the bills (names must be unique), e.g. [{"name":"Asha","usage_weight":2},{"name":"Dev","usage_weight":1}] |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | Yes | Plain-language explanation of the totals |
| bills | Yes | Each bill with its per-person shares (shares sum to the bill amount) |
| totals | Yes | Total each person owes across all bills |
| grand_total | Yes | Sum of all bill amounts |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), lowering the bar. The description adds real value beyond that by characterizing the operation as a pure calculation that also aggregates ('total what each person owes') and by scoping it to recurring shared bills. It does not disclose rounding, currency handling, or the result shape, but the output schema exists to carry return values.
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?
Three sentences, front-loaded with the core purpose, followed by inclusion criteria and then the two exclusions with alternatives. Every sentence earns its place with no filler.
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?
Purpose, routing to siblings, and supported split modes are all covered, and an output schema exists so return-value detail is unnecessary. Nothing an agent needs to select or invoke this tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both top-level params and the nested split enum are fully documented in the schema. The description restates the three split modes (equal, by occupants, by usage weight) but adds no syntax, uniqueness, or weighting semantics beyond what the schema already says. Baseline 3 is correct when the schema does the heavy lifting.
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?
States a specific verb and resource ('Split utility and household bills across housemates') and names the three supported split modes, so the agent knows exactly what computation this performs. It also explicitly distinguishes itself from split_rent and settle_up, making sibling selection unambiguous.
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?
Gives positive guidance ('Use for recurring shared bills such as electricity, gas or internet') and explicit exclusions with the correct alternative named for each ('Do NOT use for rent (use split_rent)', 'to settle who already paid (use settle_up)'). Nothing is left to inference.
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.
4 tool updates
- Changed
roommate_agreement20 fields changed- changed
Input schema / properties / deposit / descriptionPrevious value: -"Deposit amount (0 if none)"New value: +"Total deposit amount, 0 or more (0 = no deposit)" - changed
Input schema / properties / house_rules / descriptionPrevious value: -"Custom house rules; default covers quiet hours, guests, cleaning rota and shared supplies"New value: +"Custom house rules, one sentence each; default covers quiet hours, guests, cleaning rota and shared supplies" - changed
Input schema / properties / monthly_rent / descriptionPrevious value: -"Total monthly rent"New value: +"Total monthly rent for the home, positive; split equally between tenants in the text" - changed
Input schema / properties / move_in_date / descriptionPrevious value: -"Move-in date (YYYY-MM-DD)"New value: +"Move-in date YYYY-MM-DD, e.g. 2026-11-01" - changed
Input schema / properties / notice_period_months / descriptionPrevious value: -"Notice period in months, default 1"New value: +"Notice period in whole months, default 1" - added
Input schema / properties / notice_period_months / minimumAdded value: +1 - changed
Input schema / properties / notice_period_months / typePrevious value: -"number"New value: +"integer" - changed
Input schema / properties / property_address / descriptionPrevious value: -"Address of the shared home"New value: +"Street address of the shared home, e.g. '12 Elm Street, Flat 3'" - changed
Input schema / properties / room_assignments / descriptionPrevious value: -"Who sleeps in which room"New value: +"Optional: who sleeps in which room, one room per tenant; names must match tenants" - added
Input schema / properties / room_assignments / items / properties / name / descriptionAdded value: +"Tenant name (must be in tenants)" - added
Input schema / properties / room_assignments / items / properties / room / descriptionAdded value: +"Room label, e.g. 'Box room'" - changed
Input schema / properties / tenants / descriptionPrevious value: -"All tenants (at least 2)"New value: +"Unique names of all tenants (at least 2), e.g. [\"Asha\",\"Dev\"]" - added
Input schema / properties / tenants / minItemsAdded value: +2 - changed
Input schema / properties / utilities_policy / descriptionPrevious value: -"How utilities are shared; default 'split equally unless agreed otherwise'"New value: +"One sentence on how utilities are shared; default: split equally between tenants unless agreed otherwise" - added
Output schema / properties / agreementAdded value: +{ + "description": "Full agreement text, numbered sections and signature lines", + "type": "string" +} - removed
Output schema / properties / agreement_textRemoved value: -{ - "description": "The full text of the roommate agreement in plain language.", - "type": "string" -} - added
Output schema / properties / checklistAdded value: +{ + "description": "Practical steps to complete before signing", + "items": { + "type": "string" + }, + "type": "array" +} - added
Output schema / properties / disclaimerAdded value: +{ + "description": "Not-legal-advice disclaimer for the template", + "type": "string" +} - removed
Output schema / properties / signature_blocksRemoved value: -{ - "description": "The signature blocks for each tenant.", - "items": { - "properties": { - "signature_date": { - "description": "The date on which the tenant should sign.", - "type": "string" - }, - "tenant_name": { - "description": "The name of the tenant who needs to sign.", - "type": "string" - } - }, - "required": [ - "tenant_name", - "signature_date" - ], - "type": "object" - }, - "type": "array" -} - changed
Output schema / requiredPrevious value: -[ - "agreement_text", - "signature_blocks" -]New value: +[ + "agreement", + "checklist", + "disclaimer" +]
- Changed
settle_up15 fields changed- changed
Input schema / properties / costs / descriptionPrevious value: -"Shared costs to split equally"New value: +"Shared costs, split equally between everyone in payments (names must be unique), e.g. [{\"name\":\"Groceries\",\"amount\":140}]" - added
Input schema / properties / costs / items / properties / amount / descriptionAdded value: +"Cost amount, positive number" - added
Input schema / properties / costs / items / properties / name / descriptionAdded value: +"Unique cost label, e.g. 'Weekly shop'" - added
Input schema / properties / costs / minItemsAdded value: +1 - changed
Input schema / properties / payments / descriptionPrevious value: -"What each housemate paid"New value: +"Every housemate sharing the costs and what they already paid (include people who paid 0), e.g. [{\"name\":\"Asha\",\"paid\":150},{\"name\":\"Mira\",\"paid\":0}]" - added
Input schema / properties / payments / items / properties / name / descriptionAdded value: +"Unique housemate name" - added
Input schema / properties / payments / items / properties / paid / descriptionAdded value: +"Amount this housemate already paid towards the costs, 0 or more" - added
Input schema / properties / payments / minItemsAdded value: +1 - removed
Output schema / properties / balancesRemoved value: -{ - "description": "List of balances for each housemate", - "items": { - "properties": { - "balance": { - "description": "The balance owed or due by the housemate", - "type": "number" - }, - "name": { - "description": "The name of the housemate", - "type": "string" - } - }, - "required": [ - "name", - "balance" - ], - "type": "object" - }, - "type": "array" -} - added
Output schema / properties / noteAdded value: +{ + "description": "Summary of how many payments settle the group", + "type": "string" +} - added
Output schema / properties / peopleAdded value: +{ + "description": "Per-housemate paid, owed and balance", + "items": { + "properties": { + "balance": { + "description": "paid minus owed; positive = should receive money, negative = owes money", + "type": "number" + }, + "name": { + "description": "Housemate name", + "type": "string" + }, + "owed": { + "description": "Equal share of the total costs", + "type": "number" + }, + "paid": { + "description": "Amount already paid", + "type": "number" + } + }, + "required": [ + "name", + "paid", + "owed", + "balance" + ], + "type": "object" + }, + "type": "array" +} - added
Output schema / properties / total_costsAdded value: +{ + "description": "Sum of all shared costs", + "type": "number" +} - removed
Output schema / properties / transactionsRemoved value: -{ - "description": "List of transactions to settle the balances", - "items": { - "properties": { - "amount": { - "description": "The amount to be paid", - "type": "number" - }, - "from": { - "description": "The name of the housemate paying", - "type": "string" - }, - "to": { - "description": "The name of the housemate receiving the payment", - "type": "string" - } - }, - "required": [ - "from", - "to", - "amount" - ], - "type": "object" - }, - "type": "array" -} - added
Output schema / properties / transfersAdded value: +{ + "description": "Fewest payments that settle all balances (empty when settled)", + "items": { + "properties": { + "amount": { + "description": "Amount to transfer", + "type": "number" + }, + "from": { + "description": "Housemate who pays", + "type": "string" + }, + "to": { + "description": "Housemate who receives", + "type": "string" + } + }, + "required": [ + "from", + "to", + "amount" + ], + "type": "object" + }, + "type": "array" +} - changed
Output schema / requiredPrevious value: -[ - "balances", - "transactions" -]New value: +[ + "total_costs", + "people", + "transfers", + "note" +]
- Changed
split_rent20 fields changed- changed
Input schema / properties / method / descriptionPrevious value: -"Split method; default by_size when every room has a size, else equal"New value: +"'equal' (same rent per room) or 'by_size' (proportional to size). Default: by_size when every room has a size, else equal" - changed
Input schema / properties / rooms / descriptionPrevious value: -"Rooms in the house"New value: +"Every room that pays rent (room names must be unique), e.g. [{\"name\":\"Master\",\"size\":20,\"occupants\":[\"Asha\",\"Dev\"]}]" - added
Input schema / properties / rooms / items / properties / name / descriptionAdded value: +"Unique room label, e.g. 'Master bedroom'" - added
Input schema / properties / rooms / items / properties / occupants / descriptionAdded value: +"Names of the people in this room; when given, the room's rent is split equally between them" - added
Input schema / properties / rooms / items / properties / size / descriptionAdded value: +"Room area (m2 or ft2, any consistent unit), positive; needed on every room for by_size" - added
Input schema / properties / rooms / minItemsAdded value: +1 - changed
Input schema / properties / total_rent / descriptionPrevious value: -"Monthly rent for the whole house"New value: +"Monthly rent for the whole home, positive number in any currency, e.g. 2400" - added
Output schema / properties / methodAdded value: +{ + "description": "Split method actually applied", + "enum": [ + "equal", + "by_size" + ], + "type": "string" +} - added
Output schema / properties / noteAdded value: +{ + "description": "Plain-language explanation of how the rent was split", + "type": "string" +} - changed
Output schema / properties / rooms / descriptionPrevious value: -"The rooms in the house and their respective shares."New value: +"Per-room rent shares, in input order; they sum to total_rent" - changed
Output schema / properties / rooms / items / properties / name / descriptionPrevious value: -"The name of the room."New value: +"Room label" - removed
Output schema / properties / rooms / items / properties / occupantsRemoved value: -{ - "description": "The occupants of the room and their respective shares.", - "items": { - "properties": { - "name": { - "description": "The name of the occupant.", - "type": "string" - }, - "share": { - "description": "The amount of rent this occupant owes.", - "type": "number" - } - }, - "required": [ - "name", - "share" - ], - "type": "object" - }, - "type": "array" -} - added
Output schema / properties / rooms / items / properties / per_occupantAdded value: +{ + "description": "Equal split of this room's rent between its occupants (only when occupants were given)", + "items": { + "properties": { + "amount": { + "description": "Amount, rounded to cents", + "type": "number" + }, + "name": { + "description": "Person's name", + "type": "string" + } + }, + "required": [ + "name", + "amount" + ], + "type": "object" + }, + "type": "array" +} - added
Output schema / properties / rooms / items / properties / rentAdded value: +{ + "description": "Monthly rent for this room", + "type": "number" +} - removed
Output schema / properties / rooms / items / properties / shareRemoved value: -{ - "description": "The amount of rent this room owes.", - "type": "number" -} - removed
Output schema / properties / rooms / items / properties / sizeRemoved value: -{ - "description": "The size of the room.", - "type": "number" -} - added
Output schema / properties / rooms / items / properties / weightAdded value: +{ + "description": "Weight used: room size for by_size, 1 for equal", + "type": "number" +} - changed
Output schema / properties / rooms / items / requiredPrevious value: -[ - "name", - "share" -]New value: +[ + "name", + "weight", + "rent" +] - changed
Output schema / properties / total_rent / descriptionPrevious value: -"The total monthly rent for the whole house."New value: +"Total monthly rent that was split, rounded to cents" - changed
Output schema / requiredPrevious value: -[ - "total_rent", - "rooms" -]New value: +[ + "method", + "total_rent", + "rooms", + "note" +]
- Changed
split_utilities16 fields changed- changed
Input schema / properties / bills / descriptionPrevious value: -"Bills to split"New value: +"Bills to split (names must be unique), e.g. [{\"name\":\"Electricity\",\"amount\":120,\"split\":\"by_usage\"}]" - added
Input schema / properties / bills / items / properties / amount / descriptionAdded value: +"Bill total, positive number, e.g. 120" - added
Input schema / properties / bills / items / properties / name / descriptionAdded value: +"Unique bill label, e.g. 'Electricity'" - added
Input schema / properties / bills / items / properties / split / descriptionAdded value: +"'equal' per person, 'by_occupants' weighted by each person's occupants, or 'by_usage' weighted by usage_weight (required on everyone)" - added
Input schema / properties / bills / minItemsAdded value: +1 - changed
Input schema / properties / people / descriptionPrevious value: -"People sharing the house"New value: +"Housemates sharing the bills (names must be unique), e.g. [{\"name\":\"Asha\",\"usage_weight\":2},{\"name\":\"Dev\",\"usage_weight\":1}]" - added
Input schema / properties / people / items / properties / name / descriptionAdded value: +"Unique housemate name" - added
Input schema / properties / people / items / properties / occupants / descriptionAdded value: +"How many people this housemate pays for (by_occupants bills), positive, default 1" - added
Input schema / properties / people / items / properties / usage_weight / descriptionAdded value: +"Relative usage for by_usage bills, positive, e.g. 2 for double use, 0.5 for a light user" - added
Input schema / properties / people / minItemsAdded value: +1 - added
Output schema / properties / billsAdded value: +{ + "description": "Each bill with its per-person shares (shares sum to the bill amount)", + "items": { + "properties": { + "amount": { + "description": "Bill total, rounded to cents", + "type": "number" + }, + "name": { + "description": "Bill label", + "type": "string" + }, + "shares": { + "description": "Each person's share of this bill", + "items": { + "properties": { + "amount": { + "description": "Amount, rounded to cents", + "type": "number" + }, + "name": { + "description": "Person's name", + "type": "string" + } + }, + "required": [ + "name", + "amount" + ], + "type": "object" + }, + "type": "array" + }, + "split": { + "description": "Split rule applied", + "enum": [ + "equal", + "by_occupants", + "by_usage" + ], + "type": "string" + } + }, + "required": [ + "name", + "amount", + "split", + "shares" + ], + "type": "object" + }, + "type": "array" +} - added
Output schema / properties / grand_totalAdded value: +{ + "description": "Sum of all bill amounts", + "type": "number" +} - added
Output schema / properties / noteAdded value: +{ + "description": "Plain-language explanation of the totals", + "type": "string" +} - removed
Output schema / properties / split_resultsRemoved value: -{ - "description": "List of split results for each person", - "items": { - "properties": { - "bill_details": { - "description": "Details of each bill and the person's share", - "items": { - "properties": { - "amount_owed": { - "description": "Amount owed by the person for this bill", - "type": "number" - }, - "bill_name": { - "description": "Name of the bill", - "type": "string" - } - }, - "required": [ - "bill_name", - "amount_owed" - ], - "type": "object" - }, - "type": "array" - }, - "name": { - "description": "Name of the person", - "type": "string" - }, - "total_owed": { - "description": "Total amount owed by the person", - "type": "number" - } - }, - "required": [ - "name", - "total_owed", - "bill_details" - ], - "type": "object" - }, - "type": "array" -} - added
Output schema / properties / totalsAdded value: +{ + "description": "Total each person owes across all bills", + "items": { + "properties": { + "amount": { + "description": "Amount, rounded to cents", + "type": "number" + }, + "name": { + "description": "Person's name", + "type": "string" + } + }, + "required": [ + "name", + "amount" + ], + "type": "object" + }, + "type": "array" +} - changed
Output schema / requiredPrevious value: -[ - "split_results" -]New value: +[ + "bills", + "totals", + "grand_total", + "note" +]
4 tool updates
- Changed
roommate_agreement1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "agreement_text": { + "description": "The full text of the roommate agreement in plain language.", + "type": "string" + }, + "signature_blocks": { + "description": "The signature blocks for each tenant.", + "items": { + "properties": { + "signature_date": { + "description": "The date on which the tenant should sign.", + "type": "string" + }, + "tenant_name": { + "description": "The name of the tenant who needs to sign.", + "type": "string" + } + }, + "required": [ + "tenant_name", + "signature_date" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "agreement_text", + "signature_blocks" + ], + "type": "object" +}
- Changed
settle_up1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "balances": { + "description": "List of balances for each housemate", + "items": { + "properties": { + "balance": { + "description": "The balance owed or due by the housemate", + "type": "number" + }, + "name": { + "description": "The name of the housemate", + "type": "string" + } + }, + "required": [ + "name", + "balance" + ], + "type": "object" + }, + "type": "array" + }, + "transactions": { + "description": "List of transactions to settle the balances", + "items": { + "properties": { + "amount": { + "description": "The amount to be paid", + "type": "number" + }, + "from": { + "description": "The name of the housemate paying", + "type": "string" + }, + "to": { + "description": "The name of the housemate receiving the payment", + "type": "string" + } + }, + "required": [ + "from", + "to", + "amount" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "balances", + "transactions" + ], + "type": "object" +}
- Changed
split_rent1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "rooms": { + "description": "The rooms in the house and their respective shares.", + "items": { + "properties": { + "name": { + "description": "The name of the room.", + "type": "string" + }, + "occupants": { + "description": "The occupants of the room and their respective shares.", + "items": { + "properties": { + "name": { + "description": "The name of the occupant.", + "type": "string" + }, + "share": { + "description": "The amount of rent this occupant owes.", + "type": "number" + } + }, + "required": [ + "name", + "share" + ], + "type": "object" + }, + "type": "array" + }, + "share": { + "description": "The amount of rent this room owes.", + "type": "number" + }, + "size": { + "description": "The size of the room.", + "type": "number" + } + }, + "required": [ + "name", + "share" + ], + "type": "object" + }, + "type": "array" + }, + "total_rent": { + "description": "The total monthly rent for the whole house.", + "type": "number" + } + }, + "required": [ + "total_rent", + "rooms" + ], + "type": "object" +}
- Changed
split_utilities1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "split_results": { + "description": "List of split results for each person", + "items": { + "properties": { + "bill_details": { + "description": "Details of each bill and the person's share", + "items": { + "properties": { + "amount_owed": { + "description": "Amount owed by the person for this bill", + "type": "number" + }, + "bill_name": { + "description": "Name of the bill", + "type": "string" + } + }, + "required": [ + "bill_name", + "amount_owed" + ], + "type": "object" + }, + "type": "array" + }, + "name": { + "description": "Name of the person", + "type": "string" + }, + "total_owed": { + "description": "Total amount owed by the person", + "type": "number" + } + }, + "required": [ + "name", + "total_owed", + "bill_details" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "split_results" + ], + "type": "object" +}
4 tool updates
- First observed
roommate_agreement - First observed
settle_up - First observed
split_rent - First observed
split_utilities
Related MCP Connectors
Track and split shared expenses across trips, events, and groups. Create groups, add expenses, and…
- RoomlineOAuthapp.roomline
Rent, rooms and tenants for rent-by-the-room landlords: who is late, vacancies, reminders.
Split shared expenses in a group — no account needed. See who owes whom and settle up.
Split court costs, settle up and plan fair rotations for pickup games. Free.
Related MCP Servers
- AlicenseCqualityBmaintenanceEnables turning receipt photos into checked, per-person expense splits with exact-cent reconciliation.5MIT
- FlicenseNot gradedqualityBmaintenanceTracks subscriptions and recurring bills with flexible billing cycles, and provides upcoming renewals and spending summaries.-
- AlicenseAqualityBmaintenanceEnables managing Splitwise expenses and generating premium spending analytics with category breakdowns, trends, and settlement optimization through natural language.42MIT
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.