Skip to main content
Glama

preview_endpoint

FREE. See what a paid WebLens endpoint costs and what it returns before paying: the live price, a one-line summary, and a recorded sample of the exact response shape. Endpoints with no paid upstream (/fetch/basic, /contents, /map) also run a real truncated LIVE preview when you pass a url; SerpAPI- and Anthropic-backed endpoints return the recorded sample only, because free live runs there would burn upstream credits. Price: free

Input Schema

NameRequiredDescriptionDefault
urlNoFor fetch-backed endpoints only: run a real truncated preview of this URL
domainNoFor /domain only: run a real, summarised preview of this domain
endpointYesPaid endpoint path to preview, e.g. "/answer"

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • addedInput schema / properties / domain
      Added value: +{
      +  "description": "For /domain only: run a real, summarised preview of this domain",
      +  "maxLength": 253,
      +  "minLength": 3,
      +  "type": "string"
      +}
    • addedInput schema / properties / endpoint / maxLength
      Added value: +100
    • addedInput schema / properties / endpoint / minLength
      Added value: +1
    • changedInput schema / properties / url / description
      Previous value: -"Fetch-backed endpoints only (/fetch/basic, /contents, /map): run a real truncated preview of this URL"New value: +"For fetch-backed endpoints only: run a real truncated preview of this URL"
    • addedInput schema / properties / url / format
      Added value: +"uri"
  2. First observed

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does so well: it discloses cost (free), why live runs are restricted (would burn upstream credits), that previews are truncated/summarised, and that output may be a recorded sample rather than live. It stops short of covering auth needs or rate limits, but the behavioral profile is otherwise rich.

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 'FREE' and the core purpose, then dense but purposeful detail. Every sentence carries information; the endpoint-class distinction is a long clause but earns its place. Slightly heavy for a preview tool, but not padded.

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?

No output schema exists, so the description must explain return values, and it does: price, summary, and response-shape sample. Combined with the live-vs-recorded distinction, an agent has what it needs to call and interpret the tool, though it could note any pagination or size limits.

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 real meaning by tying the url parameter to live-preview behavior for fetch-backed endpoints and the domain parameter to /domain summarised previews. It clarifies the conditional semantics the schema only hints at.

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 (preview) and resource (endpoint), and precisely enumerates what the tool returns: live price, one-line summary, and a recorded sample of the response shape. It is clearly distinguishable from all the paid sibling endpoints it previews.

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 frames the use case ('before paying') and then goes further, splitting endpoints into two behavioral classes: fetch-backed ones (/fetch/basic, /contents, /map) that run a live truncated preview, versus SerpAPI/Anthropic-backed ones that return only the recorded sample. That is exactly the when/when-not routing an agent needs.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.