Dayze — Life Context

Add Contact Phone or Email

add_person_contact_method

Add an extra phone number or email address to a contact (kind phone|email, value, optional label such as work, home or mobile). The primary phone and email stay update_person's. A value the contact already has (extra or primary) is not added twice. An extra email also links that address's Gmail messages to this contact, as in Dayze. undo_contact_change(change_id) removes it. ($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": {
      "person_id": "<person_id>",
      "kind": "<kind>",
      "value": "<value>"
    },
    "name": "add_person_contact_method"
  }
}

Input Schema

Name	Required	Description
`kind`	Yes	Whether this extra contact method is a phone or an email, e.g. phone.
`label`	No	Phone label, e.g. work, home, mobile (phones only).
`value`	Yes	The phone number (digits, e.g. +65 9123 4567) or email address.
`person_id`	Yes	An owned contact id.
`request_id`	No	Client idempotency key (retries return original result).
`idempotency_key`	No	Alias for request_id.

Output Schema

Name	Required	Description
`added`	No
`account`	No	The Dayze account this data belongs to. With more than one Dayze connection, name it in the answer.
`message`	No
`change_id`	No	Pass to undo_contact_change to remove it.
`person_id`	No
`provenance`	No	Which connector wrote the record and which connected Dayze account received it.
`person_name`	No
`extra_emails`	No
`extra_phones`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 10, 2026

TDQS

A4.2/5.0

Behavior3/5

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

Annotations already declare non-read-only, non-destructive, closed-world behavior, and the description goes well beyond them: it discloses the Gmail-linking side effect of extra emails, the dedupe rule, the undo path, the $0.05 cost, and the API-key requirement. Those are genuine behavioral disclosures that annotations cannot carry.

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?

Four tight sentences, front-loaded with the action and followed by scoping, side effects, and cost/auth. The parenthetical '(kind phone|email, value, optional label such as work, home or mobile)' slightly duplicates the schema, which is the only waste.

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?

An output schema exists so return values need not be described, and annotations cover the safety profile. The description fills the remaining gaps an agent needs: side effects on Gmail linkage, reversal mechanism, cost, and auth, all proportionate to a 6-parameter mutation tool.

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 100%, so all six parameters are already documented, and the description largely restates kind and label semantics that the schema provides. It adds only the dedupe meaning for value (a value the contact already has is not added twice), which is marginal beyond the schema baseline.

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 and resource (add an extra phone number or email address to a contact) and immediately scopes it against update_person, which owns the primary phone/email. An agent can distinguish it from add_person_alias, remove_person_contact_method and update_person without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Names two sibling routes explicitly: use update_person for primary phone/email, and undo_contact_change(change_id) to reverse this operation. It also warns that a value already present (extra or primary) is not added twice, which tells the agent not to pre-check manually.

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.