WebLens

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; search- and Anthropic-backed endpoints return the recorded sample only, because free live runs there would burn upstream credits. Price: free

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": {
      "endpoint": "<endpoint>"
    },
    "name": "preview_endpoint"
  }
}

Input Schema

Name	Required	Description
`url`	No	For fetch-backed endpoints only: run a real truncated preview of this URL
`domain`	No	For /domain only: run a real, summarised preview of this domain
`endpoint`	Yes	Paid endpoint path to preview, e.g. "/answer"

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedOct 13, 2026

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"
```

First observedAug 4, 2026

TDQS

A4.3/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden, and it does well: it discloses that the call is free, that previews are truncated, that some endpoints only return a recorded sample and why, and that live runs depend on passing a url. The only gap is that it doesn't describe the exact response envelope beyond 'live price, summary, sample'.

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?

Content is front-loaded (FREE, then what you get) and dense with useful specifics. However, the trailing 'Price: free' duplicates the leading 'FREE.' and is pure waste in an otherwise tight two-sentence definition.

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?

With no annotations and no output schema, the description supplies the safety/cost profile and the shape of the return value, which is the critical missing information. It is nearly complete; only the exact response structure and whether previews are rate-limited or cached is left to discovery.

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 baseline is 3, but the description adds genuine conditional meaning beyond the schema: passing a url triggers a real truncated LIVE preview only for /fetch/basic, /contents, and /map, and is inert for search/Anthropic-backed endpoints. The `domain` parameter's live behavior is covered in the schema rather than the description, which keeps this from 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?

The description states a specific verb+resource: preview a paid WebLens endpoint to see its live price, one-line summary, and recorded sample response shape. The 'before paying' framing makes its role distinct from every sibling (which are the actual paid endpoints being previewed), so an agent can route correctly without opening a schema.

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?

It says when to use it (before paying, to learn cost/return shape) and precisely which endpoints can produce a live preview versus a recorded sample only, including the reason (upstream credits). It stops short of an explicit 'if you want the real result, call the endpoint itself' redirect, but the usage context is otherwise unambiguous.

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

All WebLens 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.