Skip to main content
Glama

Watch an agent or MCP server for changes

gaip_watch_register

Use this when asked to keep an eye on an agent or MCP server ("tell me if it changes or goes down"). Pass the continuity_handle from any GAIP result, kind and target_url. GAIP re-checks every 24 hours (3 free watches), receipts each change and can call your webhook. Free, no account; records a GAIP receipt only. Inputs must be public and non-personal.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
slaNoDELIVERY_SLA only: service-level terms checked on every observation, any of min_uptime_pct, max_latency_ms, required_fields (JSON key paths), freshness_field + max_age_seconds; optional uptime_window_hours, min_observations. Results go only to you.
kindYesAGENT_READINESS (agent URL), SUPPLIER_CARD (published card), DELIVERY_TERMS (terms_id) or DELIVERY_SLA (terms_id plus sla terms).
terms_idNoDELIVERY_TERMS or DELIVERY_SLA: terms_id from witness_register_terms.
target_urlNoPublic https URL (AGENT_READINESS, SUPPLIER_CARD). No query string.
webhook_urlNoOptional: your own public https endpoint for signed change events.
interval_hoursNoHours between checks: 24 minimum on the free tier; 1 for DELIVERY_SLA.
continuity_handleYesThe continuity_handle from an earlier GAIP result; proves you own these watches.
data_classificationNoPUBLIC (default) or NON_PERSONAL_PUBLIC. Never send personal data.PUBLIC

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / examples
      Previous value: -[
      -  {
      -    "continuity_handle": {
      -      "continuity_id": "<continuity_handle.continuity_id returned by any GAIP tool>",
      -      "token": "<continuity_handle.token returned by any GAIP tool>"
      -    },
      -    "interval_hours": 24,
      -    "kind": "SUPPLIER_CARD",
      -    "target_url": "https://weather.example.com/.well-known/agent-card.json",
      -    "webhook_url": "https://hooks.example.com/gaip-watch"
      -  }
      -]New value: +[
      +  {
      +    "continuity_handle": {
      +      "continuity_id": "<continuity_handle.continuity_id returned by any GAIP tool>",
      +      "token": "<continuity_handle.token returned by any GAIP tool>"
      +    },
      +    "interval_hours": 24,
      +    "kind": "DELIVERY_TERMS",
      +    "terms_id": "<terms_id from witness_register_terms>"
      +  }
      +]
  2. Changed6 schema fields changed
    • changedInput schema / properties / interval_hours / description
      Previous value: -"Optional: hours between checks (24 minimum on the free tier)."New value: +"Hours between checks: 24 minimum on the free tier; 1 for DELIVERY_SLA."
    • changedInput schema / properties / interval_hours / minimum
      Previous value: -24New value: +1
    • changedInput schema / properties / kind / description
      Previous value: -"AGENT_READINESS (agent URL), SUPPLIER_CARD (published card) or DELIVERY_TERMS (terms_id)."New value: +"AGENT_READINESS (agent URL), SUPPLIER_CARD (published card), DELIVERY_TERMS (terms_id) or DELIVERY_SLA (terms_id plus sla terms)."
    • changedInput schema / properties / kind / enum
      Previous value: -[
      -  "AGENT_READINESS",
      -  "DELIVERY_TERMS",
      -  "SUPPLIER_CARD"
      -]New value: +[
      +  "AGENT_READINESS",
      +  "DELIVERY_TERMS",
      +  "SUPPLIER_CARD",
      +  "DELIVERY_SLA"
      +]
    • addedInput schema / properties / sla
      Added value: +{
      +  "description": "DELIVERY_SLA only: service-level terms checked on every observation, any of min_uptime_pct, max_latency_ms, required_fields (JSON key paths), freshness_field + max_age_seconds; optional uptime_window_hours, min_observations. Results go only to you.",
      +  "type": "object"
      +}
    • changedInput schema / properties / terms_id / description
      Previous value: -"DELIVERY_TERMS: terms_id from witness_register_terms."New value: +"DELIVERY_TERMS or DELIVERY_SLA: terms_id from witness_register_terms."
  3. Changed3 schema fields changed
    • addedInput schema / properties / data_classification / description
      Added value: +"PUBLIC (default) or NON_PERSONAL_PUBLIC. Never send personal data."
    • addedInput schema / properties / interval_hours / description
      Added value: +"Optional: hours between checks (24 minimum on the free tier)."
    • addedInput schema / properties / kind / description
      Added value: +"AGENT_READINESS (agent URL), SUPPLIER_CARD (published card) or DELIVERY_TERMS (terms_id)."
  4. Added

TDQS

A4.1/5.0
Behavior5/5

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

With annotations only covering safety flags, the description adds substantial operational context: a 24-hour re-check cadence, a 3-free-watch quota, receipting of each change, optional webhook delivery, no account required, and the public/non-personal input constraint. These are exactly the traits an agent needs and none are duplicated from the 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?

Front-loaded with the usage trigger, followed by compact operational facts in two dense sentences with no filler. A slightly tighter structure could separate the quota/cadence facts from the input constraints, but nothing is wasted.

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 an 8-parameter tool with a nested handle object and no output schema, the description covers cadence, quota, receipting, webhook, cost, and data constraints. It does not describe how watch results are retrieved (presumably via gaip_watch_events), a minor omission given no output schema exists.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents every parameter including the kind enum, interval_hours bounds, and the nested continuity_handle. The description only names continuity_handle, kind and target_url, which restates the schema rather than adding format or precedence detail, matching the baseline 3.

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?

The description states a clear verb and resource ('keep an eye on an agent or MCP server') and the title adds 'Watch ... for changes', so the agent can tell this registers a monitoring watch rather than reading or removing one. It does not explicitly name the sibling tools it differs from (gaip_watch_list, gaip_watch_events, gaip_watch_remove), so it stops short of a 5.

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 a concrete invocation trigger with a user phrasing example ('tell me if it changes or goes down'), which tells the agent when this tool applies. There is no exclusion or explicit alternative-routing (e.g., use watch_events to read results), so it is clear context without alternatives.

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.