Dayze — Life Context

Log Place Visit

log_place_visit

MUTATES place_visits for map/history digs (Uber dropoff, address evidence). Required: place (or place_id) + arrived_at/date. Optional: departed_at, source (uber|mcp|…), evidence_expense_id (idempotent), city/country/address. Prefer this over stuffing streets only into expenses. ($0.10; API key required)

Input Schema

TableJSON Schema

Name	Required	Description
`city`	No
`date`	No	Alias for arrived_at
`name`	No	Alias for place
`place`	No
`source`	No
`address`	No
`country`	No
`place_id`	No
`arrived_at`	No	ISO or YYYY-MM-DD
`confidence`	No
`request_id`	No	Client idempotency key (retries return original result).
`departed_at`	No
`idempotency_key`	No	Alias for request_id.
`evidence_event_id`	No
`evidence_expense_id`	No

Output Schema

TableJSON Schema

Name	Required	Description
`place`	No	Canonical place record.
`visit`	No	Confirmed same-day outing with visit_date and evidence_refs. A typed place_visits row is primary and carries visit_id (= id); linked event/GPS evidence is reconciled without increasing the count.
`account`	No	The Dayze account this data belongs to. With more than one Dayze connection, name it in the answer.
`message`	No
`place_id`	No
`duplicate`	No
`provenance`	No	Which connector wrote the record and which connected Dayze account received it.
`created_place`	No

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

Changed1 schema field changedOct 3, 2026

changedOutput schema / properties / visit / description

Previous value: -"Normalized place visit. visit_id (= id) is the place_visits row id delete_place_visit takes; null on event/GPS evidence rows."New value: +"Confirmed same-day outing with visit_date and evidence_refs. A typed place_visits row is primary and carries visit_id (= id); linked event/GPS evidence is reconciled without increasing the count."

Changed1 schema field changedSep 28, 2026

changedOutput schema / properties / visit / description

Previous value: -"Normalized place visit."New value: +"Normalized place visit. visit_id (= id) is the place_visits row id delete_place_visit takes; null on event/GPS evidence rows."

AddedSep 13, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false and destructiveHint=false, but the description adds meaningful context beyond them: a cost figure ($0.10), an auth requirement (API key required), and idempotency behavior for evidence_expense_id/request_id. It correctly frames the operation as a mutation without contradicting the non-destructive hint.

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-loaded with the mutation verb and packed into a tight, information-dense block where each clause carries required/optional/cost data. The parenthetical run-ons are slightly dense but nothing is wasted.

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?

An output schema exists, so return values need not be explained. For a 15-parameter mutation tool the description covers the required inputs, the highest-value optionals, cost, and auth, leaving only minor param gaps.

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?

With only 33% schema coverage, the description compensates by naming the required fields (place or place_id, arrived_at/date), key optionals, and even inline enum-like values for source (uber|mcp) that the schema lacks. It leaves a few params (confidence, evidence_event_id) undocumented, so it is not fully compensating.

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?

The description opens with a specific verb+resource ('MUTATES place_visits') and scopes it to a concrete use case ('map/history digs (Uber dropoff, address evidence)'). An agent can immediately distinguish this write tool from read siblings like get_place_visits and from delete_place_visit.

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?

It provides clear usage context and an explicit alternative preference ('Prefer this over stuffing streets only into expenses'), which tells the agent when this tool beats a competing behavior. It stops short of naming sibling tools or stating exclusions, so it is not a full 5.

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.