Skip to main content
Glama

read_page

Read-only

Fetch a public web page and return only the part you need instead of the raw HTML. view: markdown (main content, navigation and boilerplate removed), outline (headings), links (all links; query keeps those whose URL or text contains it), tables (one table, chosen by table, as a markdown table), find (only passages mentioning query; query required). Use this for any single page; use read_package_info for PyPI, npm and crates.io, and run_pipeline for multi-step extraction (e.g. filtering a table's rows). Reads the live page each call and doesn't run JavaScript, so pages built in the browser may come back thin. Only public http(s) addresses. Fetches are limited to 60 a minute per client. Errors (unreachable site, non-HTML content, no table at that index) come back with a suggested fix. Each call runs a built-in page recipe and is recorded in its public run statistics; otherwise nothing is kept except the result's handle, for 60 minutes.

Input Schema

NameRequiredDescriptionDefault
urlYesPublic http(s) URL of the page.
viewNomarkdown
queryNofind: the word or phrase to look for (required). links: keep links whose URL or text contains it.
tableNotables: which table, 0 = first, -1 = last.
max_tokensNoMost tokens to return. markdown is trimmed (and marks the cut); other views return a preview and handle instead.

Output Schema

NameRequiredDescriptionDefault
valueNomarkdown/outline: text. links: [{href, text}]. tables: markdown table. find: [{match, context, line, offset}].
handleNoHandle id (h_...) of the full result, for run_op or read_handle.
previewNoInstead of value, when the result is over max_tokens.
warningNoThe result looks wrong for this view, e.g. empty.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed12 schema fields changed
    • changedInput schema / properties / max_tokens / description
      Previous value: -"Most tokens to return; markdown is trimmed to fit."New value: +"Most tokens to return. markdown is trimmed (and marks the cut); other views return a preview and handle instead."
    • removedInput schema / properties / max_tokens / title
      Removed value: -"Max Tokens"
    • changedInput schema / properties / query / description
      Previous value: -"find: what to look for. links: keep links containing it."New value: +"find: the word or phrase to look for (required). links: keep links whose URL or text contains it."
    • removedInput schema / properties / query / title
      Removed value: -"Query"
    • changedInput schema / properties / table / description
      Previous value: -"tables: which one, 0 = first, -1 = last."New value: +"tables: which table, 0 = first, -1 = last."
    • removedInput schema / properties / table / title
      Removed value: -"Table"
    • changedInput schema / properties / url / description
      Previous value: -"The page to read (http or https)."New value: +"Public http(s) URL of the page."
    • removedInput schema / properties / url / title
      Removed value: -"Url"
    • removedInput schema / properties / view / title
      Removed value: -"View"
    • removedInput schema / title
      Removed value: -"read_pageArguments"
    • addedOutput schema / properties
      Added value: +{
      +  "handle": {
      +    "description": "Handle id (h_...) of the full result, for run_op or read_handle.",
      +    "type": "string"
      +  },
      +  "preview": {
      +    "description": "Instead of value, when the result is over max_tokens."
      +  },
      +  "value": {
      +    "description": "markdown/outline: text. links: [{href, text}]. tables: markdown table. find: [{match, context, line, offset}]."
      +  },
      +  "warning": {
      +    "additionalProperties": true,
      +    "description": "The result looks wrong for this view, e.g. empty.",
      +    "type": "object"
      +  }
      +}
    • removedOutput schema / title
      Removed value: -"read_pageDictOutput"
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Despite annotations already covering the safety profile, the description adds substantial behavioral context the annotations cannot: it reads the live page (not cached), does not execute JavaScript so browser-built pages come back thin, only accepts public http(s), is rate limited to 60 fetches/minute per client, returns errors with suggested fixes, and runs a public recipe recorded in run statistics with only the result handle retained for 60 minutes. This is unusually rich disclosure of constraints, failure modes, and data retention.

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 the view-mode semantics before constraints, and essentially every sentence carries non-redundant information. It is a dense single paragraph rather than a broken-up list, which slightly raises scan cost, but there is no filler to cut.

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 restated. Combined with coverage of rate limits, JS limitations, error behavior, and handle retention, the description gives an agent everything needed to call this correctly on the first attempt.

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 80%, but the `view` enum has no per-value schema description, and the description fills exactly that gap by defining what markdown/outline/links/tables/find each return and noting that find requires `query`. It also clarifies the `table` index convention and the trimming behavior of max_tokens, adding meaning beyond the schema.

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?

Opens with a specific verb+resource ('Fetch a public web page') plus a distinct value proposition ('return only the part you need instead of the raw HTML'). It names the sibling tools it is not (read_package_info, run_pipeline), 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 Guidelines5/5

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

Explicitly states 'Use this for any single page' and then names the alternatives with the exact condition that selects each: read_package_info for PyPI/npm/crates.io, run_pipeline for multi-step extraction like filtering table rows. When-to-use and when-not-to-use are both present with concrete examples.

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.

Resources