Keeploop

Create call monitor

create_call_monitor

Watch the user's phone and FaceTime calls and voicemail. Give from_contains (number, address or contact name), body_contains (voicemail transcript) or both; a voicemail whose transcript arrives later fires once more with it. missed_only skips answered calls. Outgoing calls are 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.

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_call_monitor"
  }
}

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.
`max_hits`	No	Stop after this many matches; 1 for a one-shot watch.
`match_all`	No	Every incoming call and voicemail (needs routes).
`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.
`include_own`	No	Also match outgoing calls.
`missed_only`	No	Only calls nobody answered; voicemails always count.
`body_contains`	No	Voicemail transcript contains this.
`from_contains`	No	Sender address, number or name contains this.

Output Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 2, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations (which only say non-readonly, non-destructive, non-idempotent), it discloses the side-effect profile ('only records and notifies; never sends, changes or deletes anything'), the lifecycle ('stops after ttl_hours or max_hits'), the re-fire edge case for late transcripts, the returned token, and a licensing prerequisite (Keeploop Pro). That is meaningful behavioral context the structured fields do not carry.

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?

It is front-loaded with the core action and the required trigger, then layers lifecycle, safety, and routing constraints. Eight dense sentences with little waste, though the routes/duet sentence is slightly buried at the end for a parameter an agent may need early.

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 monitor-creation tool with an output schema, the description covers the trigger logic, skip conditions, termination rules, return token, safety guarantees, and Pro requirement. An agent has everything needed to call it correctly and interpret what happens afterward.

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; the description earns above that by explaining how the two filters combine (either or both), what from_contains matches against, and the coupling of routes to check_route and the 'duet:<channel>' convention. It does not cover name, match_all, or max_hits nuances beyond a brief mention.

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 first sentence states a specific verb and resource set: watch the user's phone and FaceTime calls plus voicemail. The resource scope cleanly separates it from the other create_*_monitor siblings (email, slack, calendar, notes), and it names the downstream tools (check_monitor, cancel_monitor, check_route) that consume its output.

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 tells the agent exactly what to supply ('Give from_contains ... body_contains ... or both'), when outgoing calls are excluded, and when a monitor keeps running forever. It stops short of explicitly routing the agent to sibling alternatives (e.g., create_email_monitor) or stating when-not to create a monitor at all.

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.