Skip to main content
Glama

Pause a watch

pause_watch
DestructiveIdempotent

Pause a watch the user chose; stop future checks and discard any in-progress result. Existing queued emails may already be on their way. Requires watch-management permission.

Input Schema

NameRequiredDescriptionDefault
watch_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior4/5

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

Adds real value beyond the annotations: it names the destructive consequence (in-progress results are discarded), warns of residual side effects (queued emails may already be sent), and states the required permission. This is consistent with destructiveHint=true and idempotentHint=true. It could go further by noting whether the pause is reversible or how state is restored via resume_watch.

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 action and its primary effects, then the caveat and the permission requirement. No filler or restatement of the tool name.

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?

For a single-parameter mutation, the description covers the essential behavior, side effects, and auth requirement, and the annotations supply the safety profile. The remaining gap is practical: how an agent obtains a valid watch_id and whether the pause can be undone.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is one parameter (watch_id) with 0% schema description coverage, and the description does not explain it, only referring vaguely to "a watch the user chose." It gives no hint about where a watch_id comes from (e.g., list_watches/get_watch) or what format it takes.

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?

Uses a specific verb+resource ("Pause a watch") and immediately specifies the two effects: "stop future checks and discard any in-progress result." This distinguishes it from destructive siblings like delete_watch and from resume_watch by implication, though no sibling is named explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The usage context is implied by the effects described (temporarily halt checks), but the description never states when to choose pause over delete_watch or when to resume instead. No prerequisites or exclusions are given beyond the permission note.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources