haus

create_appliance

Create an appliance record for the household, tracking purchase date, warranty expiry, and optional references to previously created warranty/insurance documents.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	Name, e.g. what it is or where it lives.
`brand`	No	Manufacturer or brand.
`model`	No	Model, as printed on the appliance or manual.
`notes`	No	Freeform notes.
`purchaseDate`	No	Purchase date, YYYY-MM-DD.
`serialNumber`	No	Serial number, for support or warranty claims.
`warrantyDocumentId`	No	Warranty document id from create_document.
`warrantyExpiryDate`	No	Warranty expiry, YYYY-MM-DD. Must not precede purchaseDate.
`insuranceDocumentId`	No	Insurance document id from create_document.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`items`	Yes
`title`	No
`message`	No
`variant`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedSep 8, 2026

changedInput schema / properties / brand / description

Previous value: -"Manufacturer or brand name."New value: +"Manufacturer or brand."

changedInput schema / properties / insuranceDocumentId / description

Previous value: -"ID of a previously created document containing the insurance policy."New value: +"Insurance document id from create_document."

changedInput schema / properties / model / description

Previous value: -"Model name or number, as printed on the appliance or its manual."New value: +"Model, as printed on the appliance or manual."

changedInput schema / properties / name / description

Previous value: -"Name of the appliance, e.g. what it is or where it's located."New value: +"Name, e.g. what it is or where it lives."

changedInput schema / properties / notes / description

Previous value: -"Freeform notes about the appliance."New value: +"Freeform notes."

changedInput schema / properties / purchaseDate / description

Previous value: -"Date the appliance was purchased, in YYYY-MM-DD format."New value: +"Purchase date, YYYY-MM-DD."

changedInput schema / properties / serialNumber / description

Previous value: -"Manufacturer serial number, used when contacting support or filing a warranty claim."New value: +"Serial number, for support or warranty claims."

changedInput schema / properties / warrantyDocumentId / description

Previous value: -"ID of a previously created document containing the warranty paperwork."New value: +"Warranty document id from create_document."

changedInput schema / properties / warrantyExpiryDate / description

Previous value: -"Date the manufacturer warranty expires, in YYYY-MM-DD format. Must not be before purchaseDate."New value: +"Warranty expiry, YYYY-MM-DD. Must not precede purchaseDate."

Changed19 schema fields changedJul 14, 2026

addedInput schema / examples

Added value: +[
+  {
+    "brand": "Samsung",
+    "model": "RF28R7351SG",
+    "name": "Kitchen Refrigerator",
+    "purchaseDate": "2023-11-04",
+    "serialNumber": "S/N-4471829",
+    "warrantyExpiryDate": "2025-11-04"
+  }
+]

addedInput schema / properties / brand / description
```
Added value: +"Manufacturer or brand name."
```
addedInput schema / properties / brand / examples
```
Added value: +[
+  "Samsung"
+]
```

changedInput schema / properties / insuranceDocumentId / description

Previous value: -"Document ID of insurance policy"New value: +"ID of a previously created document containing the insurance policy."

addedInput schema / properties / insuranceDocumentId / examples
```
Added value: +[
+  "doc_1a2b3c4d5e6f"
+]
```

addedInput schema / properties / model / description

Added value: +"Model name or number, as printed on the appliance or its manual."

addedInput schema / properties / model / examples
```
Added value: +[
+  "RF28R7351SG"
+]
```

addedInput schema / properties / name / description

Added value: +"Name of the appliance, e.g. what it is or where it's located."

addedInput schema / properties / name / examples
```
Added value: +[
+  "Kitchen Refrigerator"
+]
```

addedInput schema / properties / notes / description

Added value: +"Freeform notes about the appliance."

addedInput schema / properties / notes / examples

Added value: +[
+  "Extended warranty purchased in-store, receipt in the kitchen drawer."
+]

changedInput schema / properties / purchaseDate / description

Previous value: -"YYYY-MM-DD format"New value: +"Date the appliance was purchased, in YYYY-MM-DD format."

addedInput schema / properties / purchaseDate / examples
```
Added value: +[
+  "2023-11-04"
+]
```

addedInput schema / properties / serialNumber / description

Added value: +"Manufacturer serial number, used when contacting support or filing a warranty claim."

addedInput schema / properties / serialNumber / examples
```
Added value: +[
+  "S/N-4471829"
+]
```

changedInput schema / properties / warrantyDocumentId / description

Previous value: -"Document ID of warranty"New value: +"ID of a previously created document containing the warranty paperwork."

addedInput schema / properties / warrantyDocumentId / examples
```
Added value: +[
+  "doc_8f3a1c2b9e4d"
+]
```

changedInput schema / properties / warrantyExpiryDate / description

Previous value: -"YYYY-MM-DD format"New value: +"Date the manufacturer warranty expires, in YYYY-MM-DD format. Must not be before purchaseDate."

addedInput schema / properties / warrantyExpiryDate / examples
```
Added value: +[
+  "2025-11-04"
+]
```

First observedJun 30, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already indicate the tool is not read-only and not destructive. The description adds a valuable precondition: warranty and insurance document IDs must refer to previously created documents. It also clarifies that the record tracks purchase date and warranty expiry, giving context beyond the annotations.

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?

A single well-structured sentence places the core action first and then lists the tracked data and optional references. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With a full parameter schema and an output schema present, the description covers the essential purpose and ordering prerequisite. It could be more explicit about when to use this instead of update_appliance, but nothing critical is missing for an agent to invoke the tool 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 the schema already documents all parameters. The description adds a high-level grouping (purchase date, warranty expiry, document references) but does not provide new format or constraint details beyond what schema properties already state.

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 uses a specific verb and resource: 'Create an appliance record for the household'. This clearly distinguishes it from sibling tools like create_contact or create_vehicle, and the mention of warranty/insurance documents differentiates it from create_document.

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?

The description provides clear context: this is for adding a new appliance record to the household, not for modifying or deleting. It doesn't explicitly name alternatives such as update_appliance, but the creation context is unambiguous enough to guide selection.

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

All haus 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?