searchts

Overview Schema Source Related Servers Discussions Admin

read_url

Fetch any URL as clean Markdown, bypassing bot walls and JS rendering via an escalating unlocker. Use when plain fetches fail or search snippets are thin.

Instructions

Read one web page as clean Markdown, escalating through an unlocker ladder (Chrome-fingerprint fetch -> JS-rendering relay -> stealth browser) that stops at the first tier returning real content. When the user asks what a URL says, call this first. Do not start with a plain fetch. A 200 that is a sign-in form, a join page, or a bot check is not the page. Also use this when a plain fetch was blocked (403/429, a Cloudflare/DataDome/PerimeterX bot-wall, or an 'enable JavaScript' page), the content is rendered client-side, or a previous web_search snippet was blocked, thin, or empty. Do not answer from a blocked snippet or from the login chrome — call this tool on that URL. Returns Markdown ready to feed a model, always strips invisible/control characters, and if prompt-injection indicators are detected it fences the body as untrusted and prepends a one-line warning. When the page has more than this read returned (a next page, a feed, folded text, a list it mostly dropped), the text ends with a bracketed note and the JSON has 'next_url' and 'more'; read 'next_url' to continue. No note does not prove the page is complete. Returns an 'Error: ...' string (not an exception) when every tier fails.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`url`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.8.0Aug 29, 2026

removedInput schema / properties / url / description

Removed value: -"Absolute http(s) URL of the page to read."

addedInput schema / properties / url / title
```
Added value: +"Url"
```
addedInput schema / title
```
Added value: +"read_url_toolArguments"
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "result": {
+      "title": "Result",
+      "type": "string"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "title": "read_url_toolOutput",
+  "type": "object"
+}

First observedv0.5.1Jul 6, 2026

TDQS

A4.4/5.0

Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so richly: escalation order and stopping condition, invisible/control-character stripping, prompt-injection fencing with an untrusted-body marker, 'next_url'/'more' truncation signaling with the caveat that absence of a note does not prove completeness, and error-return semantics ('Error: ...' string, not an exception). That is materially more than any structured field provides.

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?

Action and mechanism are front-loaded in sentence one, and the escalation tiers are easy to scan. It is on the long side and repeats the plain-fetch prohibition in three separate sentences ('Do not start with a plain fetch', 'Also use this when a plain fetch was blocked', 'Do not answer from a blocked snippet'), which could be consolidated without losing meaning.

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?

An output schema exists, so return values need not be explained, yet the description goes further and covers next_url/more continuation, the truncation note, injection fencing, and error strings. Combined with the escalation semantics, an agent has everything needed to call this correctly and interpret the result.

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?

Schema description coverage is 0% for the single 'url' parameter, so the description must compensate. It implies a single page URL (singular 'one web page') rather than a list or domain, but never states format requirements such as absolute scheme, fragment handling, or whether redirects are followed. Marginal added meaning over the bare 'url' string.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence states a specific verb and resource ('Read one web page as clean Markdown') plus the mechanism (an unlocker ladder of three named tiers), so the agent knows exactly what it gets back. It routes away from naive plain fetches and from web_search snippets, but never acknowledges the sibling grab_site, whose name implies overlapping site-fetching behavior.

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 ('When the user asks what a URL says, call this first'), explicit when-not ('Do not start with a plain fetch'), and an enumerated list of triggering conditions (403/429, Cloudflare/DataDome/PerimeterX bot-walls, client-side rendering, thin or blocked search snippets). It even warns that a 200 sign-in form is not the page, which prevents a common false-positive selection.

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

Deploy Server