Skip to main content
Glama

web_read

Read-only

Read a specified web page by URL and return its full text, including support for long documents with pagination.

Instructions

Read a web page by address and return its text.

HOW IT DIFFERS FROM web_search, WHICH ALSO READS. That one reads the top three links of its own results at 6000 characters each — enough for an answer. This one takes the addresses YOU name, up to five at a time, reads them in full with a cursor over a long document, can demand the browser and can check for a marker. If you need an answer, search is enough; if you need to work with a document, come here.

WHEN TO CALL. You need the text of a specific page whose address is already known — from web_search results or from the user. You need facts from an article rather than a snippet about it. Read a long page in parts: the same call with the offset named at the end of the truncated text.

WHEN NOT TO CALL. There is no address yet — use web_search first. You need an office document (DOCX, XLSX) — the tool does not parse those and will say so plainly; PDF, however, IS read. A search-engine result page must not be read: it merges neighbouring results into one text and hands you facts about a namesake.

WHAT IT RETURNS. results[] per address: content — the page text, status — what became of it, title, published, lang, final_url (where a redirect led), stub_check — whether this is a block; text_source — HOW the text was obtained.

HOW TO READ THE ANSWER — four things that are easy to get wrong.

  1. EMPTY CONTENT IS A SUCCESS, not a failure: the page opened and has no text in it. Repeating is pointless, take another source. On a refusal or a failure to open, repeating does make sense.

  2. ok is about the TOOL, not about the pages: it stays true even if not one page was read. Look at count and failed, and at the status of each address: read, empty, stub, refused, unreachable, forbidden, not_reached. They mean different things and call for different next steps — empty is not worth repeating, refused and unreachable are; not_reached is news about US (out of time, the per-domain rate limit, or beyond the batch ceiling) and says nothing about the page.

  3. text_source IS REQUIRED READING when it says the text was recognised. That is a scanned PDF with no text layer: the pages were rendered and read by a vision model, and such text MUST NOT be quoted as exact — a measurement recovered 94% of the reference numbers. The details are in the recognition field, including the dpi and whether the model's answer was cut off. A text layer means "copied out of the file" and is quotable verbatim.

  4. A stub status means we met an anti-bot shield or a paywall: text arrived, but it is not from the page. Do not retell it as the content. A stub_check of "not checked" is NOT "clean".

PDF. It is read; pages and pages_read say how many pages the document has and how many were parsed. An empty result on a PDF means "there are pages and no text" — that is a scan, cured by recognition rather than by repeating. And remember: in a PDF the characters can be extracted correctly while the reading order falls apart, so labels come away from their values. Do not assemble "property: value" pairs out of adjacent PDF lines without checking that they really are adjacent.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNohow to fetch. auto (default) and plain use an ordinary request. browser goes through a real browser, for pages with a script-based check; if that path is not wired up the call returns a did-not-get-through status — see paths_available in the answer
urlsYespage addresses, from 1 to 5 per call. Take them verbatim from web_search results, do not guess at them. Addresses beyond the ceiling come back with a did-not-get-through status — they never vanish silently
freshNofalse by default. Do not take the result from the read cache (it lives 300 s). Use it when the page is known to be changing as you watch
linksNofalse by default. Return the page links as a list. links_total is ALWAYS returned: an empty list with links_total > 0 means "you did not ask", not "there are none"
expectNomarkers that MUST occur in the text if this is the right page. Set them when the address was found by an organisation or person name: a status code and a title are forged by a stub, knowledge of the content is not. Not found gives expected_found=false
formatNomarkdown (default) — text with headings and links; text — text only, cheaper in characters; html — as it came, for parsing the markup
offsetNothe character to continue reading from, counted from zero. The tool names the continuation number itself at the end of the truncated text — take it from there rather than computing it
max_charsNohow many characters of content to return per address, default 20000. The remainder is not lost — it is fetched by the next call with an offset

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv0.2.1

TDQS

A5/5.0
Behavior5/5

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

The description goes far beyond the readOnlyHint and destructiveHint annotations, detailing caching behavior, fetch modes, status semantics, PDF recognition caveats, and anti-bot stub handling. It even warns that empty content is a success and that 'ok' refers to the tool, not the pages. No contradictions with annotations exist.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Although lengthy, the description is tightly organized with clear section headers (WHEN TO CALL, WHEN NOT TO CALL, WHAT IT RETURNS, HOW TO READ THE ANSWER, PDF). Each paragraph addresses a distinct concern, and the detail is justified given the tool's multiple edge cases and status semantics.

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?

With no output schema present, the description thoroughly explains the return structure (results[], status, text_source, stub_check, recognition) and how to interpret each status. It also covers failure modes, cache behavior, rate limits, and PDF handling, leaving no critical context unexplained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Every parameter is explained in the schema, and the description adds crucial operational meaning: offset should be taken from the tool's truncation note, links_total is always returned, expect markers help verify pages found by name, and max_chars default is clarified. This goes well beyond the schema's basic field descriptions.

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 opens with a specific verb and object: 'Read a web page by address and return its text.' It clearly distinguishes itself from web_search, which returns snippets from search results, making the tool's unique purpose unmistakable.

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 CALL and WHEN NOT TO CALL sections state exactly when to use this tool versus web_search, when to avoid office documents, and how to handle pagination with offset. This leaves no ambiguity about appropriate invocation.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/AG-Bureau/mcp-search'

If you have feedback or need assistance with the MCP directory API, please join our Discord server