Dayze — Life Context

Log TV Watch

log_tv_watch

Destructive

Log a TV show the user watched to their TV Diary (the tv page, with its poster), not log_event or log_moment: season, episode (episode_end for a range), finished_season, plus the same fields as log_movie_watch. The same show, season and episode on the same day returns the stored watch (duplicate: true). A watch of the whole show takes it off To Watch; episodes do not. Private by default. ($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": {
      "title": "<title>"
    },
    "name": "log_tv_watch"
  }
}

Input Schema

Name	Required	Description
`with`	No	Who with; only their contacts are kept.
`year`	No	Premiere year.
`notes`	No	Their note or reaction.
`title`	Yes	As the user named it.
`where`	No	Cinema, home, flight …
`rating`	No	Their score out of 10, only if given.
`season`	No	TV season number, e.g. 2.
`episode`	No	The episode, or the first of a range.
`imdb_id`	No	tt… when known.
`rewatch`	No	They watched it again.
`person_ids`	No	Contact ids, e.g. ["3f2a1b4c-8d9e-6f01-c2b3-c4d5e6f70809"].
`request_id`	No	Client idempotency key (retries return original result).
`visibility`	No	Who can see the watch: private, friends or public, e.g. private.
`watched_at`	No	Local YYYY-MM-DD (last night = yesterday), or YYYY-MM-DDTHH:MM if they gave a time. Omit for now.
`episode_end`	No	Last episode of a range.
`finished_season`	No	They finished the season.
`idempotency_key`	No	Alias for request_id.
`watched_at_precision`	No	approximate when a part of day was read as a time.

Output Schema

Name	Required	Description
`watch`	No	The diary entry: watch_id, title, season, episode, watched_on, rating, poster_url, visibility.
`account`	No	The Dayze account this data belongs to. With more than one Dayze connection, name it in the answer.
`created`	No
`message`	No
`duplicate`	No	True when the same show and episode was already logged that day; nothing was added.
`provenance`	No	Which connector wrote the record and which connected Dayze account received it.
`inspect_url`	No	The Dayze page that shows the saved record.
`inspect_note`	No	What inspect_url opens. Never quote the record id.
`people_tagged`	No
`catalog_created`	No
`unresolved_people`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedNov 9, 2026
- addedInput schema / properties / person_ids / description
```
Added value: +"Contact ids, e.g. [\"3f2a1b4c-8d9e-6f01-c2b3-c4d5e6f70809\"]."
```
- addedInput schema / properties / person_ids / items / description
```
Added value: +"Contact id, e.g. 3f2a1b4c-8d9e-6f01-c2b3-c4d5e6f70809."
```
- addedInput schema / properties / season / description
```
Added value: +"TV season number, e.g. 2."
```
- addedInput schema / properties / visibility / description
```
Added value: +"Who can see the watch: private, friends or public, e.g. private."
```
- addedInput schema / properties / with / items / description
```
Added value: +"Companion name, e.g. Alex."
```
AddedNov 4, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing dedup semantics ('same show, season and episode on the same day returns the stored watch (duplicate: true)'), a side effect on another collection ('a watch of the whole show takes it off To Watch; episodes do not'), default visibility, per-call cost, and the API-key requirement. This explains the destructiveHint=true consequence in concrete terms rather than leaving the agent to guess.

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 action and destination, then the disambiguation, then behavioral consequences — a sensible ordering with every clause carrying information. The telegraphic, parenthesis-heavy phrasing ('season, episode (episode_end for a range), finished_season') is dense and slightly cryptic on first read but wastes no words.

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?

Given an output schema exists, the description needn't explain returns, yet it still conveys the duplicate-result shape and the To Watch side effect. Cost, auth, privacy default, and sibling routing are all covered, leaving nothing an agent needs before calling a mutation tool of this complexity.

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 the baseline is 3, but the description adds real meaning: it identifies season/episode as the TV-specific discriminator, explains episode_end as a range, and defers the remaining shared fields to log_movie_watch rather than restating them. It doesn't document the range edge cases (e.g. episode_end < episode) or the idempotency alias, so it stays short of exhaustive.

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 ('Log a TV show the user watched to their TV Diary') and pins down the destination ('the tv page, with its poster'). It also names what it is not ('not log_event or log_moment'), so an agent can distinguish it from the nearest ambiguous siblings without opening a schema.

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?

Explicitly excludes log_event and log_moment and explains its relationship to log_movie_watch ('the same fields as log_movie_watch'), which is genuinely useful routing for an 18-param tool. It does not mention update_tv_watch or delete_tv_watch as alternatives when correcting an existing entry, so the guidance is clear but not exhaustive.

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.