Dayze — Life Context

Delete TV Watch

delete_tv_watch

Destructive

Preview first, 30-day undo. Remove one TV Diary row (a watch or a To Watch entry; watch_id from get_watch_history) and archive its calendar entry. Reviewed and reversible: first call preview_destructive_change({ tool: "delete_tv_watch", arguments: { watch_id } }), which stores the exact change without applying it. After the user confirms, call delete_tv_watch 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": {
      "watch_id": "<watch_id>",
      "preview_id": "<preview_id>",
      "restore_window_acknowledged": "<restore_window_acknowledged>",
      "request_id": "<request_id>"
    },
    "name": "delete_tv_watch"
  }
}

Input Schema

Name	Required	Description
`watch_id`	Yes	watch_id from get_watch_history or log_tv_watch.
`preview_id`	Yes	preview_id returned by preview_destructive_change for this tool.
`request_id`	Yes	Required idempotency key; retries return the original receipt.
`idempotency_key`	No	Alias for request_id.
`restore_window_acknowledged`	Yes	Must be true after reviewing the preview and its 30-day restore window.

Output Schema

Name	Required	Description
`kind`	No
`account`	No	The Dayze account this data belongs to. With more than one Dayze connection, name it in the answer.
`deleted`	Yes	The removed diary row, with its title.
`event_id`	No
`watch_id`	Yes
`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
`idempotent_replay`	No
`life_state_rebuilt`	No
`restore_expires_at`	No
`restore_window_days`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 4, 2026

TDQS

A4.2/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the danger profile is structured data. The description adds real context beyond that: the preview is stored without applying, a changed record is refused, the result carries a restore_id, the undo window is 30 days unless the record was edited, plus cost ($0.10) and API key requirement. Return shape is covered by the output schema, so the 30-day/refusal details are the main genuine addition.

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 essential contract ("Preview first, 30-day undo") before the mechanics. It is dense and carries nested parentheticals plus a trailing cost/API-key note, but almost every clause conveys a distinct operational fact; only the cost parenthetical is arguably peripheral.

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 mutation with a mandatory two-step gate, the description covers the precondition, the exact call shape after confirmation, the refusal on changed records, and the undo path. An output schema exists, so the return value need only be named (restore_id), which it is.

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 every parameter is already documented in the schema, including request_id as an idempotency key and the restore_window_acknowledged precondition. The description's contribution is tying them into a call sequence (preview_id must come from a preview of this same tool and the ack must be true), which the schema alone does not express — useful but incremental against a full-coverage schema.

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 — "Remove one TV Diary row (a watch or a To Watch entry)... and archive its calendar entry" — with the scope narrowed to a single row and the ID source (get_watch_history) named. This distinguishes it from delete_movie_watch and delete_event without the agent needing to open 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 ordered workflow: preview_destructive_change first with the exact arguments shape, then delete_tv_watch after user confirmation, and restore_change within 30 days for undo. The alternative path (preview, restore) and the precondition (user confirms) are both spelled out rather than inferred.

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.