Keeploop

Create calendar monitor

create_calendar_monitor

Watch the user's calendar for new invites, moved or cancelled events and conflicts. Narrow by organizer_contains, title_contains, category, changes or event_ref; give at least one. Stops after ttl_hours or max_hits matches. Returns a token for check_monitor and cancel_monitor. It only records and notifies; it never sends, changes or deletes anything. routes tags the monitor for check_route; use 'duet:' for a Claude Duet channel so any later session there can read it. Requires Keeploop Pro.

Input Schema

Name	Required	Description
`name`	No	A short name for the monitor.
`routes`	No	Up to 8 labels check_route reads this monitor's matches by, e.g. 'duet:fissler'. Lowercase letters, digits, '.', '_', ':' and '-'. A new monitor with routes has no Mac banner or ntfy push.
`changes`	No	Which changes to watch: invite_new, moved, cancelled, conflict (default all).
`category`	No	Only calendars or organizers with this label.
`max_hits`	No	Stop after this many matches; 1 for a one-shot watch.
`event_ref`	No	Watch one event (an event_ref from list_events).
`ttl_hours`	No	Stop after this many hours (default 24; no upper limit). 0 means no end: use it only when the user asks for a monitor that keeps running.
`title_contains`	No	Title contains this.
`organizer_contains`	No	Organizer address, domain or name contains this.

Output Schema

Name	Required	Description	Default
`note`	No
`monitor`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 29, 2026

changedInput schema / properties / routes / description

Previous value: -"Up to 8 labels check_route reads this monitor's matches by, e.g. 'duet:fissler'. Lowercase letters, digits, '.', '_', ':' and '-'."New value: +"Up to 8 labels check_route reads this monitor's matches by, e.g. 'duet:fissler'. Lowercase letters, digits, '.', '_', ':' and '-'. A new monitor with routes has no Mac banner or ntfy push."

Changed4 schema fields changedOct 28, 2026

changedInput schema / properties / ttl_hours / description

Previous value: -"Stop after this many hours (default 24, max 720)."New value: +"Stop after this many hours (default 24; no upper limit). 0 means no end: use it only when the user asks for a monitor that keeps running."

addedOutput schema / $defs / MonitorInfo / properties / moved_from

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "title": "Moved From"
+}

addedOutput schema / $defs / MonitorInfo / properties / other_worktree_monitors

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "additionalProperties": true,
+        "type": "object"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "title": "Other Worktree Monitors"
+}

addedOutput schema / $defs / MonitorInfo / properties / other_worktree_note

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "title": "Other Worktree Note"
+}

Changed2 schema fields changedOct 23, 2026

addedInput schema / properties / routes

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Up to 8 labels check_route reads this monitor's matches by, e.g. 'duet:fissler'. Lowercase letters, digits, '.', '_', ':' and '-'.",
+  "title": "Routes"
+}

addedOutput schema / $defs / MonitorInfo / properties / routes

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "title": "Routes"
+}

Changed2 schema fields changedOct 16, 2026

addedOutput schema / $defs / MonitorInfo / properties / commitments

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "title": "Commitments"
+}

addedOutput schema / $defs / MonitorInfo / properties / track

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "title": "Track"
+}

AddedOct 14, 2026

TDQS

A4.7/5.0

Behavior5/5

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

With annotations only declaring non-destructive/non-readonly, the description adds meaningful behavior: it only records and notifies, never sends or mutates data, stops after ttl_hours or max_hits, returns a token for check_monitor/cancel_monitor, and requires Keeploop Pro. That covers the mutation profile, lifecycle, and privilege requirement an agent needs.

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?

The purpose is stated first, followed by filters, lifecycle, return token, safety, and routes. Every sentence adds actionable information with no filler or repetition.

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?

For a 9-parameter creation tool with a full output schema, the description covers what is monitored, the required narrowing, TTL/max_hits termination, the returned token and its sibling consumers, the non-mutating guarantee, and the Pro requirement. Nothing essential is left for the agent to infer.

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 100%, so the baseline is 3, but the description adds a real constraint not in the schema: at least one narrowing field must be supplied. It also explains that routes tag the monitor for check_route and that 'duet:<channel>' makes matches readable by later Claude Duet sessions. It omits name and some route limits, keeping it just below a 5.

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?

The description states a specific verb and resource ('Watch the user's calendar' / monitor) and enumerates the watched changes (new invites, moved, cancelled, conflicts). The calendar scope distinguishes it from create_email_monitor and create_notes_monitor without needing the schemas.

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?

It gives concrete usage conditions: narrow by organizer/title/category/changes/event_ref and 'give at least one', and it explains when the monitor ends. It does not explicitly say when to prefer update_monitor or list_monitors instead, so it stops short of full alternative routing.

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

All Keeploop 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.