RoomSplit

Roommate agreement

roommate_agreement

Read-onlyIdempotent

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).

Input Schema

Name	Required	Description
`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

Schema Changelog

Changes observed during successful MCP inspections.

Changed20 schema fields changedOct 10, 2026

changedInput schema / properties / deposit / description

Previous value: -"Deposit amount (0 if none)"New value: +"Total deposit amount, 0 or more (0 = no deposit)"

changedInput schema / properties / house_rules / description

Previous 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"

changedInput schema / properties / monthly_rent / description

Previous value: -"Total monthly rent"New value: +"Total monthly rent for the home, positive; split equally between tenants in the text"

changedInput schema / properties / move_in_date / description

Previous value: -"Move-in date (YYYY-MM-DD)"New value: +"Move-in date YYYY-MM-DD, e.g. 2026-11-01"

changedInput schema / properties / notice_period_months / description

Previous value: -"Notice period in months, default 1"New value: +"Notice period in whole months, default 1"

addedInput schema / properties / notice_period_months / minimum
```
Added value: +1
```
changedInput schema / properties / notice_period_months / type
```
Previous value: -"number"New value: +"integer"
```

changedInput schema / properties / property_address / description

Previous value: -"Address of the shared home"New value: +"Street address of the shared home, e.g. '12 Elm Street, Flat 3'"

changedInput schema / properties / room_assignments / description

Previous value: -"Who sleeps in which room"New value: +"Optional: who sleeps in which room, one room per tenant; names must match tenants"

addedInput schema / properties / room_assignments / items / properties / name / description
```
Added value: +"Tenant name (must be in tenants)"
```
addedInput schema / properties / room_assignments / items / properties / room / description
```
Added value: +"Room label, e.g. 'Box room'"
```

changedInput schema / properties / tenants / description

Previous value: -"All tenants (at least 2)"New value: +"Unique names of all tenants (at least 2), e.g. [\"Asha\",\"Dev\"]"

addedInput schema / properties / tenants / minItems
```
Added value: +2
```

changedInput schema / properties / utilities_policy / description

Previous 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"

addedOutput schema / properties / agreement

Added value: +{
+  "description": "Full agreement text, numbered sections and signature lines",
+  "type": "string"
+}

removedOutput schema / properties / agreement_text

Removed value: -{
-  "description": "The full text of the roommate agreement in plain language.",
-  "type": "string"
-}

addedOutput schema / properties / checklist

Added value: +{
+  "description": "Practical steps to complete before signing",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / disclaimer

Added value: +{
+  "description": "Not-legal-advice disclaimer for the template",
+  "type": "string"
+}

removedOutput schema / properties / signature_blocks

Removed 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"
-}

changedOutput schema / required

Previous value: -[
-  "agreement_text",
-  "signature_blocks"
-]New value: +[
+  "agreement",
+  "checklist",
+  "disclaimer"
+]

Changed1 schema field changedOct 6, 2026

changedOutput 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"
+}

First observedOct 4, 2026

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.

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