TimeTree MCP Server

list_event_comments

Read-only

Retrieve comments for a TimeTree calendar event, including comment IDs, author user IDs, and attached image metadata, so you can review event discussion only.

Instructions

List comments with their ids, author user IDs, and attached image metadata. Use get_event_comment_image to view an image. Only comments are returned, not change history; use get_recent_activity for who changed what.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`event_uuid`	Yes	The event UUID
`calendar_id`	Yes	The calendar ID from list_calendars (numeric string; numbers are also accepted)

Output Schema

TableJSON Schema

Name	Required	Description	Default
`total`	Yes
`comments`	Yes
`event_uuid`	Yes
`calendar_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.7.0Oct 22, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "calendar_id": {
+      "type": "number"
+    },
+    "comments": {
+      "items": {
+        "properties": {
+          "author_id": {
+            "description": "User ID of the author",
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "author_type": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "calendar_id": {
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "content": {
+            "type": "string"
+          },
+          "created_at": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "editor_id": {
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "event_id": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "id": {
+            "description": "comment_id for update_event_comment and delete_event_comment",
+            "type": "string"
+          },
+          "images": {
+            "items": {
+              "properties": {
+                "filename": {
+                  "type": [
+                    "string",
+                    "null"
+                  ]
+                },
+                "height": {
+                  "type": [
+                    "number",
+                    "string",
+                    "null"
+                  ]
+                },
+                "image_index": {
+                  "minimum": 0,
+                  "type": "integer"
+                },
+                "width": {
+                  "type": [
+                    "number",
+                    "string",
+                    "null"
+                  ]
+                }
+              },
+              "required": [
+                "image_index",
+                "filename",
+                "width",
+                "height"
+              ],
+              "type": "object"
+            },
+            "type": "array"
+          },
+          "updated_at": {
+            "type": [
+              "string",
+              "null"
+            ]
+          }
+        },
+        "required": [
+          "id",
+          "content",
+          "images"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "event_uuid": {
+      "type": "string"
+    },
+    "total": {
+      "type": "number"
+    }
+  },
+  "required": [
+    "calendar_id",
+    "event_uuid",
+    "comments",
+    "total"
+  ],
+  "type": "object"
+}

Changed2 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"
```

First observedv0.3.0May 27, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context about the returned scope (comments only, excluding change history) and points to the sibling for image retrieval, though it says nothing about pagination, ordering, or result limits.

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, front-loaded with the core action and followed by routing guidance; every sentence carries distinct information with no restatement of the title.

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 and both parameters are documented, so the description needn't spell out return structure; it still adds scoping and sibling routing. Only minor gaps remain, such as ordering or whether results are paginated.

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% for both required parameters, including the note that calendar_id comes from list_calendars. The description's field list describes return values rather than the parameters, so it adds no semantics beyond the schema — baseline 3 is correct.

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 ("List comments") plus the fields returned (ids, author user IDs, image metadata), and explicitly scopes it against get_recent_activity. An agent can distinguish it from siblings without opening the 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 alternatives with the conditions that select them: get_event_comment_image "to view an image" and get_recent_activity "for who changed what," plus an explicit negative ("Only comments are returned, not change history").

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