Skip to main content
Glama
Sign In

Zetlyn

by com.zetlyn
OverviewDiscussionsAdmin

Watch a page

watch_page

Start watching a page: one place on it (give the selector from preview_page) or the whole page (no selector). A JSON field is a place like any other; a feed watched whole is told by its new entries. Zetlyn checks it every hour (with a subscription as often as every minute, see every_minutes) and notifies the account when it changes.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "url": "<url>"
    },
    "name": "watch_page"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYesThe page's address.
selectorNoThe selector of the place to watch, from preview_page. Leave out to watch the whole page.
notify_whenNoTell the person only when the value comes to meet this, not on every change: {"below": 400} or {"above": 1000} (the amount of money in the place, a number beside €, $, EUR and the like, else its first number; needs a selector; a place showing two different amounts is refused, mark a narrower one), {"contains": "In stock"} or {"not_contains": "Sold out"} (case does not matter). Told once when it comes true, again only after it stopped being true. Leave out to be told of every change.
confirm_costNoOnly when the person agreed: a watch beyond the 10 in the subscription costs 0.50 € a month more. Without it such a watch is refused with the price, to ask them first.
every_minutesNoHow often to check, in minutes. 60 if left out; 15, 5 and 1 need a subscription.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Adds substantial behavior beyond the annotations: hourly check cadence, sub-hourly frequencies gated on a subscription, notification to the account, the 10-watch limit with a 0.50 €/month overage, refusal with price when confirm_cost is absent, and notify_when's once-until-reset firing semantics. Consistent with readOnlyHint=false and destructiveHint=false since it creates a watch without removing anything.

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?

Three sentences, front-loaded with the core action and its two modes, and no filler. The feed/JSON-field sentence is slightly dense and idiosyncratically phrased but carries real information about whole-page feed behavior.

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 mutating, cost-bearing tool with no output schema, the description covers cadence, billing thresholds, consent, and notification semantics well. It leaves unstated what happens when a watch for that URL already exists (presumably update_watch) and any auth requirements, so not fully complete.

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 itself details notify_when's money parsing, so the baseline is 3; the description still adds value by stating the selector-vs-whole-page rule and the every_minutes/subscription dependency, and by flagging that notify_when needs a selector.

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?

States a specific verb and resource ("Start watching a page") plus the two modes of operation: a single place via a selector from preview_page, or the whole page with no selector. It does not explicitly differentiate from siblings like update_watch or get_watch, but the create-a-watch scope is clear.

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?

Gives clear selection rules for the two usage modes (selector = one place, no selector = whole page, feed watched whole = entries) and references preview_page as the source of a valid selector. Also cues confirm_cost as consent-gated ("Only when the person agreed"). No explicit when-not-to-use (e.g. an existing watch should go to update_watch instead), which keeps it off a 5.

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

All Zetlyn 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