Skip to main content
Glama
Sign In

Dayze — Life Context

by com.dayze
OverviewDiscussionsAdmin

Update TV Watch

update_tv_watch

Change a TV Diary watch by watch_id: rating (null clears), watched_at or notes. Nothing else changes. ($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>"
    },
    "name": "update_tv_watch"
  }
}

Input Schema

NameRequiredDescriptionDefault
notesNoReplaces the note; null clears it.
ratingNonull clears it.
watch_idYeswatch.watch_id from the log tool.
request_idNoClient idempotency key (retries return original result).
watched_atNoLocal YYYY-MM-DD (last night = yesterday), or YYYY-MM-DDTHH:MM if they gave a time. Omit for now.
idempotency_keyNoAlias for request_id.
watched_at_precisionNoapproximate when a part of day was read as a time.

Output Schema

NameRequiredDescriptionDefault
watchNo
accountNoThe Dayze account this data belongs to. With more than one Dayze connection, name it in the answer.
messageNo
provenanceNoWhich connector wrote the record and which connected Dayze account received it.
changed_fieldsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the safety profile is covered elsewhere. The description does add value beyond annotations by disclosing the $0.10 cost, the API-key requirement, and partial-update semantics ('Nothing else changes'), plus the 'null clears' behavior. It does not mention idempotency/retry behavior, which the schema alone carries, so this is solid but not rich.

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?

Two compact sentences with the identifier and mutable field list front-loaded, and the pricing/auth parenthetical cleanly separated at the end. Every clause carries information; only the repetition of 'null clears' (already in the schema) is slightly redundant.

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?

For a mutation tool with full schema coverage, annotations, and an output schema, the description covers the essential unknown-to-schema facts: cost, auth requirement, partial-update scope, and null-clearing. Remaining details (idempotency alias, watched_at_precision) are adequately handled by the schema, so nothing critical 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 description coverage is 100%, so all seven parameters are already documented, including the 'null clears it' semantics for rating and notes and the request_id idempotency note. The description restates the three mutable field names and the null-clearing rule without adding format, range, or precision guidance beyond the schema; baseline 3 is appropriate.

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?

The description names a specific verb and resource ('Change a TV Diary watch by watch_id') and enumerates the mutable fields (rating, watched_at, notes), which lets an agent distinguish it from log_tv_watch and delete_tv_watch. It never names update_movie_watch explicitly, so sibling differentiation is implicit rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'by watch_id' and 'Nothing else changes' imply this is for editing an existing entry rather than creating one, and that other fields are off-limits. However, there is no explicit instruction such as 'use log_tv_watch to create a new watch' or any statement of prerequisites, so the agent must infer the when-to-use boundary.

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 toolsInspect
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