Zovo Bill Splitter

Split rent

split_rent

Read-onlyIdempotent

Use this when roommates or housemates want to split rent fairly: by bedroom size (square feet or metres) with a shared-space portion split per occupant, by income, or equally, with optional per-room adjustments (private bathroom, no window), couples sharing a room, and utilities split per occupant. Every amount is exact to the cent and the parts add up exactly to the rent. Does not give legal or tenancy advice, collect rent, or handle one-off shared expenses (use settle_group_expenses for those).

Input Schema

Name	Required	Description
`basis`	No	How to split: room_size (default when every room has a size), income (in proportion to income), or equal (per occupant).
`rooms`	Yes	Each bedroom or person. Example: [{"name": "Ana", "size": 160}, {"name": "Ben", "size": 120}, {"name": "Chloe", "size": 100}].
`currency`	No	ISO 4217 code, e.g. USD, EUR, GBP. Defaults to USD.
`total_rent`	Yes	Total monthly rent for the home, e.g. 3200.
`extra_costs`	No	Other monthly costs split equally per occupant, e.g. 180 for utilities and internet.
`shared_area`	No	Area of shared space (kitchen, living room, shared bathroom) in the same unit as the room sizes, e.g. 400. Its share of the total area is split equally per occupant.
`shared_percent`	No	Alternative to shared_area: percent of the rent treated as shared space and split equally per occupant, e.g. 40. Defaults to 50 for room_size when shared_area is not given.

Output Schema

Name	Required	Description	Default
`kind`	Yes
`basis`	Yes
`hints`	Yes
`rooms`	Yes
`totals`	Yes
`display`	Yes
`currency`	Yes
`settings`	Yes
`warnings`	Yes
`assumptions`	Yes
`minor_units`	Yes
`shared_source`	Yes
`shared_percent`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 22, 2026

TDQS

A4.2/5.0

Behavior4/5

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

The annotations already establish that this is a read-only, idempotent, non-destructive operation. The description adds useful behavior beyond that: every amount is exact to the cent and the parts add up exactly to the rent, and it clarifies that the tool does not collect rent or give legal advice.

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?

The definition is front-loaded with the usage trigger and then adds the arithmetic guarantee and exclusions. The first sentence is dense with many clauses, but overall there is little wasted text and no repetition of schema details.

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 seven-parameter tool with a full output schema and strong annotations, the description covers purpose, supported splitting bases, arithmetic guarantees, and key exclusions. An agent has enough information to decide when to call it and what behavior to expect.

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 the schema already documents all seven parameters in detail. The description reinforces concepts such as shared-space splitting per occupant and per-room adjustments, but it does not add syntax or edge-case semantics beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource — splitting rent among roommates — and enumerates the supported bases (room size, income, equal), adjustments, couples, and utilities. It also distinguishes itself from settle_group_expenses for one-off shared expenses, so an agent can tell what it is for without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a clear trigger (roommates or housemates wanting to split rent fairly) and an explicit exclusion for one-off shared expenses with a named alternative, settle_group_expenses. The other sibling, split_bill, is not mentioned, leaving a small gap in routing guidance.

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

All Zovo Bill Splitter tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?