Dayze — Life Context

Add Condition

create_condition

Add a private condition for an explicit subject_type: self, or person plus an owned person_id from get_people/resolve_person. Never turn a family member's condition into self; if the person is unresolved, ask and write nothing. status defaults suspected—never infer active or confirmed from a mention. Keep the user's words; source defaults user_reported and confirmation_status reported. ($0.10; API key required)

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	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.
`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.
`created`	No
`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
`already_existed`	No	true: an open condition with this name exists; it came back unchanged.
`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: -[
-  "name"
-]New value: +[
+  "name",
+  "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.8/5.0

Behavior5/5

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

Annotations only declare the safety profile (non-read, non-destructive), while the description adds real behavioral context: privacy of the record, cost ($0.10), API-key requirement, defaults for status/source/confirmation_status, and the no-write-if-unresolved rule. This is substantial value beyond the annotations and does not contradict them.

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?

Purpose and the subject_type rule are front-loaded, then defaults, then cost/auth. Every clause carries a rule or fact, though the density is high and the trailing cost/API-key note reads as appended rather than integrated.

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 14 parameters, high schema coverage, and an output schema present, the description need not explain return values. It supplies exactly the missing pieces—usage rules, defaults, privacy, and cost/auth—so an agent has everything required to call it correctly.

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 93%, so the baseline is 3; the description goes beyond it by reinforcing defaults (suspected, user_reported, reported) and adding a semantic guardrail—never infer active/confirmed from a mention and keep the user's words. These add meaning for the enum/default parameters the schema alone does not fully constrain.

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 ("Add a private condition") plus the scoping rule (subject_type self or person). The create semantics implicitly distinguish it from the sibling update_condition, and the "private" qualifier adds scope an agent would not otherwise know.

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?

Gives explicit when-to-use rules and exclusions: use self or a person with an owned person_id from get_people/resolve_person, never turn a family member into self, and if the person is unresolved ask and write nothing. It even routes to the sibling tools needed to resolve the person first.

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.