OmniSnap MCP

Watch for a while

watch_page

Read-only

Monitors a page for a set number of seconds and reports console errors, failed requests, and layout shifts that occur during the watch. Use it while reproducing a bug or after a change.

Instructions

Watches the page for a number of seconds and reports the console errors, failed requests and layout shifts that happen during it. Every other tool here asks a question and gets an answer as of that instant; most of what goes wrong does not wait to be asked. Use it while the user reproduces something, or just after a change, when asking afterwards would find a page that looks fine.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

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

Input Schema

Name	Required	Description	Default
`seconds`	No	How long to watch.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.3Nov 11, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations only declare readOnlyHint and openWorldHint; the description adds the substantive behavior that the call occupies a time window and captures transient events (console errors, failed requests, layout shifts) rather than a snapshot. It does not say what happens if nothing is observed or whether the call blocks for the full duration, but it substantially exceeds annotation coverage.

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?

Opens with the core behavior and what is reported, then justifies why the tool exists. The middle sentence about things not waiting to be asked is rhetorical but earns its place by establishing the temporal-observation rationale; it could be trimmed slightly without loss.

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 enumerates the return contents (console errors, failed requests, layout shifts), so an agent knows what it will get back. With a single well-documented parameter, purpose, timing and returns are all covered.

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?

Only one parameter (seconds) and the schema documents it fully at 100% coverage with default, min and max. The description's phrase 'for a number of seconds' restates the parameter without adding format, budget or scaling guidance, so baseline 3 applies.

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 specific verb (watches) and resource (the page), plus exactly what it reports: console errors, failed requests and layout shifts occurring over the interval. It also distinguishes itself from the sibling family by contrasting temporal observation with the instant-answer query tools.

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 concrete triggering contexts: while the user reproduces a bug, or just after a change when a later query would see a page that already looks fine. It characterizes the alternative class (instant query tools) without naming specific siblings, so the routing signal is clear but one step short of explicit when-not guidance.

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