Skip to main content
Glama

Dayze — Life Context

by com.dayze
OverviewDiscussionsAdmin

Undo Contact Change

undo_contact_change
Destructive

Reverse a reversible contact change (rename, alias, identity, classify, link). For merges, deletes, unlink_people, remove_person_alias and convert_contact_entity, pass restore_id as change_id within 30 days. Restore rejects later edits rather than overwriting them. ($0.10; API key required)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
change_idYes
request_idNoClient idempotency key (retries return original result).
idempotency_keyNoAlias for request_id.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
undoneNo
accountNoThe Dayze account this data belongs to. With more than one Dayze connection, name it in the answer.
messageNo
change_idNo
provenanceNoWhich connector wrote the record and which connected Dayze account received it.
not_restoredNoFields the undo left as they are, e.g. the birthday of an update_person saved before MCP 1.41.5.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • 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"
+}
  2. Changed1 schema field changed
    • addedOutput schema / properties / not_restored
      Added value: +{
+  "description": "Fields the undo left as they are, e.g. the birthday of an update_person saved before MCP 1.41.5.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "field": {
+        "type": "string"
+      },
+      "reason": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "field",
+      "reason"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}
  3. Added

TDQS

A4.2/5.0
Behavior5/5

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

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=true, openWorldHint=false) by disclosing the 30-day reversibility window, the non-overwriting conflict behavior ('rejects later edits rather than overwriting them'), the $0.10 cost, and the API-key requirement. These are exactly the operational constraints an agent needs before invoking a reversing mutation.

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?

Three tight sentences, front-loaded with the core action and its scope before the parameter-mapping rule and cost/auth footer. Dense and mostly waste-free, though the merge/delete sentence packs several operation names into one clause.

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 no explanation, and the description covers the key gating factors: eligible change types, time limit, conflict semantics, cost, and auth. The only gap is the absence of explicit guidance on choosing between this and the generic restore_change sibling.

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 67%, and the description compensates for the undocumented required change_id by explaining where its value comes from (the restore_id returned by the originating change). request_id/idempotency_key are already described in the schema, so no further credit there.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Reverse a reversible contact change') and enumerates the covered change types (rename, alias, identity, classify, link), which scopes it against the broader restore_change/restore_event/restore_expense/restore_cleanup family. It never names those siblings directly, so differentiation is inferred from the 'contact' scope rather than stated.

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 concrete when-to-use context: the 30-day window, and the specific upstream operations (merges, deletes, unlink_people, remove_person_alias, convert_contact_entity) whose restore_id must be fed in as change_id. It does not explicitly tell the agent when NOT to use it or which sibling restore tool to prefer instead, so routing to restore_change remains ambiguous.

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 toolsInspect
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.

Resources