Dayze — Life Context

Cleanup Duplicate Events

cleanup_duplicate_events

Destructive

Preview first, 30-day undo. Canonicalize one owned duplicate calendar pair: copy fields unique to the archived event onto keep_event_id, then recoverably archive archive_event_id (archived_at + canonical_id). Person tags stay on the archived row (restorable). Preview with preview_destructive_change({tool:"cleanup_duplicate_events",arguments:{keep_event_id,archive_event_id}}). Reviewed and reversible: first call preview_destructive_change({ tool: "cleanup_duplicate_events", arguments: { keep_event_id, archive_event_id } }), which stores the exact change without applying it. After the user confirms, call cleanup_duplicate_events 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": {
      "keep_event_id": "<keep_event_id>",
      "archive_event_id": "<archive_event_id>",
      "preview_id": "<preview_id>",
      "restore_window_acknowledged": "<restore_window_acknowledged>",
      "request_id": "<request_id>"
    },
    "name": "cleanup_duplicate_events"
  }
}

Input Schema

Name	Required	Description
`preview_id`	Yes	preview_id returned by preview_destructive_change for this tool.
`request_id`	Yes	Required idempotency key; retries return the original receipt.
`keep_event_id`	Yes	Survivor event_id from get_events (kept active).
`idempotency_key`	No	Alias for request_id.
`archive_event_id`	Yes	Redundant event_id from get_events (archived, restorable).
`survivor_event_id`	No	Alias of keep_event_id.
`canonical_event_id`	No	Alias of keep_event_id.
`duplicate_event_id`	No	Alias of archive_event_id.
`restore_window_acknowledged`	Yes	Must be true after reviewing the preview and its 30-day restore window.

Output Schema

Name	Required	Description
`keep`	No
`account`	No	The Dayze account this data belongs to. With more than one Dayze connection, name it in the answer.
`archive`	No
`link_moves`	No
`preview_id`	No
`provenance`	No	Which connector wrote the record and which connected Dayze account received it.
`restore_id`	No	Pass to restore_change to undo within restore_window_days.
`reversible`	No
`field_copies`	No
`preview_text`	No
`keep_event_id`	No
`archive_event_id`	No
`idempotent_replay`	No
`restore_expires_at`	No
`restore_window_days`	No
`attendees_retained_on_archive`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, and the description adds substantial context beyond them: the 30-day undo window, the restore_id receipt, that person tags remain on the archived row and are restorable, that a changed record is refused, plus cost ($0.10) and API key requirement. The only minor gap is that it repeats the preview instruction twice rather than adding new behavioral detail the second time.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The preview instruction is stated twice in near-identical form ("Preview with preview_destructive_change({tool:...,arguments:{...}})" and then "first call preview_destructive_change({ tool: ..., arguments: { ... } })"), roughly duplicating a full sentence. The content is front-loaded and accurate, but the repetition costs space that could have described the alias parameters or the output receipt.

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 destructive, multi-parameter mutation with a required preview handshake, the description covers the entry path, the apply path, the undo path, the refusal condition, cost, and auth. Since an output schema exists, it need not enumerate return fields, and mentioning restore_id is sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so per the baseline the schema already documents all nine parameters including aliases. The description still adds ordering semantics the schema cannot express — which parameters belong to the preview call versus the apply call, and that restore_window_acknowledged must follow user review — which is genuine value beyond the field descriptions.

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 — canonicalize one owned duplicate calendar pair by copying unique fields onto keep_event_id and recoverably archiving archive_event_id — and names the exact write outcome (archived_at + canonical_id). An agent can distinguish this from preview_destructive_change and restore_change without opening any schema.

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 two-step workflow: first call preview_destructive_change with the two event ids, then after user confirmation call this tool with preview_id, restore_window_acknowledged: true and request_id. It also names the inverse operation (restore_change for 30 days) and the refusal condition when the reviewed record changed.

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

All Dayze — Life Context 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.