Zetlyn

Preview a page

preview_page

Read-onlyIdempotent

Read a public web page (or JSON, an RSS or Atom feed, XML or plain text, each read as a page of its own: one line per value, the field's path beside it) and list the places on it that can be watched, each with the selector that marks it, what it says now, and the text beside it: the page's own content first, its menus, header and footer last. Call this before watch_page to choose a place. If the place the person means is not among them, call it again with find (a word or sign the place says, such as "€", "In stock" or "Version"), which searches the whole page. If it fails saying the site does not let programs read the page, that page cannot be watched: tell the person, and do not call watch_page for it.

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": "preview_page"
  }
}

Input Schema

Name	Required	Description	Default
`url`	Yes	The page's address, e.g. https://example.com/pricing
`find`	No	Only the places whose text, or the text beside them, says this (case aside), from the whole page.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already cover readOnly/idempotent/openWorld, and the description adds real behavior beyond them: result ordering (page content first, menus/header/footer last), how JSON/RSS/Atom/XML/plain text are rendered (one line per value with the field path beside it), and the precise failure semantics when a site refuses programmatic access. That is disclosure the agent could not get 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?

The core purpose and the watch_page ordering rule are front-loaded and every sentence carries operational information. The opening sentence is a dense run-on with nested parentheticals that slows parsing, though nothing is truly redundant.

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?

There is no output schema, yet the description explains the shape of what comes back (selector, current text, adjacent text, ordering), the page-type variations, the retry path, and the unrecoverable failure case. An agent can call this correctly and interpret the result without further information.

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% so the baseline is 3; the description goes further by explaining that find searches the whole page rather than only the initially listed places, and gives concrete example tokens ('€', 'In stock', 'Version'). It doesn't add format or escaping details, so it stops short of a 5.

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?

States a concrete verb and resource — read a public page and list the watchable places on it — and specifies what each listed place carries (selector, current value, adjacent text). This clearly separates it from watch_page (which creates the watch) and read_place (which reads a chosen place).

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?

Explicitly says to call it 'before watch_page to choose a place', gives the fallback when the place is absent ('call it again with find'), and states that on a site-blocks-programs failure the page cannot be watched and watch_page must not be called. When-to-use, retry path, and a hard exclusion are all present.

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

All Zetlyn tools Inspect

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

Need Help?