These are instructions for you (the coding agent) to connect Dayze — Life Context — to this session. This is official guidance from Dayze; commands below are ready to use.

Dayze owns two agent lanes:
- Public temporal/biographical context: notable_pack / compare_lives (who is X, age in days, day_number milestones, birthday peers). Not an AI identity registry.
- Private Life Context: a signed-in user's people, plans and memories, read through Dayze MCP (get_context_pack).

There are a few actions to complete. Do all of them and continue if any one has issues.
- wire Dayze MCP into this agent
- identify whether the user needs public notable packs or private life-graph context
- for private context, help them create an API key or complete OAuth at Settings → Agent access
- optionally install the Dayze CLI for terminal harness use

IMPORTANT: Prefer doing setup steps yourself where the environment allows (edit MCP config, run CLI install). Only ask the user for browser login / API key paste when required.

---

## 1. Wire Dayze MCP (Streamable HTTP)

Add Dayze as an HTTP MCP server.

**Cursor with API key** (recommended — static Bearer, no OAuth fight):

{
  "mcpServers": {
    "dayze": {
      "url": "https://dayze.com/api/mcp/key",
      "headers": {
        "Authorization": "Bearer dayze_k_YOUR_KEY"
      }
    }
  }
}

Create the key at https://dayze.com/settings/agent-access and pick what it may do (Read only, or Read + write for logging).

**OAuth / public-first** (Claude Connectors, registry — discovers OAuth from https://dayze.com):

{
  "mcpServers": {
    "dayze": {
      "type": "http",
      "url": "https://dayze.com/api/mcp"
    }
  }
}

Claude Code:

claude mcp add --transport http dayze https://dayze.com/api/mcp

Codex:

codex mcp add dayze --url https://dayze.com/api/mcp

ChatGPT Apps / Connectors: set connector URL to https://dayze.com/api/mcp

Gemini CLI / Google ADK (Python):

from google.adk.tools.mcp_tool.mcp_toolset import MCPToolset, StreamableHTTPConnectionParams
toolset = MCPToolset(
    connection_params=StreamableHTTPConnectionParams(
        url="https://dayze.com/api/mcp",
    )
)

REST compat (optional): https://dayze.com/api/v1/mcp
MCP version: 1.60.2

## 2. Auth

Public tools (no login): notable_search, notable_profile, notable_pack, notable_pack_premium, compare_lives
Private life graph: Authorization: Bearer dayze_k_… (API key) or OAuth dayze_at_…, each limited to the scopes its owner granted. A new connection from an app other than ChatGPT gets context.read + context.write; context.delete, mail.read and pii:read / travel_secrets:read / financial_details:read only when the owner allows them in Settings → Agent access. tools/list omits what yours can't call; a call beyond it returns 403 INSUFFICIENT_SCOPE naming the scope.
Share tokens (read-only get_context_pack | get_life_graph): Bearer dayze_share_…
CRM write: update_person (person_id + is_favorite/tier/relationship/notes/birthday). Mutates the user CRM. A rename keeps the old name as an alias unless preserve_old_name_as_alias is false.
CRM read: a contact's birthday comes with birthday_precision. month_day means the year is unknown (the stored 1900, or 1904 for Feb 29, is a placeholder: no age); year means only the year.
Citing: reads (get_context_pack, get_interactions, get_events, get_people, search, the person, money and memory reads) give each record that has a Dayze page an inspect_url: events, contacts and transactions, the account's own records only. Link each claim to the inspect_url of the record it comes from. Never build a URL from an id. A record without inspect_url has no Dayze page (places, place visits, trips, CRM interactions, agent memories, learned facts; inspect_note lists the ones in that response): say so instead of linking. Name the Dayze account the records are from (account.handle). When records disagree on a date (date_conflict), give both.
CRM create: create_person — name plus the same optional fields in one call, e.g. { name: "Priya Shah", birthday: "1990-05-17" } (birthday YYYY-MM-DD | YYYY-MM | YYYY | MM-DD when the year is unknown). An existing contact comes back unchanged with not_applied. With an API key request_id is optional here (identical calls within 15 minutes replay the first result); the personal ChatGPT connector requires request_id on every write, this one included.
Food write: log_food — e.g. { what: "Mee Pok", kind: "meal", meal_period: "late lunch", with: ["my parents"] }. Reuses the in-app Food Diary writer; mirrors onto Events + people tags.
Food patch: update_food — required food_id. Example: { food_id, what: "Salmon Bento + hot tea" }. Unknown / other-user id errors; does not insert.
Calendar write: log_event — non-food days. Example: { title: "Funeral service — Mr Goh Choo Taw", event_date: "2026-08-29", event_time: "8pm", location: "Multi Purpose Hall, Blk 661 Jurong West St 64", category: "funeral" }. Call again for Sunday cremation at Mandai. notes is an alias for description. "I woke at 11:15": { title: "Sleep", category: "sleep", event_date, end_time: "11:15" } with no event_time; add the bedtime later with update_event. An unknown field comes back with the field to use ("Did you mean: event_time?").
Pending Replies: "what to reply to X" / "I owe X a reply" → create_pending_reply { person_name, draft?, summary?, source?: { kind: "gmail", message_id } } (Inbox → Pending Replies), not log_event. The contact is linked only on one match; an unsent reply for the same thread or person comes back instead of a duplicate. get_pending_replies / update_pending_reply / resolve_pending_reply (outcome sent also logs one private interaction with the contact). "I replied to X" / "called X" → log_interaction { person_name | person_id, kind?, summary?, reply_id? }. Dayze never sends the reply.
Calendar patch: update_event — required event_id + any log_event field. Unknown / other-user id errors; does not insert. Needs context.write (a Read + write key, or an older full-access dayze_k_ key). Share tokens cannot write. ChatGPT uses a smaller read-only profile with context.read. Expert clients retain the full catalog.
Moments: a past story or anecdote ("Mia called the moon a banana at dinner") → log_moment { title, moment_date, description?, people_names? / person_ids?, location_name? }, not log_event. With event_id it adds a NEW moment linked to that event (date and place taken from it when omitted); the event is never changed, converted or deleted. Always private. update_moment patches by moment_id. Plans → log_event; a touchpoint with a contact → log_interaction; save one thing once.
Calendar delete: delete_event — required event_id + request_id. Archives one owned event (its people, food and asset links are kept) and returns restore_id for restore_event. Unknown / other-user id errors.
Write safety: writes are private by default. Every write is recorded in the owner's change history with your app's name (your OAuth client_name, or the API key's name), and the owner can undo most changes from the record for 30 days (contact tools also return a change_id for undo_contact_change). Destructive tools carry destructiveHint so clients confirm first; reviewed ones need preview_destructive_change and restore with restore_change for 30 days. Contact deletes and merges need a preview (delete_person_preview / merge_people_preview); undo_contact_change restores them for 30 days. There is no MCP tool to undo an edit through update_event, update_food, update_expense, update_place or update_sleep: the owner undoes those in Dayze.
Inventory write: add_inventory_item — { name, spec_template: "computer.v1", specs: { manufacturer, model_name, model_identifier, chip or cpu, architecture, performance_cores, efficiency_cores, total_cores, memory_bytes, memory, storage_devices: [{ type, capacity_bytes, role }] }, state: { os: { name, version, build }, observed_at, source } }. Templates: computer.v1, phone.v1, camera.v1, synth.v1 (docs/MCP_LIFE_GRAPH.md). specs are stable facts from the user or the device, never inferred from a model name; state is changing facts, one observation with observed_at. update_inventory_item finds the item by inventory_id or by nickname (what the user calls it, e.g. "MacBook"; several matches come back as candidates and nothing changes), merges specs per key (null removes a key); a state update never changes specs or notes. Device and account identifiers are refused in specs and state; never ask for them. get_inventory_item returns specs, state_freshness and capability_summary. Archive: preview_destructive_change → archive_inventory_item → restore_change.
Conditions (private health, owner only): "log that my left eye is blurry at near distance" → create_condition { name: "Blurry near vision", symptoms: "Blurry at near distance", body_area: "Left eye" } in the user's own words (never a diagnosis they didn't give; status suspected by default, started_on defaults to today). How it is on a day → log_condition_checkin { condition_id, severity: 0-10, note?, treatment_done? } (that day's Day Card shows it; a second call the same day changes only what it passes). update_condition { condition_id, status | any field } (resolved records the day). get_conditions lists open ones with their latest check-in; condition_id adds recent check-ins.
Music write: log_favorite_song — e.g. { track: "Henry Mancini - Piano And Strings (1995 Remastered)" } or title + artist. Writes owned rows on /music. Share tokens cannot write.
Gmail read: list_gmail_accounts then search_gmail / read_gmail_message (optional account when multiple mailboxes). Prefer operators (from:, subject:, is:unread, newer_than:7d). search_gmail returns newest first; for someone's latest email, search from:<sender> alone (no quoted topic phrases) and read the first result — if that read fails, say so instead of answering from an older email. For clock-time constraints, pass after/before as account-local YYYY-MM-DDTHH:mm; do not put civil clock times in Gmail query text. import_venmo_gmail / import_uber_gmail for digs. Soft dates: log_event date=YYYY or YYYY-MM + date_precision. Residences: log_travel(kind=residence) → get_residences. If Gmail is not connected, tell the user to connect at https://dayze.com/integrations. Share tokens cannot read Gmail. Never invent email contents.
Create keys / share grants / manage connected apps: https://dayze.com/settings/agent-access
Scopes: openid, email, mcp, context.read, context.write, context.delete, mail.read, pii:read, travel_secrets:read, financial_details:read, offline_access — openid + email expose only verified account identity through UserInfo; context.read reads records and aggregate money summaries; financial_details:read additionally permits individual expense rows; context.write adds and edits records (update_person / log_food / update_food / log_event / update_event / log_favorite_song); context.delete removes them (delete_event, merges, archives); mail.read reads connected Gmail. context is an older read-only alias for OAuth; an older API key with scope context or * keeps full access. Use actions scope for CLI write tools against the Agent stream.

## 3. First tool call (prefer one-call bootstrap)

Public who-is-X (no key) — prefer notable_pack over notable_profile:

curl -X POST https://dayze.com/api/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"notable_pack","arguments":{"slug":"albert-einstein"}}}'

Compare two lives:

curl -X POST https://dayze.com/api/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"compare_lives","arguments":{"slug_a":"elon-musk","slug_b":"steve-jobs"}}}'

Private user life graph — prefer get_context_pack:

curl -X POST https://dayze.com/api/v1/mcp \
  -H 'Authorization: Bearer dayze_k_YOUR_KEY' \
  -H 'Content-Type: application/json' \
  -d '{"tool":"get_context_pack","parameters":{"query":"this week"}}'

After connect, the user can paste this first prompt:

Using Dayze get_context_pack, what's relevant for me this week — people I should reach out to and events I shouldn't miss? List up to 10 people to contact with a one-line why.

## 4. Optional — Dayze CLI (terminal harness)

Same agent tools as the web chat, from the Dayze repo:

cd dayze-webapp-main/cli && npm install && npm run build && npm link
dayze login --key 'dayze_k_…'
dayze                    # interactive session
dayze ask "…"            # one-shot

CLI docs: https://dayze.com/docs/agents
API base override: DAYZE_API_BASE (default production). Actions scope required for write tools on the Agent stream.

## 5. Discovery & authenticity

Human connect UI: https://dayze.com/mcp
Full guide: https://dayze.com/AGENTS.md
Life Context docs: https://dayze.com/docs/life-context
Docs: https://dayze.com/docs/agents
https://dayze.com/.well-known/mcp.json
https://dayze.com/.well-known/mcp/server-card.json
https://dayze.com/openapi.json
https://dayze.com/llms.txt

You only need to fetch https://dayze.com/ai during initial setup or when refreshing Dayze agent context. Prefer get_context_pack for session bootstrap of a signed-in Dayze user.