TimeTree MCP Server

update_memo

DestructiveIdempotent

Modify an existing TimeTree memo by sending only fields to change, replacing checklist and virtual attendee lists as needed; get memo_uuid from list_memos. Use update_event for regular events.

Instructions

Change a memo and return it. Only provide the fields to change; checklist and virtual attendees replace the current lists. Get memo_uuid from list_memos. Fails for regular events (use update_event).

Input Schema

TableJSON Schema

Name	Required	Description
`url`	No	New related URL; use an empty string to remove it
`note`	No	New memo body text
`title`	No	New memo title
`label_id`	No	Color label ID (1-10): 1=Emerald green, 2=Modern cyan, 3=Deep sky blue, 4=Pastel brown, 5=Midnight black, 6=Apple red, 7=French rose, 8=Coral pink, 9=Bright orange, 10=Soft violet
`location`	No	New memo location
`checklist`	No	Replace checklist items; use [] to clear
`memo_uuid`	Yes	The memo UUID (same as event UUID)
`calendar_id`	Yes	The calendar ID from list_calendars (numeric string; numbers are also accepted)
`virtual_user_attendees`	No	Replace virtual member attendees; use [] to clear

Output Schema

TableJSON Schema

Name	Required	Description	Default
`memo`	Yes
`message`	No
`success`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.7.0Oct 22, 2026

changedInput schema / properties / label_id / description

Previous value: -"New color label ID (1-10)"New value: +"Color label ID (1-10): 1=Emerald green, 2=Modern cyan, 3=Deep sky blue, 4=Pastel brown, 5=Midnight black, 6=Apple red, 7=French rose, 8=Coral pink, 9=Bright orange, 10=Soft violet"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "memo": {
+      "properties": {
+        "calendar_id": {
+          "type": "number"
+        },
+        "checklist": {
+          "type": "array"
+        },
+        "created_at": {
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "label_color": {
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "label_id": {
+          "type": [
+            "number",
+            "null"
+          ]
+        },
+        "location": {
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "memo_date": {
+          "description": "YYYY-MM-DD",
+          "type": "string"
+        },
+        "note": {
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "title": {
+          "type": "string"
+        },
+        "updated_at": {
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "url": {
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "uuid": {
+          "type": "string"
+        },
+        "virtual_user_attendees": {
+          "type": "array"
+        }
+      },
+      "required": [
+        "uuid",
+        "title",
+        "memo_date"
+      ],
+      "type": "object"
+    },
+    "message": {
+      "type": "string"
+    },
+    "success": {
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "success",
+    "memo"
+  ],
+  "type": "object"
+}

Changed3 schema fields changedv0.4.0Oct 3, 2026

changedInput schema / properties / calendar_id / description

Previous value: -"The calendar ID"New value: +"The calendar ID from list_calendars (numeric string; numbers are also accepted)"

changedInput schema / properties / calendar_id / type
```
Previous value: -"number"New value: +"string"
```

changedInput schema / properties / url / description

Previous value: -"New related URL"New value: +"New related URL; use an empty string to remove it"

First observedv0.3.0May 27, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: partial-update semantics (only send changed fields) and replace-not-merge behavior for checklists and virtual attendees. It does not mention permissions or auth requirements, which is the remaining gap.

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 short sentences, zero filler, with the core action stated first and the alternative routing (update_event) placed last where it belongs. Every sentence carries information the agent needs.

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 still notes the memo is returned. For a 9-parameter mutation tool, the critical semantics — partial update, list replacement, UUID sourcing, and the event/memo distinction — are all present.

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 description coverage is 100%, so the baseline is 3, but the description adds a genuine semantic rule absent from the schema: omit unchanged fields because updates are partial. It also reinforces that list parameters replace rather than append, which matters for the two array fields.

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 ('Change a memo'), plus the return behavior ('and return it'). It explicitly distinguishes itself from the closest sibling with 'Fails for regular events (use update_event).'

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?

Gives a clear when-to-use rule ('only provide the fields to change'), a prerequisite for identifying the target ('Get memo_uuid from list_memos'), and an explicit exclusion with a named alternative ('Fails for regular events (use update_event)').

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.