Dayze — Life Context

Update Moment (patch a story)

update_moment

Patch one owned moment by moment_id (from log_moment); fields left out are untouched. It stays private. Requires moment_id. Patchable: title, description, moment_date, moment_date_precision, end_date, moment_type, location_name, people, event_id, images, tags. Unknown or other-user moment_id returns an error and creates nothing. person_ids / people_names, media_urls and tags replace the stored list ([] clears); event_id links an owned event (the event is not changed), empty or null unlinks. Visibility is not an argument. Returns changed_fields. Requires API key or OAuth with context.write. ($0.10; API key required)

Input Schema

TableJSON Schema

Name	Required	Description
`date`	No	Alias for moment_date.
`tags`	No	Replaces the tags. [] clears.
`title`	No	New title (max 200). Cannot be empty.
`end_date`	No	YYYY-MM-DD. Empty or null clears.
`event_id`	No	Link the moment to an owned event (the event is not changed). Empty or null unlinks.
`location`	No	Alias for location_name.
`moment_id`	Yes	UUID of a moment the user owns (from log_moment).
`media_urls`	No	Replaces the image links. [] clears.
`person_ids`	No	Replaces the tagged people (with people_names). [] clears. Owned contact ids only.
`request_id`	No	Client idempotency key (retries return original result).
`description`	No	Replaces the story text. Empty or null clears.
`moment_date`	No	YYYY-MM-DD, YYYY-MM or YYYY (alias date).
`moment_time`	No	Optional local HH:mm or HH:mm:ss. Empty or null clears (date-only).
`moment_type`	No	Default memory.
`people_names`	No	Replaces the tagged people (with person_ids); names match saved contacts only.
`location_name`	No	Replaces the place. Empty or null clears. Alias: location.
`cover_image_url`	No	https image link. Empty or null clears.
`idempotency_key`	No	Alias for request_id.
`moment_date_precision`	No	How exact the date is. YYYY-MM and YYYY default to month and year; circa for "around then".

Output Schema

TableJSON Schema

Name	Required	Description
`moment`	Yes	A moment: a story or memory, private to the owner. event_id links the event it is about.
`account`	No	The Dayze account this data belongs to. With more than one Dayze connection, name it in the answer.
`message`	Yes
`provenance`	No	Which connector wrote the record and which connected Dayze account received it.
`invalidates`	No
`people_tagged`	Yes
`changed_fields`	Yes	The columns this call changed; empty when nothing differed.
`unresolved_people`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedOct 3, 2026
- addedOutput schema / properties / moment / properties / ai_summary
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```
- addedOutput schema / properties / moment / properties / is_featured
```
Added value: +{
+  "type": "boolean"
+}
```
- addedOutput schema / properties / moment / properties / is_pinned
```
Added value: +{
+  "type": "boolean"
+}
```
- addedOutput schema / properties / moment / properties / is_recurring
```
Added value: +{
+  "type": "boolean"
+}
```
- addedOutput schema / properties / moment / properties / location_lat
```
Added value: +{
+  "type": [
+    "number",
+    "null"
+  ]
+}
```
- addedOutput schema / properties / moment / properties / location_lng
```
Added value: +{
+  "type": [
+    "number",
+    "null"
+  ]
+}
```
- addedOutput schema / properties / moment / properties / location_place_id
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```
- addedOutput schema / properties / moment / properties / merged_provenance
```
Added value: +{
+  "items": {
+    "additionalProperties": true,
+    "type": "object"
+  },
+  "type": "array"
+}
```
- addedOutput schema / properties / moment / properties / recurrence_rule
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```
- addedOutput schema / properties / moment / properties / sentiment
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```

Changed2 schema fields changedOct 3, 2026

addedOutput schema / properties / account

Added value: +{
+  "additionalProperties": false,
+  "description": "The Dayze account this data belongs to. With more than one Dayze connection, name it in the answer.",
+  "properties": {
+    "display_name": {
+      "description": "Account display name.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "handle": {
+      "description": "Account handle, e.g. @goh.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "note": {
+      "description": "How to disclose the account to the user.",
+      "type": "string"
+    },
+    "qa_fixture": {
+      "description": "True for a known QA test account: its records are fixture data, not a real life.",
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "handle",
+    "display_name",
+    "qa_fixture",
+    "note"
+  ],
+  "type": "object"
+}

addedOutput schema / properties / provenance

Added value: +{
+  "additionalProperties": false,
+  "description": "Which connector wrote the record and which connected Dayze account received it.",
+  "properties": {
+    "account": {
+      "additionalProperties": false,
+      "description": "The Dayze account this data belongs to. With more than one Dayze connection, name it in the answer.",
+      "properties": {
+        "display_name": {
+          "description": "Account display name.",
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "handle": {
+          "description": "Account handle, e.g. @goh.",
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "note": {
+          "description": "How to disclose the account to the user.",
+          "type": "string"
+        },
+        "qa_fixture": {
+          "description": "True for a known QA test account: its records are fixture data, not a real life.",
+          "type": "boolean"
+        }
+      },
+      "required": [
+        "handle",
+        "display_name",
+        "qa_fixture",
+        "note"
+      ],
+      "type": "object"
+    },
+    "channel": {
+      "description": "Always mcp_connector.",
+      "type": "string"
+    },
+    "connector": {
+      "additionalProperties": false,
+      "properties": {
+        "kind": {
+          "description": "oauth or api_key.",
+          "type": "string"
+        },
+        "name": {
+          "description": "The connected app or API-key label shown to the account owner.",
+          "type": "string"
+        }
+      },
+      "required": [
+        "kind",
+        "name"
+      ],
+      "type": "object"
+    },
+    "source": {
+      "description": "chatgpt for ChatGPT OAuth writes; mcp for another OAuth app or API key.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "source",
+    "channel",
+    "connector",
+    "account"
+  ],
+  "type": "object"
+}

Changed1 schema field changedOct 2, 2026

addedInput schema / properties / moment_time

Added value: +{
+  "description": "Optional local HH:mm or HH:mm:ss. Empty or null clears (date-only).",
+  "type": "string"
+}

AddedOct 1, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only declare the generic readOnly/openWorld/destructive flags; the description supplies the real behavioral detail an agent needs: list fields replace wholesale with [] clearing, event_id links without mutating the event and null unlinks, visibility is not accepted, the response contains changed_fields, and the call requires an API key or OAuth with context.write at $0.10. That is substantial context beyond the structured fields.

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, identifier and patch semantics, then constraints, then side effects, then auth/cost. Every sentence carries information, though the parenthetical cost/auth clause and the long patchable-field list make it dense; a slightly tighter grouping would read better.

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?

With 19 parameters, an output schema (which covers changed_fields) and safety annotations already present, the description fills the remaining gaps: error behavior, list replacement, link/unlink semantics, auth requirements and pricing. Nothing material is missing for correct invocation.

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 enumerates which fields are patchable, explains the replace-and-clear semantics for people/media/tags, and clarifies event_id link/unlink behavior. Minor cost: it uses loose field names ('people', 'images') where the schema uses person_ids/people_names and media_urls, so the mapping takes a moment.

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+resource+scope: 'Patch one owned moment by moment_id (from log_moment)'. The parenthetical source hint and the 'owned' qualifier let an agent distinguish this from log_moment (create), delete_moment (remove) and merge_moments 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 Guidelines4/5

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

Gives clear context: patch semantics ('fields left out are untouched'), the required identifier, and the failure mode for unknown/other-user ids ('returns an error and creates nothing'). It also rules out visibility editing ('Visibility is not an argument'), which routes the agent elsewhere, but it never names the sibling tool that does handle visibility, so the routing is implicit rather than explicit.

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.