Skip to main content
Glama

Dayze — Life Context

Split Memory

split_memory
Destructive

Preview first, 30-day undo. Split one mixed agent memory into two: keep content_a on the original row and insert content_b as a new memory. Both parts must appear in the original. Reviewed and reversible: first call preview_destructive_change({ tool: "split_memory", arguments: { memory_id, content_a, content_b } }), which stores the exact change without applying it. After the user confirms, call split_memory with preview_id, restore_window_acknowledged: true and request_id; the reviewed preview is applied exactly and a changed record is refused. Returns restore_id; restore_change({ restore_id }) undoes it for 30 days unless the record was edited since. ($0.10; API key required)

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "preview_id": "<preview_id>",
      "restore_window_acknowledged": "<restore_window_acknowledged>",
      "request_id": "<request_id>"
    },
    "name": "split_memory"
  }
}

Input Schema

NameRequiredDescriptionDefault
memory_idNoMemory id, checked against the preview.
preview_idYespreview_id returned by preview_destructive_change for this tool.
request_idYesRequired idempotency key; retries return the original receipt.
idempotency_keyNoAlias for request_id.
restore_window_acknowledgedYesMust be true after reviewing the preview and its 30-day restore window.

Output Schema

NameRequiredDescriptionDefault
accountNoThe Dayze account this data belongs to. With more than one Dayze connection, name it in the answer.
content_aYes
content_bYes
memory_idYes
preview_idNo
provenanceNoWhich connector wrote the record and which connected Dayze account received it.
restore_idNoPass to restore_change to undo within restore_window_days.
reversibleNo
split_memory_idNo
idempotent_replayNo
life_state_rebuiltYes
restore_expires_atNo
restore_window_daysNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior3/5

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

The annotations already declare destructiveHint=true, readOnlyHint=false and openWorldHint=false, so the bar is lower. The description adds real value beyond them — preview-then-apply enforcement, refusal if the reviewed record changed, the restore_id contract and 30-day undo limit, plus cost and API-key prerequisites. It stops short of describing the returned receipt or failure modes such as expired previews, which keeps it at a solid but not exceptional level.

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-loaded with the two key facts (preview first, 30-day undo) and organized as purpose, then workflow, then return/undo, then cost. Dense but almost every clause carries required operational information; the pricing/API-key parenthetical is the one element that could move to a metadata field.

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?

An output schema exists, so return values need not be explained, yet the description still names restore_id and its scope. For a destructive, gated, paid operation with an idempotency requirement, the description covers prerequisites, enforcement, reversibility and cost — nothing an agent needs in order to call it 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 the baseline is 3. The description does add meaning for content_a/content_b — which are referenced in the description but absent from the schema properties — and clarifies the split invariant "both parts must appear in the original," but it says nothing further about idempotency_key aliasing or request_id retry receipts beyond what the schema already documents.

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 one mixed agent memory into two") and immediately defines the resulting shape: content_a stays on the original row, content_b becomes a new memory. That distinguishes it from merge siblings like merge_memory and merge_near_memory without requiring the schema to be opened.

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 an explicit ordered workflow: preview_destructive_change first, user confirmation, then split_memory with preview_id, restore_window_acknowledged and request_id, with restore_change named as the undo path. Prerequisites (reviewed preview, user confirms) and the 30-day window are stated outright.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.