Dayze — Life Context

Update Trip

update_trip

Patch a stored trip (trip_id from get_trips or log_travel): title, city, country (null clears), start_date, end_date (YYYY-MM-DD), kind (trip|residence|soft_pin), confidence (confirmed|likely|possible; status follows as log_travel sets it), evidence (null clears). Fields left out stay. Its private calendar event from log_travel follows the title, dates and place. Inferred trips (ids starting inferred:) are calendar events: edit those with update_event. Archived trips need restore_trip first. ($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": {
      "trip_id": "<trip_id>"
    },
    "name": "update_trip"
  }
}

Input Schema

Name	Required	Description
`city`	No	A real city (not a region or state).
`kind`	No	Entry kind: trip, residence or soft_pin, e.g. trip.
`title`	No	Trip title, e.g. Tokyo spring trip.
`country`	No	Country name, e.g. Singapore.
`trip_id`	Yes	A stored trip id from get_trips, get_trip or log_travel.
`end_date`	No	YYYY-MM-DD, on or after start_date
`evidence`	No	Source note (Gmail id, booking, address); null clears it.
`confidence`	No	How certain the stay is: confirmed, likely or possible, e.g. confirmed.
`request_id`	No	Client idempotency key (retries return original result).
`start_date`	No	YYYY-MM-DD
`idempotency_key`	No	Alias for request_id.

Output Schema

Name	Required	Description
`trip`	No	The stored trip after the change.
`account`	No	The Dayze account this data belongs to. With more than one Dayze connection, name it in the answer.
`changed`	No	Each changed field: { from, to }.
`message`	No
`updated`	No
`event_id`	No	The trip's calendar event that followed the change, or null.
`provenance`	No	Which connector wrote the record and which connected Dayze account received it.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 10, 2026

TDQS

A4.2/5.0

Behavior3/5

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

Annotations only declare the safety profile (not read-only, not destructive, closed-world); the description adds genuine context beyond that with patch semantics ("fields left out stay"), null-clears behavior, the side effect on the private calendar event, status coupling to log_travel, and cost/auth requirements. The main missing piece is what happens on failed validation or partial conflicts, but the mutation surface is otherwise well disclosed. Consistent with destructiveHint=false since it is a partial patch, not a delete.

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 action and field list, followed by prerequisites and edge cases in priority order; every clause carries information. It is parenthetical-heavy and telegraphic ("(null clears)" twice, "$0.10; API key required" trailing), which slightly hurts scanability but wastes almost nothing.

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 an 11-parameter mutation tool with an output schema, the definition covers cost, auth, idempotency-adjacent guidance via schema, side effects, prerequisites for archived and inferred trips, and the sibling to use instead. Nothing an agent needs to call it correctly is left unstated.

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 schema already documents formats, enums, and null-clearing; baseline is 3. The description contributes real meaning on top: patch-omission semantics and the note that confidence's status follows whatever log_travel set, which the schema does not state.

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?

"Patch a stored trip" gives a specific verb and resource, then enumerates the mutable fields (title, city, country, dates, kind, confidence, evidence) with their value semantics. It explicitly separates itself from update_event (inferred trips) and restore_trip (archived trips), so an agent can pick correctly without opening schemas.

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?

Names the alternatives and the exact condition selecting them: inferred: ids belong to update_event, archived trips require restore_trip first. It also points to the source of valid ids (get_trips or log_travel), leaving nothing to inference.

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.