Dayze — Life Context

Update Condition

update_condition

Patch a condition by condition_id with its explicit subject_type (and person_id for a contact). The subject must match. Patch status, confirmation_status, source or condition fields; omitted fields stay untouched and null clears nullable text. Never infer active/confirmed. ($0.10; API key required)

Input Schema

TableJSON Schema

Name	Required	Description
`name`	No	What the user calls it, in their words (e.g. "Blurry near vision"). Never a diagnosis they did not give.
`notes`	No
`source`	No	Provenance, e.g. user_reported. Default user_reported.
`status`	No	suspected (default for a new one) \| active \| improving \| resolved.
`symptoms`	No	What they notice, e.g. "Blurry at near distance, worse in the evening".
`body_area`	No	Where, e.g. "Left eye".
`person_id`	No	Owned contact id; required for person.
`request_id`	No	Client idempotency key (retries return original result).
`started_on`	No	YYYY-MM-DD it started (onset). Default for a new one: today.
`treatments`	No	What they use or do for it.
`condition_id`	Yes	From get_conditions or create_condition.
`subject_type`	Yes	self, or person with person_id.
`tracking_focus`	No	What to watch on each check-in.
`idempotency_key`	No	Alias for request_id.
`confirmation_status`	No	unconfirmed \| reported (default) \| confirmed; never infer confirmed.

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.
`message`	No
`condition`	No	A private condition with explicit subject_type/person_id, source and confirmation_status.
`provenance`	No	Which connector wrote the record and which connected Dayze account received it.
`condition_id`	No
`changed_fields`	No
`idempotent_replay`	No	true when this request_id already ran: the first result, nothing new written.

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 changedOct 3, 2026

addedInput schema / properties / confirmation_status

Added value: +{
+  "description": "unconfirmed | reported (default) | confirmed; never infer confirmed.",
+  "enum": [
+    "unconfirmed",
+    "reported",
+    "confirmed"
+  ],
+  "type": "string"
+}

addedInput schema / properties / person_id

Added value: +{
+  "description": "Owned contact id; required for person.",
+  "type": "string"
+}

addedInput schema / properties / source

Added value: +{
+  "description": "Provenance, e.g. user_reported. Default user_reported.",
+  "type": "string"
+}

addedInput schema / properties / subject_type

Added value: +{
+  "description": "self, or person with person_id.",
+  "enum": [
+    "self",
+    "person"
+  ],
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "condition_id"
-]New value: +[
+  "condition_id",
+  "subject_type"
+]

changedOutput schema / properties / condition / description

Previous value: -"An owner health condition: condition_id, name, status, confirmed, sensitivity, symptoms, body_area, started_on, resolved_on, tracking_focus, treatments, notes, latest_checkin."New value: +"A private condition with explicit subject_type/person_id, source and confirmation_status."

Changed1 schema field changedOct 3, 2026

changedOutput schema / properties / condition / description

Previous value: -"A private health condition: condition_id, name, status, confirmed, symptoms, body_area, started_on, resolved_on, tracking_focus, treatments, notes, latest_checkin."New value: +"An owner health condition: condition_id, name, status, confirmed, sensitivity, symptoms, body_area, started_on, resolved_on, tracking_focus, treatments, notes, latest_checkin."

AddedSep 30, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations only declare readOnlyHint=false and destructiveHint=false; the description goes further by stating patch semantics (omitted fields untouched, null clears nullable text), an explicit safety rule (never infer active/confirmed), the auth requirement (API key required) and cost ($0.10). This is meaningful disclosure beyond the structured fields, though reversibility and error behavior are not covered.

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?

One dense paragraph, front-loaded with the identifying keys before the patch semantics and the invariant. Every sentence carries information (semantics, invariant, auth/cost), though the parenthetical cost/API-key tail is slightly tacked on.

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?

With an output schema present, return values need not be described, and the annotations plus description cover the safety profile, patching rules, and required identity fields for a 15-parameter mutation. What is missing is only guidance on alternatives (create_condition) and what happens on a subject mismatch (error vs no-op).

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 already 93%, so the baseline is 3. The description adds genuine semantics on top: explicit subject_type matching, person_id for contacts, and the null-vs-omitted distinction that the schema does not state per-parameter. It stops short of touching the many optional text fields (name, notes, symptoms, treatments).

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 (patch a condition) plus the identity mechanics (condition_id with its explicit subject_type). It is clearly distinguishable from the create_condition and log_condition_checkin siblings, and the 'subject must match' clause tells the agent what the call is keyed on.

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?

It implies usage (patching an existing, already-identified condition) and gives invariants such as 'Never infer active/confirmed' and 'omitted fields stay untouched'. However it never explicitly names the alternative (create_condition) or states the when-not-to-use condition, so routing between siblings is left partly 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.