haus

store_memory

Store a long-term memory about the household. Use sparingly for durable preferences, routines, constraints, or insights worth recalling in a future conversation. Recall first to avoid duplicates.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	Short kebab-case slug, e.g. 'preferred-cleaning-day'. Max 80 chars.
`type`	Yes	'user' for what the user stated, 'system' for insights you derived.
`content`	Yes	Free-text body. Max 8000 chars.
`description`	Yes	Single-line summary used to decide relevance later. Max 200 chars.

Output Schema

TableJSON Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 8, 2026

changedInput schema / properties / type / description

Previous value: -"Author of the memory. 'user' for things the user has stated; 'system' for stable insights you derived yourself."New value: +"'user' for what the user stated, 'system' for insights you derived."

Changed5 schema fields changedJul 14, 2026

addedInput schema / examples

Added value: +[
+  {
+    "content": "The user said they'd rather have the house cleaned Saturday mornings instead of Friday evenings, because they work late on Fridays.",
+    "description": "User prefers the house cleaned on Saturday mornings",
+    "name": "preferred-cleaning-day",
+    "type": "user"
+  }
+]

addedInput schema / properties / content / examples

Added value: +[
+  "The user said on 2026-07-10 they'd rather have the house cleaned Saturday mornings instead of Friday evenings, because they work late on Fridays."
+]

addedInput schema / properties / description / examples

Added value: +[
+  "User prefers the house cleaned on Saturday mornings"
+]

addedInput schema / properties / name / examples

Added value: +[
+  "preferred-cleaning-day"
+]

addedInput schema / properties / type / examples
```
Added value: +[
+  "user"
+]
```

First observedJun 30, 2026

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already cover the read-only/destructive safety profile (readOnlyHint=false, destructiveHint=false). The description adds useful context that memories are long-term and that use should be selective, but it does not disclose what happens if a memory with the same name already exists, which is a relevant behavioral gap for a store operation.

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?

The description is three concise sentences with no filler. The core action is front-loaded, followed by targeted usage guidance and a duplicate-avoidance instruction. Every sentence earns its place.

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?

The schema and output schema cover parameter structure and return values, so the description can focus on usage. It provides the core context: household scope, selective use, and recall-first behavior. The only notable omission is explicit guidance to route existing memories to update_memory, which is a minor gap given the sibling toolset.

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%: all four parameters (name, type, content, description) have detailed descriptions, examples, and constraints. The description adds no parameter-specific guidance beyond what the schema already provides, so the baseline of 3 applies.

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

Purpose4/5

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

Description states a clear verb ('Store') and resource ('long-term memory about the household'), and enumerates the kinds of content (durable preferences, routines, constraints, insights) that qualify. It doesn't explicitly contrast with the sibling update_memory or recall_memory tools, but the core purpose is unmistakable.

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 gives explicit guidance on when to use the tool ('Use sparingly', and only for durable preferences/routines/constraints/insights) and tells the agent to 'Recall first to avoid duplicates.' It stops short of naming update_memory as the alternative for modifying an existing memory, so alternative routing is incomplete.

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?