Skip to main content
Glama

Agent Watch

by io.github.entradox
OverviewDiscussionsAdmin

aw_watch

Idempotent

Add endpoints to your personal watchlist (probed immediately, then every 6h).

Plan-limited by the email used at checkout: free 5, Builder ($19/mo) 50,
Team ($99/mo) 500 endpoints. Alerts fire on alive→dead transitions and
tool-schema drift. Already-watched URLs are returned without re-probing.

Args:
    email: the email your subscription is under (free tier works too)
    urls: endpoint URLs to add to your watchlist
    watch_token: issued at registration, delivered in your onboarding email — required

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlsYes
emailYes
watch_tokenNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / watch_token
      Added value: +{
+  "default": "",
+  "title": "Watch Token",
+  "type": "string"
+}
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations: it explains immediate probing, periodic re-probing, alert conditions, plan-based quotas, required watch_token auth, and idempotent behavior for already-watched URLs. No contradiction with idempotentHint=true or destructiveHint=false.

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?

Dense but economical: purpose, behavior, plan limits, alert semantics, and parameters are covered in a few sentences with no filler. The most important information is front-loaded.

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?

Covers the main API contract: what the tool does, when it runs, what triggers alerts, plan constraints, and required token. It does not specify quota-exceeded behavior or detailed response shape, but this is still a well-specified tool description.

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 0%, but the Args section compensates by explaining all three parameters: email identifies the subscription/plan, urls are the endpoints to watch, and watch_token is required for the operation. It lacks format details for URLs, but the core meaning is clear.

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 description opens with a specific verb and object: 'Add endpoints to your personal watchlist.' It clearly distinguishes this from one-off checks and explains the monitoring behavior, so an agent can immediately identify the tool's purpose.

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?

The description provides clear context: this tool adds endpoints to a watchlist that are probed immediately and then every 6 hours, with alerts on state changes. It does not explicitly contrast with sibling tools like aw_check_endpoint, so it stops short of full when-to-use versus when-not-to-use guidance.

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

All Agent Watch 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