doc-scraper

Overview Schema Source Related Servers Discussions Admin

get_page

Read-onlyIdempotent

Instructions

Fetch an HTML page live over the network and return its content as markdown. This is an on-demand fetch independent of any crawl: it does not read the stored crawl output, and it ignores the site's configured content_selector and scope. Large pages are truncated at max_bytes; follow next_offset to read the rest (each call fetches the page again).

Input Schema

Name	Required	Description
`url`	Yes	The URL to fetch
`offset`	No	Byte offset into the page content, for reading a truncated page in parts (default: 0)
`max_bytes`	No	Maximum content bytes to return (default: 102400, max: 1048576; larger values are capped, 0 or less means the default)
`content_selector`	No	CSS selector for main content (defaults to 'body')

Output Schema

Name	Required	Description
`url`	Yes
`title`	Yes
`offset`	Yes
`content`	Yes	Page content converted to markdown
`truncated`	Yes
`next_offset`	No	Pass as offset to read the next part; present only when truncated
`total_length`	Yes	Bytes of the whole converted page
`fetch_time_ms`	Yes
`content_length`	Yes	Bytes of content in this response

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedv2.21.0Oct 21, 2026

addedInput schema / properties / max_bytes

Added value: +{
+  "description": "Maximum content bytes to return (default: 102400, max: 1048576; larger values are capped, 0 or less means the default)",
+  "type": "integer"
+}

addedInput schema / properties / offset

Added value: +{
+  "description": "Byte offset into the page content, for reading a truncated page in parts (default: 0)",
+  "type": "integer"
+}

addedOutput schema / properties / content_length / description
```
Added value: +"Bytes of content in this response"
```

addedOutput schema / properties / next_offset

Added value: +{
+  "description": "Pass as offset to read the next part; present only when truncated",
+  "type": [
+    "null",
+    "integer"
+  ]
+}

addedOutput schema / properties / offset
```
Added value: +{
+  "type": "integer"
+}
```

addedOutput schema / properties / total_length

Added value: +{
+  "description": "Bytes of the whole converted page",
+  "type": "integer"
+}

addedOutput schema / properties / truncated
```
Added value: +{
+  "type": "boolean"
+}
```

changedOutput schema / required

Previous value: -[
-  "url",
-  "title",
-  "content",
-  "content_length",
-  "fetch_time_ms"
-]New value: +[
+  "url",
+  "title",
+  "content",
+  "content_length",
+  "total_length",
+  "offset",
+  "truncated",
+  "fetch_time_ms"
+]

Changed1 schema field changedv2.15.0Oct 17, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "content": {
+      "description": "Page content converted to markdown",
+      "type": "string"
+    },
+    "content_length": {
+      "type": "integer"
+    },
+    "fetch_time_ms": {
+      "type": "integer"
+    },
+    "title": {
+      "type": "string"
+    },
+    "url": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "url",
+    "title",
+    "content",
+    "content_length",
+    "fetch_time_ms"
+  ],
+  "type": "object"
+}

First observedSep 6, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare it read-only and open-world, but the description adds materially: bypassing crawl storage and site config, truncation at max_bytes, and the non-obvious cost that each paginated call re-fetches the page. The only blemish is the reference to a 'next_offset' field that does not exist in the schema (the parameter is 'offset'), which could momentarily confuse an agent.

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?

Three tight sentences, front-loaded with the action and the crawl-independence caveat before the truncation mechanics. Nearly every clause earns its place; the 'next_offset' wording is the one piece of noise that should have been 'offset'.

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?

For a 4-parameter fetch tool with full schema coverage and an output schema, the description covers what an agent must know: it is live, it ignores stored/config state, and large pages are truncated with a re-fetch cost. Nothing essential is missing.

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 coverage is 100%, so the baseline is 3 and all four parameters already carry descriptions. The description adds real meaning for offset/max_bytes by tying them to truncation and the refetch requirement, but it does so under a mismatched name ('next_offset'), so the added value is partial rather than clean.

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 ('Fetch an HTML page live over the network and return its content as markdown') and immediately scopes it against the crawl-based siblings by saying it does not read stored crawl output. An agent can distinguish this from read_page/list_pages/crawl_site 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly frames the tool as an on-demand live fetch independent of any crawl and notes it ignores the site's content_selector and scope, which is exactly the condition that decides between this and the stored-crawl siblings. It stops short of naming the concrete alternative (read_page) or stating when a live fetch is wasteful, so it is clear context rather than full routing guidance.

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

Deploy Server