Dayze — Life Context

Create Contact

create_person

Add a Dayze Contacts record, birthday included (YYYY-MM-DD, YYYY-MM, YYYY, or MM-DD if year unknown); checks duplicates first. An existing contact comes back unchanged with its person_id, not_applied (the fields you sent) and a hint. request_id is optional: without one, identical calls within 15 minutes return the first result. Advertised name create_person is stable; tools/call also accepts create_contact. ($0.10; API key required)

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes
`tier`	No
`email`	No
`notes`	No
`phone`	No
`aliases`	No
`birthday`	No	YYYY-MM-DD, YYYY-MM, YYYY, or MM-DD / --MM-DD when the year is unknown (same as update_person)
`request_id`	No	Client idempotency key (retries return original result).
`is_favorite`	No
`context_tags`	No
`relationship`	No
`relationships`	No
`idempotency_key`	No	Alias for request_id.

Output Schema

TableJSON Schema

Name	Required	Description
`id`	No
`code`	No
`hint`	No
`name`	No
`slug`	No
`people`	No
`person`	No	CRM person record.
`account`	No	The Dayze account this data belongs to. With more than one Dayze connection, name it in the answer.
`aliases`	No	Aliases saved on the new contact.
`created`	No
`message`	No
`skipped`	No
`birthday`	No	As stored: YYYY-MM-DD. A year-unknown birthday is 1900-MM-DD (Feb 29: 1904-02-29).
`duplicate`	No	True when the contact already existed: nothing on it was changed.
`person_id`	No	The new contact, or the existing one on a duplicate.
`created_at`	No
`person_ids`	No
`provenance`	No	Which connector wrote the record and which connected Dayze account received it.
`matched_via`	No
`not_applied`	No	On a duplicate: the fields sent that were not saved.
`role_expand`	No
`hygiene_flags`	No
`aliases_not_saved`	No	Aliases not saved (another contact has them); the contact was still created.
`idempotent_replay`	No
`birthday_precision`	No	day, month, year, month_day (year unknown) or approximate.

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

Changed4 schema fields changedOct 2, 2026

addedOutput schema / properties / code
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / hygiene_flags

Added value: +{
+  "items": {
+    "additionalProperties": true,
+    "description": "Import hygiene skip/review flags.",
+    "type": "object"
+  },
+  "type": "array"
+}

changedOutput schema / properties / message / type

Previous value: -[
-  "string",
-  "null"
-]New value: +"string"

addedOutput schema / properties / skipped
```
Added value: +{
+  "type": "boolean"
+}
```

Changed17 schema fields changedSep 28, 2026

addedOutput schema / properties / aliases

Added value: +{
+  "description": "Aliases saved on the new contact.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / aliases_not_saved

Added value: +{
+  "description": "Aliases not saved (another contact has them); the contact was still created.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "alias": {
+        "type": "string"
+      },
+      "reason": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "alias",
+      "reason"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / birthday

Added value: +{
+  "description": "As stored: YYYY-MM-DD. A year-unknown birthday is 1900-MM-DD (Feb 29: 1904-02-29).",
+  "type": "string"
+}

addedOutput schema / properties / birthday_precision

Added value: +{
+  "description": "day, month, year, month_day (year unknown) or approximate.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / created_at
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / duplicate

Added value: +{
+  "description": "True when the contact already existed: nothing on it was changed.",
+  "type": "boolean"
+}

addedOutput schema / properties / hint
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / id
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / idempotent_replay
```
Added value: +{
+  "type": "boolean"
+}
```

addedOutput schema / properties / matched_via

Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / name
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / not_applied

Added value: +{
+  "description": "On a duplicate: the fields sent that were not saved.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / people

Added value: +{
+  "items": {
+    "additionalProperties": true,
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / person_id

Added value: +{
+  "description": "The new contact, or the existing one on a duplicate.",
+  "type": "string"
+}

addedOutput schema / properties / person_ids

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / role_expand
```
Added value: +{
+  "type": "boolean"
+}
```

addedOutput schema / properties / slug

Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}

Changed3 schema fields changedSep 28, 2026

addedInput schema / properties / birthday

Added value: +{
+  "description": "YYYY-MM-DD, YYYY-MM, YYYY, or MM-DD / --MM-DD when the year is unknown (same as update_person)",
+  "type": "string"
+}

addedInput schema / properties / is_favorite
```
Added value: +{
+  "type": "boolean"
+}
```

addedInput schema / properties / tier / enum

Added value: +[
+  "vip",
+  "normal",
+  "low"
+]

Changed2 schema fields changedSep 27, 2026

addedInput schema / properties / context_tags

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / relationships

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

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

AddedSep 1, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=false): discloses duplicate detection, the exact shape of the existing-contact response (person_id, not_applied, hint), idempotency semantics (request_id / 15-minute dedupe window), the create_contact alias, cost ($0.10) and the API-key requirement. Rich, non-obvious behavioral context.

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 core action and birthday formats, then layers idempotency, naming and cost. Dense but mostly earn-place; the parenthetical cost/auth note and alias clause make it slightly crowded for a single paragraph.

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?

For a 13-param write tool with an output schema, it covers the important gaps: auth, cost, idempotency, duplicate handling and the existing-record return case. The main omission is meaning for the secondary filter-like params, though the output schema and self-explanatory names cover most of that.

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 description coverage is only 23%, so the description must compensate. It adds real value on the two non-obvious params (birthday formats, request_id idempotency), but leaves tier, aliases, is_favorite, context_tags, relationship(s) and idempotency_key unexplained. Most remaining params are self-evident, so this is adequate rather than thorough.

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 ('Add') and resource ('Dayze Contacts record') and is clearly distinguishable from sibling creators like create_place and create_condition. It also resolves the create_person/create_contact naming ambiguity explicitly.

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?

Implies usage through the duplicate-check behavior ('checks duplicates first'), which hints at a create-vs-update decision, but never states when to use this instead of update_person or merge_people. No explicit when-not guidance or named alternatives.

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.