Dayze — Life Context

Update Contact (CRM write)

update_person

MUTATES one owned Dayze contact by person_id. A context_tags-only patch is supported; send the full desired tag array (a repeat is a no-op). For personal-write OAuth send request_id, a unique string for each new write; reuse it for an exact retry. Fields left out are untouched. undo_contact_change(change_id) reverts a change. Requires context.write; share tokens cannot write. ($0.10; API key required)

Input Schema

TableJSON Schema

Name	Required	Description
`name`	No	Rename contact (also refreshes URL slug). Prefer this over create+merge for spelling fixes
`tier`	No	Relationship priority. VIP stays in inner_circle even when not favorited
`notes`	No	Replaces people.notes (does not append). Empty or null clears
`birthday`	No	YYYY, YYYY-MM, YYYY-MM-DD, or MM-DD / --MM-DD (year unknown; 02-29 ok). Null/empty clears
`person_id`	Yes	UUID of a person the authenticated user owns
`request_id`	No	Required on personal-write OAuth. Unique for a new write; reuse for an exact retry.
`is_favorite`	No	Favorite flag. Favorites (and VIP) appear in get_context_pack inner_circle
`context_tags`	No	Contexts such as Work, Personal, Family, plus custom tags
`relationship`	No	Relationship label (friend, sister, …). Empty or null clears
`relationships`	No	Who they are to the user, in primary-first order (for example Friend + Client)
`idempotency_key`	No	Alias for request_id.
`preserve_old_name_as_alias`	No	When renaming, keep the previous name as a former_name alias (default true)

Output Schema

TableJSON Schema

Name	Required	Description
`person`	Yes	A Dayze person or contact record.
`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.
`change_id`	No	Pass to undo_contact_change to revert this change, birthday and birthday_precision included.
`provenance`	No	Which connector wrote the record and which connected Dayze account received it.
`former_name_alias`	No	After a rename that keeps the old name (preserve_old_name_as_alias, default true): alias, saved, and reason when it could not be kept.
`life_state_rebuilt`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 3, 2026

changedInput schema / properties / request_id / description

Previous value: -"Client idempotency key (retries return original result)."New value: +"Required on personal-write OAuth. Unique for a new write; reuse for an exact retry."

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 changedSep 28, 2026

addedOutput schema / properties / change_id

Added value: +{
+  "description": "Pass to undo_contact_change to revert this change, birthday and birthday_precision included.",
+  "type": "string"
+}

Changed2 schema fields changedSep 28, 2026

changedInput schema / properties / birthday / description

Previous value: -"YYYY, YYYY-MM, YYYY-MM-DD, or MM-DD / --MM-DD (year unknown). Null/empty clears"New value: +"YYYY, YYYY-MM, YYYY-MM-DD, or MM-DD / --MM-DD (year unknown; 02-29 ok). Null/empty clears"

addedOutput schema / properties / former_name_alias

Added value: +{
+  "additionalProperties": true,
+  "description": "After a rename that keeps the old name (preserve_old_name_as_alias, default true): alias, saved, and reason when it could not be kept.",
+  "type": "object"
+}

Changed2 schema fields changedSep 27, 2026

addedInput schema / properties / context_tags

Added value: +{
+  "description": "Contexts such as Work, Personal, Family, plus custom tags",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / relationships

Added value: +{
+  "description": "Who they are to the user, in primary-first order (for example Friend + Client)",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

Changed1 schema field changedSep 14, 2026

addedInput schema / properties / preserve_old_name_as_alias

Added value: +{
+  "description": "When renaming, keep the previous name as a former_name alias (default true)",
+  "type": "boolean"
+}

Changed2 schema fields changedSep 13, 2026

changedInput schema / properties / birthday / description

Previous value: -"YYYY, YYYY-MM, or YYYY-MM-DD. Null/empty clears"New value: +"YYYY, YYYY-MM, YYYY-MM-DD, or MM-DD / --MM-DD (year unknown). Null/empty clears"

addedInput schema / properties / name

Added value: +{
+  "description": "Rename contact (also refreshes URL slug). Prefer this over create+merge for spelling fixes",
+  "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"
+    },
+    "life_state_rebuilt": {
+      "type": "boolean"
+    },
+    "person": {
+      "additionalProperties": true,
+      "description": "A Dayze person or contact record.",
+      "type": "object"
+    }
+  },
+  "required": [
+    "person",
+    "changed",
+    "life_state_rebuilt"
+  ],
+  "type": "object"
+}

AddedAug 29, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Adds substantial context beyond the annotations: partial-update semantics (omitted fields untouched), full-array replacement for context_tags, idempotency/retry behavior for request_id, the undo path, and hard auth constraints (context.write required, share tokens cannot write). Cost and API-key requirements are also disclosed — more than the non-destructive annotation conveys.

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-loads the mutation scope, then packs idempotency, partial-update rules, undo, and auth/prerequisites efficiently. Dense but every sentence carries weight; slightly telegraphic ending with cost and API-key notes.

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 a 12-parameter mutation tool with an output schema (so return values need no explanation), the description closes the important gaps: auth requirements, idempotency, partial-update semantics, and a revert path. Nothing an agent needs to invoke it correctly is missing.

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 all 12 parameters and the baseline is 3. The description adds real semantics for context_tags (full-array semantics, repeats are no-ops) but repeats rather than extends the schema's request_id/idempotency explanation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and scope — 'MUTATES one owned Dayze contact by person_id' — so the agent knows it is a targeted partial update rather than an identity/alias edit. It does not explicitly distinguish itself from close siblings like update_person_identity or update_person_alias, which would have earned a 5.

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 operational context: context_tags-only patches are allowed, fields left out are untouched, request_id is required for personal-write OAuth, and undo goes through undo_contact_change. It stops short of naming alternatives for the fields it does not cover (e.g. identity vs alias tools), so no explicit exclusion routing.

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.