Skip to main content
Glama

notolens

by com.notolens
OverviewDiscussionsAdmin

Preview domain

preview_domain

Render a domain before adding it as an asset on a monitor with a capture reference. A preview exists only for a planned add_asset: it needs the monitor, passes the same checks add_asset would (valid domain, plan slot free, not already watched) and its confirm records that the user asked for the add. Returns the normalized domain, the screenshot as image content so it can be shown to the user, plus a capture_token bound to that domain with its expiry in expires_at (a few minutes). The image is for the user to approve; the token then goes to add_asset as reference.capture_token, and a new preview_domain call retries the render. captured is true only when the render produced a screenshot. A render that got only the site icon (captured false) still returns a capture_token, which stores that icon alone; a failed or blocked render with no icon returns the outcome with no token. When captured is false, upload or skip are the alternatives. Requires write access, since it only makes sense when setting up monitoring.

Input Schema

NameRequiredDescriptionDefault
domainYesA valid domain, e.g. "acme.com".
confirmYesRequired. true records that the user asked to add this domain to this monitor; a preview is the first step of add_asset, not a standalone lookup.
monitor_idYesMonitor id from list_monitors or create_monitor. The render is for a domain asset planned on this monitor.

Output Schema

NameRequiredDescriptionDefault
domainYesThe normalized domain that was rendered, the value for add_asset.
resultYes
capturedYes
expires_atYes
capture_tokenYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedOutput schema / properties / domain
      Added value: +{
+  "description": "The normalized domain that was rendered, the value for add_asset.",
+  "type": "string"
+}
    • changedOutput schema / required
      Previous value: -[
-  "result",
-  "captured",
-  "capture_token",
-  "expires_at"
-]New value: +[
+  "domain",
+  "result",
+  "captured",
+  "capture_token",
+  "expires_at"
+]
  2. Changed1 schema field changed
    • changedOutput schema / properties / result / enum
      Previous value: -[
-  "ok",
-  "unreachable",
-  "blocked"
-]New value: +[
+  "ok",
+  "http_error",
+  "unreachable",
+  "blocked"
+]
  3. Changed1 schema field changed
    • changedInput schema / properties / confirm / description
      Previous value: -"Required. Set true only after the user has asked to add this domain to this monitor; a preview is the first step of add_asset, never a standalone lookup."New value: +"Required. true records that the user asked to add this domain to this monitor; a preview is the first step of add_asset, not a standalone lookup."
  4. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false) cover the safety profile, and the description adds substantial context beyond them: it requires write access, re-runs the same validation as add_asset, records the user's confirmation, and describes the token's binding and short expiry. It also discloses failure modes (icon-only renders still return a token; fully blocked renders return no token).

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 purpose and organized around the preview→token→add_asset flow, with no truly wasted sentence. It is dense and a few clauses (the captured/icon/token cascade) are hard to parse on first read, slightly hurting scanability.

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?

Although an output schema exists, the description still clarifies the returned token's purpose and expiry semantics, and it covers prerequisites, alternates, and failure paths. Nothing an agent needs to call this correctly in conjunction with add_asset is missing.

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, but the description adds cross-parameter workflow meaning: confirm records that the user requested the add, monitor_id identifies the planned destination, and capture_token is passed to add_asset as reference.capture_token. This goes beyond the field-level schema text.

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 and resource ("Render a domain before adding it as an asset on a monitor") and immediately scopes it against the sibling: it is not a standalone lookup but the first step of add_asset. An agent can distinguish it from add_asset and prepare_asset_upload without opening any schema.

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?

Explicit when-to-use (before adding an asset), explicit when-not ("a preview is the first step of add_asset, not a standalone lookup"), and explicit alternatives for the captured=false case ("upload or skip are the alternatives"). It also routes the follow-up: token goes to add_asset, and a new preview_domain call retries the render.

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

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