Dayze — Life Context

Rename Contact List

update_contact_list

Rename a contact list (list_id, or list_name as its current name or slug) to name. Its members are unchanged. A name another list already has is refused (code CONFLICT); Family follows relationships and keeps its name (code AUTO_SYNCED_LIST). undo_contact_change(change_id) puts the old name back. ($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": {
      "name": "<name>"
    },
    "name": "update_contact_list"
  }
}

Input Schema

Name	Required	Description
`name`	Yes	The new name, e.g. "Book club".
`list_id`	No	Contact list id from list_contact_lists.
`list_name`	No	The current list name or slug, when list_id is not known.
`request_id`	No	Client idempotency key (retries return original result).
`idempotency_key`	No	Alias for request_id.

Output Schema

Name	Required	Description
`list`	No	Contact list after the rename: id, name, slug.
`account`	No	The Dayze account this data belongs to. With more than one Dayze connection, name it in the answer.
`message`	No
`renamed`	No
`change_id`	No	Pass to undo_contact_change to put the old name back.
`provenance`	No	Which connector wrote the record and which connected Dayze account received it.
`previous_name`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 10, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing that members are unchanged, that name collisions are refused with code CONFLICT, that Family lists are auto-synced and keep their name (code AUTO_SYNCED_LIST), that the change is reversible via undo_contact_change, and that the call costs $0.05 with an API key. These are exactly the traits an agent needs before invoking a mutation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three dense sentences plus a parenthetical: identifier resolution first, then side effects, then error codes, then the recovery path and cost. Nothing is wasted and the key scoping information is front-loaded.

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 explained, and the description covers everything else an agent needs: how to identify the list, what changes and what doesn't, which error codes to expect, how to undo, and the auth/cost requirement.

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 coverage is 100% and the schema already documents name, list_id, list_name, and idempotency keys. The description restates the identifier resolution (list_id or list_name as current name/slug) but adds no format or constraint detail the schema lacks, so the baseline 3 applies.

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 precise verb and resource ('Rename a contact list ... to name') and immediately scopes it with the identifier options. It also names the undo path, which separates it from sibling mutation tools like create_contact_list.

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?

Gives clear operating context: use list_id, or list_name as a fallback when the id is unknown, and call undo_contact_change(change_id) to revert. It doesn't explicitly compare against other sibling tools that might also affect a list, but the usage conditions it does give are concrete.

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.