screenshot.com.ar

Read a web page as markdown

read_page

Read-onlyIdempotent

Open a public web page in a real Chrome browser (JavaScript is executed) and return its main content as clean markdown: title, headings, text, links, lists and tables, without navigation, footers, ads or cookie banners. Best tool to read articles, docs, product pages or search results.

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": {
      "url": "<url>"
    },
    "name": "read_page"
  }
}

Input Schema

Name	Required	Description	Default
`url`	Yes	Public http(s) URL of the page. If the scheme is missing, https:// is assumed.
`max_chars`	No	Maximum length of the returned markdown, in characters (100-200000). Default 50000.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely non-redundant behavior: rendering happens in a real Chrome browser with JavaScript executed, and boilerplate (navigation, footers, ads, cookie banners) is stripped from the extracted content.

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?

Two sentences, no filler, with the core action and output shape front-loaded and the use-case guidance trailing. Every clause carries information an agent can act on.

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 output schema, the description carries the burden of describing return values and does so thoroughly, including what is excluded. It leaves unstated what happens for pages that fail to load, are blocked, or exceed max_chars, which a robust definition would cover.

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% – the url scheme assumption and max_chars range/default are fully documented in the schema itself. The description adds only the 'public http(s)' restriction, which the schema partially implies, so baseline 3 applies.

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?

States a specific verb and resource ('Open a public web page') plus the exact output format ('clean markdown' with title, headings, text, links, lists, tables), which is far more than a restatement of the name. It does not explicitly contrast with the screenshot siblings, so an agent must infer the difference from the absent screenshot mention.

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?

'Best tool to read articles, docs, product pages or search results' gives concrete use cases, and 'public' web page signals that authenticated or private pages are out of scope. No sibling alternative is named for the case where a visual capture is needed, which keeps this below a 5.

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

All screenshot.com.ar 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.

Resources

Need Help?