Keeploop

Create notification monitor

create_notification_monitor

Watch the notifications any app on the Mac posts (experimental). app matches the app's name (e.g. 'Microsoft Teams'), from_contains the notification title (where chat apps put the sender) and body_contains the whole notification; give at least one. Reactions (someone reacted to a message) are skipped unless include_reactions 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.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "create_notification_monitor"
  }
}

Input Schema

Name	Required	Description
`app`	No	App name contains this, e.g. Microsoft Teams.
`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.
`max_hits`	No	Stop after this many matches; 1 for a one-shot watch.
`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.
`body_contains`	No	Notification text contains this.
`from_contains`	No	Notification title (where chat apps put the sender) contains this.
`include_reactions`	No	Notifications monitors: also match reactions (off by default).

Output Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 2, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations only declare readOnly=false/destructive=false/idempotent=false/openWorld=false; the description goes well beyond by explaining that reactions are skipped by default, that the monitor terminates on ttl_hours or max_hits, that it returns a token consumed by check_monitor and cancel_monitor, and that it 'never sends, changes or deletes anything'. It also discloses a prerequisite ('Requires Keeploop Pro') and flags the tool as experimental, none of which is in the structured fields.

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?

Front-loads the core behavior, then packs the filter semantics, lifecycle rules, return token and prerequisite into a few dense sentences with no filler. It is information-rich rather than bloated, though the sentence structure is packed enough that an agent must read the whole block to catch the Pro requirement.

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 an 8-parameter creation tool with an output schema, an agent has everything it needs: matching fields, default reaction behavior, termination conditions, the returned token and its consumers, route semantics, and the Pro entitlement requirement. Nothing needed to call it correctly or interpret its lifecycle is absent.

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 would be 3, but the description adds cross-tool semantics the schema cannot: from_contains is 'where chat apps put the sender', and routes 'tags the monitor for check_route' with the duet channel convention. The only slightly loose point is that the description says app 'matches the app's name' while the schema says 'contains this'.

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 — 'Watch the notifications any app on the Mac posts' — and scopes it to macOS notification-stream monitoring, which separates it from create_message_monitor, create_slack_monitor and create_email_monitor. It does not explicitly name those siblings as alternatives, so an agent must infer the routing from the source medium rather than from an explicit statement.

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 invocation constraints: 'give at least one' of app/from_contains/body_contains, 'use it only when the user asks for a monitor that keeps running' for ttl_hours=0, and the 'duet:<channel>' route convention for check_route. Missing is an explicit statement of when NOT to use this versus the other create_*_monitor tools, which is the main sibling ambiguity.

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.