Dayze — Life Context

Update Food (diary patch)

update_food

MUTATES one existing Food Diary row the authenticated user owns. Required: food_id (UUID). Optional patch (same fields as log_food): what, kind, dish_items, place, merchant, notes, append_notes (concat), consumed_at (ISO instant) / meal_period (profile TZ), amount, currency, paid_by / payment_method, with / people_names / person_ids. dish_items replaces the complete ordered dish list. Unknown or other-user food_id returns an error and does not create a row. Syncs the mirrored calendar event and rebuilds life_state. Requires API key or OAuth with scope context. Share tokens cannot write. ($0.10; API key required)

Input Schema

TableJSON Schema

Name	Required	Description
`food`	No	Alias for what.
`item`	No	Alias for what.
`kind`	No
`what`	No	Full updated dish/drink text (replaces, does not append). Example: Salmon Bento + hot tea
`with`	No	Companion names, aliases, or ids to add (does not remove existing tags)
`notes`	No	Replaces notes. Empty or null clears
`place`	No	Venue or location. Empty or null clears
`amount`	No	Price if mentioned
`dishes`	No	Alias for dish_items.
`people`	No	Alias for with
`food_id`	Yes	UUID of a food diary row the authenticated user owns
`paid_by`	No	Who paid (name or alias)
`currency`	No	ISO currency, e.g. SGD
`merchant`	No	Restaurant, stall, or shop. Empty or null clears
`dish_items`	No	Complete replacement ordered dish list; [] clears it.
`person_ids`	No	Owned person UUIDs to tag (user-scoped)
`request_id`	No	Client idempotency key (retries return original result).
`consumed_at`	No	ISO instant; wins over meal_period
`description`	No	Alias for what (the dish, not notes).
`meal_period`	No	Spoken period when consumed_at is omitted, e.g. "late lunch"
`person_name`	No	One companion to add, by name
`append_notes`	No	Append text to existing notes (newline-separated)
`people_names`	No	Alias for with
`payment_method`	No	Alias of paid_by for expense-style agents
`idempotency_key`	No	Alias for request_id.

Output Schema

TableJSON Schema

Name	Required	Description
`account`	No	The Dayze account this data belongs to. With more than one Dayze connection, name it in the answer.
`changed`	Yes	Changed fields with before and after values.
`food_id`	Yes
`event_id`	Yes
`food_log`	Yes	Updated Food Diary row.
`provenance`	No	Which connector wrote the record and which connected Dayze account received it.
`people_tagged`	Yes
`unresolved_people`	Yes
`life_state_rebuilt`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

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"
+}

Changed6 schema fields changedSep 29, 2026

addedInput schema / properties / description

Added value: +{
+  "description": "Alias for what (the dish, not notes).",
+  "type": "string"
+}

addedInput schema / properties / dishes

Added value: +{
+  "description": "Alias for dish_items.",
+  "type": "array"
+}

addedInput schema / properties / food

Added value: +{
+  "description": "Alias for what.",
+  "type": "string"
+}

addedInput schema / properties / item

Added value: +{
+  "description": "Alias for what.",
+  "type": "string"
+}

addedInput schema / properties / people

Added value: +{
+  "description": "Alias for with",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / person_name

Added value: +{
+  "description": "One companion to add, by name",
+  "type": "string"
+}

Changed1 schema field changedSep 26, 2026

addedInput schema / properties / dish_items

Added value: +{
+  "description": "Complete replacement ordered dish list; [] clears it.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "name": {
+        "type": "string"
+      },
+      "price": {
+        "minimum": 0,
+        "type": "number"
+      },
+      "rating": {
+        "maximum": 5,
+        "minimum": 1,
+        "type": "number"
+      }
+    },
+    "required": [
+      "name"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

Changed1 schema field changedSep 24, 2026

changedInput schema / properties / consumed_at / description

Previous value: -"ISO 8601 datetime; wins over meal_period"New value: +"ISO instant; wins over meal_period"

Changed2 schema fields changedSep 11, 2026

addedInput schema / properties / append_notes

Added value: +{
+  "description": "Append text to existing notes (newline-separated)",
+  "type": "string"
+}

addedInput schema / properties / payment_method

Added value: +{
+  "description": "Alias of paid_by for expense-style agents",
+  "type": "string"
+}

Changed2 schema fields changedSep 4, 2026

addedInput schema / properties / idempotency_key

Added value: +{
+  "description": "Alias for request_id.",
+  "type": "string"
+}

addedInput schema / properties / request_id

Added value: +{
+  "description": "Client idempotency key (retries return original result).",
+  "type": "string"
+}

Changed1 schema field changedAug 31, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "properties": {
+    "changed": {
+      "additionalProperties": true,
+      "description": "Changed fields with before and after values.",
+      "type": "object"
+    },
+    "event_id": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "food_id": {
+      "type": "string"
+    },
+    "food_log": {
+      "additionalProperties": true,
+      "description": "Updated Food Diary row.",
+      "type": "object"
+    },
+    "life_state_rebuilt": {
+      "type": "boolean"
+    },
+    "people_tagged": {
+      "items": {
+        "additionalProperties": true,
+        "description": "A Dayze person or contact record.",
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "unresolved_people": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "food_id",
+    "event_id",
+    "food_log",
+    "changed",
+    "people_tagged",
+    "unresolved_people",
+    "life_state_rebuilt"
+  ],
+  "type": "object"
+}

AddedAug 31, 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 side effects (syncs the mirrored calendar event, rebuilds life_state), auth constraints (API key/OAuth scope, share tokens cannot write), error behavior for unknown/other-user food_id, and mutation semantics like append_notes concatenation and dish_items full replacement. Annotation says destructiveHint=false and nothing here contradicts that.

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?

Dense but front-loaded, with the core mutation scope stated first. Each clause carries information (auth, side effects, param semantics), though it runs long and could be broken up for readability.

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 an output schema present and annotations covering safety, the description supplies everything else an agent needs: required field, auth requirements, error conditions, side effects, and mutation semantics. Nothing material is missing for a 25-param mutation tool.

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 96%, so the schema already documents most parameters. The description adds grouping (same fields as log_food), precedence (consumed_at wins over meal_period), and concat-vs-replace distinctions for notes and dish_items, giving useful meaning beyond the 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?

Starts with a specific verb and scope ('MUTATES one existing Food Diary row the authenticated user owns'), which cleanly separates it from log_food (create) and delete_food (remove). The required food_id (UUID) and ownership constraint make the resource unambiguous.

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?

Implies update-vs-create semantics and clarifies it will not fall back to creating a row ('does not create a row'), effectively routing the agent to log_food for new entries. It also states auth requirements (API key/OAuth; share tokens cannot write). No explicit 'use X instead when' routing, but context is clear.

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.