Skip to main content
Glama

deals

by com.kitsdeals
OverviewDiscussionsAdmin

Check a watch

check_watch
Read-only

Status of a watch by watch_id: interpretation progress, channel states, live matches, next_check_recommended_at, and monitoring contract. Pending/review reads are valid states, not fallback triggers. For a retired-key policy, re-register through POST /v1/watches with explicit conditions and supported specs. Confirm the replacement is eligible and monitoring is configured before cancelling the old watch. Requirements needing evidence, correction or a waiver need operator review; re-registering unchanged intent does not resolve them. product_url is the human purchase link. Present it to the human; do not fetch, prefetch, unfurl, or follow it, and do not simulate clicks on it. Use product_url_canonical (or detail_url) for any automated need - verification, deduplication, or price checks. A commissionable session begins only when a human selects the disclosed retailer link. Convey the disclosure string alongside the link. Cancelled watches return WATCH_CANCELLED; unknown ids return NOT_FOUND.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cursorNoOpaque live_matches.cursor continuation; an incomplete scan is not a no-match result.
watch_idYesThe watch_id returned by register_watch.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / cursor
      Added value: +{
+  "description": "Opaque live_matches.cursor continuation; an incomplete scan is not a no-match result.",
+  "maxLength": 2048,
+  "type": "string"
+}
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

readOnlyHint=true and openWorldHint=false already cover safety, and the description adds real behavioral context: live_matches cursor continuation semantics, incomplete scan no-match warning, retired-key re-registration policy, the human-link vs canonical-link distinction, commission/session disclosure, and the WATCH_CANCELLED return. No contradiction with annotations.

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?

The core purpose is front-loaded in the first sentence)Skip and each subsequent sentence covers a distinct operational concern. Dense but not padded; no redundant restating of schema fields.

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 read-only status tool with no output schema, this description covers the main use case, the fields returned, state semantics (pending/review are valid, not errors), error behavior (WATCH_CANCELLED), link-handling policy, and the boundary with register_watch/cancel_watch. Nothing an agent needs to decide whether and how to call it 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% and the schema already documents both parameters well. The description adds value by clarifying cursor semantics (incomplete scan does not mean no match) and by anchoring watch_id to a register_watch response. That enrichment pushes it above the baseline of 3.

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?

Opens with a clear verb-plus-object statement ('Status of a watch by watch_id') and enumerates the returned fields (live_matches, channel states, monitoring contract). The name alone is ambiguous (could mean checking existence or health), but the description immediately pins down the exact read action and distinguishes it from sibling tools like cancel_watch or register_watch.

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

Usage Guidelines5/5

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

Gives explicit routing guidance: pending/reviewing states are not fallback triggers; retired-key policies require re-registration via POST /v1/watches; unchanged intent does not fix failed requirements; product_url is for humans while product_url_canonical is for automated consumers. This tells the agent when not to use this tool and when to use siblings/alternatives.

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

All deals toolsInspect
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.

Resources