Keeploop

Create email monitor

create_email_monitor

Watch the user's mail for messages that have not arrived yet. Give at least one of from_contains, subject_contains or body_contains; all given must match (case-insensitive). Mail containing any word in from_excludes, subject_excludes or body_excludes (comma-separated) never matches. Mail the user sent is skipped unless include_own is true. 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.
`account`	No	Only this mail account (name or address).
`mailbox`	No	Only this mailbox, e.g. INBOX (Gmail labels count).
`category`	No	Only accounts with this label, e.g. Work or Personal (list_categories).
`max_hits`	No	Stop after this many matches; 1 for a one-shot watch.
`match_all`	No	Match every new item instead of a filter; needs routes (check_route).
`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.
`bulk_allow`	No	Senders that always pass exclude_bulk: parts of an address or name, e.g. ['dropbox.com', 'mybank'].
`include_own`	No	Also match what the user sent or wrote.
`unread_only`	No	Only unread messages.
`exclude_bulk`	No	Skip newsletters, promos and other list or automated mail (by header). Off by default.
`body_contains`	No	Message text contains this.
`body_excludes`	No	Skip messages whose text contains any of these comma-separated words.
`from_contains`	No	Sender address, number or name contains this.
`from_excludes`	No	Skip senders containing any of these comma-separated words.
`account_excludes`	No	Skip mail in these accounts (names or addresses, as list_accounts shows).
`subject_contains`	No	Subject contains this.
`subject_excludes`	No	Skip subjects containing any of these comma-separated words.

Output Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 29, 2026

addedInput schema / properties / account_excludes

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Skip mail in these accounts (names or addresses, as list_accounts shows).",
+  "title": "Account Excludes"
+}

Changed2 schema fields changedOct 29, 2026

addedInput schema / properties / bulk_allow

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Senders that always pass exclude_bulk: parts of an address or name, e.g. ['dropbox.com', 'mybank'].",
+  "title": "Bulk Allow"
+}

addedInput schema / properties / exclude_bulk

Added value: +{
+  "default": false,
+  "description": "Skip newsletters, promos and other list or automated mail (by header). Off by default.",
+  "title": "Exclude Bulk",
+  "type": "boolean"
+}

Changed3 schema fields changedOct 29, 2026

addedInput schema / properties / mailbox

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Only this mailbox, e.g. INBOX (Gmail labels count).",
+  "title": "Mailbox"
+}

addedInput schema / properties / match_all

Added value: +{
+  "default": false,
+  "description": "Match every new item instead of a filter; needs routes (check_route).",
+  "title": "Match All",
+  "type": "boolean"
+}

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?

It adds context the annotations do not carry: the Pro entitlement check, the AND semantics of the contains filters, the fact that excludes always win, that the user's own sent mail is skipped by default, the stop conditions (ttl_hours or max_hits), a concrete return value ("Returns a token for check_monitor and cancel_monitor"), and an explicit safety statement. The safety statement ("never sends, changes or deletes anything") matches destructiveHint=false instead of contradicting it.

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 core purpose is front-loaded, and each remaining sentence covers one rule (matching, excludes, own mail, termination, return value, safety, routes) with no filler. Dense but structured, and appropriate for a tool with 19 parameters.

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 19-parameter creation tool with an output schema and annotations, the description covers every decision an agent must make: at least one matching filter, exclude semantics, stopping rules, entitlement, and the token returned for follow-up. Nothing essential for correct invocation is missing.

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 all 19 parameters are already documented; the baseline is therefore 3. The description earns the higher score by documenting cross-parameter behavior that the schema does not: multiple contains values must all match, anything in the matching excludes list prevents the match, and matching is case-insensitive. It does not cover which parameters conflict with one another, or when match_all and the filter parameters interact.

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?

"Watch the user's mail for messages that have not arrived yet" names a specific verb and resource and implicitly separates the tool from search_mail, which reads mail that already exists. It also names the follow-up tools (check_monitor, cancel_monitor, check_route) so an agent knows where this tool sits in the workflow.

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 real prerequisites ("Give at least one of from_contains, subject_contains or body_contains"), explains when to set ttl_hours=0 ("use it only when the user asks for a monitor that keeps running"), and explains what routes is for. It never states the converse case, namely that an agent should use search_mail or list_monitors instead when the mail already exists or a monitor is already set up.

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.