Dayze — Life Context

Update Interaction

update_interaction

Contacts: correct one entry in a contact's history (interaction_id from get_person_interactions or log_interaction): kind, summary (null clears) or occurred_at. Fields left out stay. The contact's last interaction follows: moving the latest entry earlier makes the next latest their last interaction, a later time moves it forward, and the next check-in is recomputed. Private; never sends anything. Returns change_id: undo_contact_change(change_id) puts it back. Requires API key or OAuth with context.write. ($0.05; API key required)

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "interaction_id": "<interaction_id>"
    },
    "name": "update_interaction"
  }
}

Input Schema

Name	Required	Description
`kind`	No	Interaction type: message, call, meeting, note, check_in or thought_of, e.g. call.
`summary`	No	One line (max 280) in your own words; null clears it.
`request_id`	No	Client idempotency key (retries return original result).
`occurred_at`	No	When it happened (ISO date-time with a zone); not in the future.
`interaction_id`	Yes	The interaction id from get_person_interactions or log_interaction.
`idempotency_key`	No	Alias for request_id.

Output Schema

Name	Required	Description
`account`	No	The Dayze account this data belongs to. With more than one Dayze connection, name it in the answer.
`changed`	No	Each changed field: { from, to }.
`message`	No
`change_id`	No	Pass to undo_contact_change to put it back.
`provenance`	No	Which connector wrote the record and which connected Dayze account received it.
`interaction`	No	The history entry after the change (private): interaction_id, person_id, person_name, kind, summary, occurred_at, source.
`last_interaction`	No	The contact's last_interaction_at and next_check_in_at after the change (changed: true when this moved them), or null.
`life_state_rebuilt`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 10, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the annotations: discloses the cascade side effects (the contact's last interaction shifts when the latest entry is moved, and the next check-in is recomputed), states the operation is private and 'never sends anything' (consistent with openWorldHint=false), and surfaces the write scope (context.write), the $0.05 cost, and the change_id → undo_contact_change recovery path. That is exactly the mutation context an agent needs before writing.

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?

Tight and front-loaded — the core action and its fields come first, with consequences, safety, and cost trailing. The heavy parenthetical nesting (id sources, null-clears, the undo call, the price) makes it dense but every clause carries information; little could be cut without loss.

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 mutation tool with an output schema (so return shape needs no prose), everything an agent needs is present: which id to supply, partial-update semantics, downstream recomputation effects, auth requirements, privacy, and how to reverse the change. Nothing material is left to inference.

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 100%, so the baseline is 3, but the description adds genuine semantics the schema lacks: 'Fields left out stay' establishes PATCH rather than replace behavior, and 'null clears' clarifies the nullable summary's meaning. It does not cover the idempotency_key/request_id alias relationship, which lives only in the schema.

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?

Names a specific verb and scope: 'correct one entry in a contact's history', then enumerates the mutable fields (kind, summary, occurred_at) and identifies the interaction_id sources (get_person_interactions or log_interaction). This is distinguishable from log_interaction (create) and delete_interaction (remove) without opening either schema.

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?

Frames the tool as a correction path for existing entries and routes the agent to the two tools that produce interaction_id, plus names undo_contact_change as the reversal path. It stops short of an explicit 'to add a new interaction use log_interaction instead' exclusion, so the create-vs-correct split is implied rather than stated.

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.