AgentReader

Server Details

AgentReader (agentreader.xyz): web pages, PDFs, JSON, CSV and text as Markdown. Card packs or x402.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 100.0% over 23 days
Last Tested: 2026-11-06 02:51
Transport: Streamable HTTP · MCP 2025-11-25
URL
ChatGPT: –
Claude: –

TDQS

A4.4/5.0

Scored 2026-11-05 18:55 across 4 tools

Disambiguation5/5

Each tool targets a completely distinct concern: read_url fetches page content, search finds pages, get_balance reports account credits, and report_issue files feedback. The read_url description even spells out the search→read workflow, so an agent cannot reasonably confuse them.

Naming Consistency4/5

All names are snake_case and mostly follow the verb_noun pattern (get_balance, read_url, report_issue). The bare verb 'search' is the sole deviation, but it remains clear and readable.

Tool Count5/5

Four tools exactly cover the server's scope — find (search), fetch (read_url), account status (get_balance), and feedback (report_issue). Nothing is redundant, and no tool feels like padding.

Completeness4/5

The read/search/account lifecycle is fully covered with no dead ends, including a feedback path for failures. Minor gaps remain, such as batch URL reads or search pagination controls, but agents can work around these easily.

Available Tools

4 tools

get_balanceGet balanceAInspect

Show remaining free calls and prepaid credits for the API key sent in the MCP connection headers, plus available credit bundles and how to buy them.

Name	Required	Description	Default
No parameters

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does disclose the key behavioral fact: identity comes from the MCP connection headers, so no credential parameter is needed. It also previews the payload shape (remaining calls, credits, bundles, purchase instructions), though it stays silent on error behavior for an invalid/exhausted key and does not explicitly label the operation as read-only.

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?

A single sentence that front-loads the primary resource (remaining calls and credits) before the secondary bundle/purchase detail. Dense but every clause adds information an agent needs; only the trailing purchase clause is marginal.

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?

For a zero-parameter read tool with no output schema, the description adequately covers what is returned (free calls, prepaid credits, available bundles, purchase path) and how identity is resolved. It is nearly complete, missing only failure-mode behavior when the key is invalid or credits are exhausted.

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?

The tool takes zero parameters and the schema is an empty object, so there is nothing for the description to disambiguate. Baseline of 4 applies, and the description correctly implies the caller supplies no arguments.

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 (Show) and resource (remaining free calls and prepaid credits) and scopes it to the API key carried in the MCP connection headers, plus secondary outputs (credit bundles and purchase path). It is unmistakably distinct from the only sibling, read_url, which performs an unrelated fetch operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

Usage is implied — an agent would call this to check quota or decide whether it needs to buy credits — but there is no explicit when-to-use cue, no precondition (e.g. valid key required), and no mention of alternatives or when not to call it.

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

read_urlRead URL / web page / PDF to MarkdownA

Read-onlyIdempotent

Inspect

Read a web page or PDF with AgentReader (agentreader.xyz) and return only its main content as clean Markdown (default) or JSON. Prefer this over a plain fetch when the page is JavaScript-rendered, behind a cookie/consent wall, a PDF, or large (raw HTML can be 20x the tokens). If the site blocks bots or is paywalled you get a clear error, are not charged, and should move on instead of retrying URL variants. Renders JavaScript with headless Chromium when needed and keeps code blocks verbatim. JSON adds title, author, date, links and tables. News homepages return headline lists, RSS/Atom feeds return items, mode=full returns the whole page. JSON URLs (APIs, e.g. datasets-server.huggingface.co) come back pretty-printed in a json block, or as parsed `data` with format=json; plain-text and Markdown files (.txt, .md, raw.githubusercontent.com) are returned cleaned; CSV (text/csv, .csv) comes back in a csv block, with parsed rows as data/tables when cheap. Images, audio, video, archives and office files get HTTP 415 (not charged). StackOverflow, npm and PyPI are read via their official APIs. Results with very little text carry meta.warning; if a result looks wrong, call report_issue. Pricing: 5 free reads/day without an API key; then credits on a key, which comes from a card pack your user buys at https://agentreader.xyz/buy ($3 for 2,000 reads or $10 for 7,000 reads + VAT where applicable) or from a crypto bundle (POST https://agentreader.xyz/v1/credits/buy?bundle=500, x402). Send the key as Authorization: Bearer (apps that can't set headers: connect to https://agentreader.xyz/mcp?api_key=). Or pay $0.005/read via x402 in the tool call.

Name	Required	Description
`url`	Yes	The page, PDF or RSS/Atom feed to read. Also accepted as u or link, without https://, or path style /v1/read/https://….
`mode`	No	article: main content only. links: list of headlines with links. full: the whole page, including non-article parts. auto picks article or links based on the page. RSS/Atom feeds always return their items. Default: auto.
`format`	No	markdown returns the content as Markdown only. json wraps the same Markdown with title, author, date, word count, links, tables and metadata (meta.warning flags results that may be incomplete); there is no separate plain-text copy. Default: markdown.
`render`	No	Whether to load the page in headless Chromium. auto does so only when plain fetching returns too little. Default: auto.
`extract`	No	Returns named fields (title, author, date, price, currency, image, brand, sku, rating, availability, summary…) from JSON-LD, OpenGraph, microdata and meta tags. No LLM. Missing fields are null. In JSON as `fields`, in Markdown as front matter. Default: (none).

TDQS

A4.7/5.0

Behavior5/5

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

Goes well past the readOnly/idempotent annotations: discloses headless Chromium rendering fallback, verbatim code-block preservation, HTTP 415 for unsupported media types, no charge on failure, meta.warning on thin results, API-backed sources (StackOverflow/npm/PyPI), and per-read pricing/auth mechanics. An agent knows both the failure modes and the cost consequences before calling.

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

Conciseness3/5

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

Purpose is front-loaded correctly in the first sentence, but the rest is a dense run-on paragraph mixing usage guidance, content-type behavior, and lengthy pricing detail (card packs in dollars, VAT, crypto bundle endpoint, x402 per-read rate). The pricing block is useful for cost awareness but is disproportionately verbose relative to selection needs.

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?

There is no output schema, and the description compensates fully: it explains the Markdown vs JSON return shapes, the extra JSON fields (`fields`, links, tables), the `data` key for JSON/CSV URLs, and the meta.warning signal. Nothing an agent needs to interpret results or avoid misuse is missing.

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 100%, so the baseline is 3, but the description adds real meaning about what the url parameter accepts and how each content type behaves (JSON pretty-printed into a ```json block, CSV into ```csv with parsed rows, .txt/.md cleaned, images/audio/video/office → 415). The mode and format explanations largely restate the schema descriptions rather than extending them, which keeps it out of 5 territory.

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 ('Read a web page or PDF with AgentReader') plus the exact output shape ('only its main content as clean Markdown (default) or JSON'). It also distinguishes itself from the generic alternative by naming when a plain fetch is insufficient, so an agent can identify it without opening the 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?

Gives an explicit selection rule ('Prefer this over a plain fetch when the page is JavaScript-rendered, behind a cookie/consent wall, a PDF, or large') and an explicit stop rule ('if the site blocks bots or is paywalled ... move on instead of retrying URL variants'). It also routes to a sibling ('call report_issue') when results look wrong.

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

report_issueReport a bad readAInspect

Tell AgentReader that a read failed or looked wrong (empty, not the main content, cut off, blocked although readable, ...), so we can fix it. Free, never charged, max 10 per day. We store the URL without its query string, the reason and your short note for 90 days; don't put personal data in the note.

Name	Required	Description
`url`	Yes	The page whose read went wrong
`note`	No	What you expected or what was wrong (max 300 characters; longer notes are cut)
`reason`	Yes	empty (little or no text), wrong_content (not the page's main content), missing_part (content cut off or missing), blocked_wrongly (error although the page is readable), too_long (too much boilerplate), error (unexpected error), other

TDQS

A4.7/5.0

Behavior5/5

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

Beyond annotations, it discloses meaningful behavior: the report is free and never charged, capped at 10 per day, stores the URL without its query string, reason, and note for 90 days, and warns against personal data in the note. These details are exactly the kind of retention, rate-limit, and privacy context annotations cannot convey.

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?

The description is front-loaded with the core action and purpose, then adds only essential constraints and privacy details. Every sentence earns its place: reporting intent, usage limits, data retention, and the personal-data warning.

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 simple three-parameter reporting tool with no output schema, the description supplies the missing behavioral context an agent needs: when to report, what happens to the data, retention period, rate limit, and privacy constraint. Annotations already cover safety hints, so this is complete.

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 100%, so the schema already documents url, note, and reason well. The description adds useful parameter-related meaning by stating that the URL is stored without its query string and that the note should not contain personal data, though it does not further explain reason semantics beyond the enum description.

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 uses a specific verb and resource: telling AgentReader that a read failed or looked wrong, with concrete failure examples such as empty, wrong content, cut off, and blocked. It clearly separates this reporting action from sibling tools like read_url and search, which perform reads rather than issue reports.

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?

It gives clear triggering conditions: use this when a read failed or looked wrong, with examples of failure modes. It also adds operational constraints such as free use, max 10 per day, and a privacy warning, though it does not explicitly name alternatives or when not to use it.

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

searchWeb searchA

Read-onlyIdempotent

Inspect

Search the web and get a ranked list of results (title, url, snippet). Use it to find pages, then call read_url on the best results to read them as clean Markdown. Priced like one read (free daily calls, credits or x402).

Name	Required	Description
`lang`	No	Optional language code, e.g. en, nl
`limit`	No	Max results (default 10)
`query`	Yes	Search query
`format`	No	markdown returns the content as Markdown only. json wraps the same Markdown with title, author, date, word count, links, tables and metadata (meta.warning flags results that may be incomplete); there is no separate plain-text copy. Default: markdown.

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint and destructiveHint, so the safety profile is covered. The description adds genuinely new operational context the annotations lack: the cost model ('priced like one read', free daily calls, credits or x402). It does not discuss rate-limit specifics or result pagination beyond the limit cap.

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?

Three tight sentences: capability and return shape first, workflow second, cost last. No filler, no repetition of the title, and every sentence carries information an agent needs.

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 compensates by naming the return fields and the cost model, and it explains the follow-up step with read_url. Minor gaps remain around result volume/pagination beyond the limit parameter, but nothing essential to a correct call 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 description coverage is 100% and the format enum is already fully documented in the schema, including the meta.warning caveat. The description adds no syntax or semantics beyond what the schema provides, so the baseline 3 applies.

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 ('Search the web') plus the exact return shape ('ranked list of results (title, url, snippet)'), so an agent knows what comes back without opening a schema. It also implicitly separates itself from the sibling read_url by casting search as the discovery step.

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 tells the agent when to use it ('find pages') and what to do next ('call read_url on the best results'), which is a clear routing rule against the only relevant sibling. It stops short of stating when-not to use it (e.g. for direct URL reads where read_url alone suffices), so it is strong but not exhaustive.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateOct 22, 2026
- Addedreport_issue

2 tool updatesOct 19, 2026

Changedread_url1 field changed

changedInput schema / properties / format / description

Previous value: -"markdown returns the text only. json adds title, author, date, links, tables and metadata. Default: markdown."New value: +"markdown returns the content as Markdown only. json wraps the same Markdown with title, author, date, word count, links, tables and metadata (meta.warning flags results that may be incomplete); there is no separate plain-text copy. Default: markdown."

Changedsearch1 field changed

changedInput schema / properties / format / description

Previous value: -"markdown returns the text only. json adds title, author, date, links, tables and metadata. Default: markdown."New value: +"markdown returns the content as Markdown only. json wraps the same Markdown with title, author, date, word count, links, tables and metadata (meta.warning flags results that may be incomplete); there is no separate plain-text copy. Default: markdown."

2 tool updatesOct 18, 2026

Changedread_url5 fields changed

changedInput schema / properties / extract / description

Previous value: -"Optional structured fields to pull from page metadata (JSON-LD, OpenGraph, microdata) and heuristics: comma list like 'title,author,date,price,currency,summary,image,brand,rating' or a JSON schema {properties:{price:{type:'number'}}}. Returned as `fields` (front matter in markdown)."New value: +"Returns named fields (title, author, date, price, currency, image, brand, sku, rating, availability, summary…) from JSON-LD, OpenGraph, microdata and meta tags. No LLM. Missing fields are null. In JSON as `fields`, in Markdown as front matter. Default: (none)."

changedInput schema / properties / format / description

Previous value: -"markdown (default) or json"New value: +"markdown returns the text only. json adds title, author, date, links, tables and metadata. Default: markdown."

changedInput schema / properties / mode / description

Previous value: -"auto (default): article text, or a headline+link list for news homepages/index pages; article: main article only; links: headline+link list; full: whole page as Markdown. RSS/Atom feeds always return their items."New value: +"article: main content only. links: list of headlines with links. full: the whole page, including non-article parts. auto picks article or links based on the page. RSS/Atom feeds always return their items. Default: auto."

changedInput schema / properties / render / description

Previous value: -"JavaScript rendering with headless Chromium: auto (default), never, always"New value: +"Whether to load the page in headless Chromium. auto does so only when plain fetching returns too little. Default: auto."

changedInput schema / properties / url / description

Previous value: -"http(s) URL of a web page, RSS/Atom feed or PDF (https:// assumed if omitted)"New value: +"The page, PDF or RSS/Atom feed to read. Also accepted as u or link, without https://, or path style /v1/read/https://…."

Changedsearch1 field changed

changedInput schema / properties / format / description

Previous value: -"markdown (default) or json"New value: +"markdown returns the text only. json adds title, author, date, links, tables and metadata. Default: markdown."

1 tool updateOct 16, 2026

Changedread_url1 field changed

removedInput schema / properties / archive

Removed value: -{
-  "description": "auto (default): if the live page is bot-blocked, return the latest Wayback Machine copy, flagged with meta.source='archive.org' and its snapshot time; never: fail instead",
-  "enum": [
-    "auto",
-    "never"
-  ],
-  "type": "string"
-}

1 tool updateOct 16, 2026

Changedread_url1 field changed

addedInput schema / properties / archive

Added value: +{
+  "description": "auto (default): if the live page is bot-blocked, return the latest Wayback Machine copy, flagged with meta.source='archive.org' and its snapshot time; never: fail instead",
+  "enum": [
+    "auto",
+    "never"
+  ],
+  "type": "string"
+}

2 tool updatesOct 16, 2026

Changedread_url3 fields changed

addedInput schema / properties / extract

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "additionalProperties": {},
+      "propertyNames": {
+        "type": "string"
+      },
+      "type": "object"
+    }
+  ],
+  "description": "Optional structured fields to pull from page metadata (JSON-LD, OpenGraph, microdata) and heuristics: comma list like 'title,author,date,price,currency,summary,image,brand,rating' or a JSON schema {properties:{price:{type:'number'}}}. Returned as `fields` (front matter in markdown)."
+}

changedInput schema / properties / url / description

Previous value: -"http(s) URL of an HTML page or PDF"New value: +"http(s) URL of a web page, RSS/Atom feed or PDF (https:// assumed if omitted)"

removedInput schema / properties / url / format
```
Removed value: -"uri"
```

Addedsearch

1 tool updateOct 16, 2026

Changedread_url1 field changed

addedInput schema / properties / mode

Added value: +{
+  "description": "auto (default): article text, or a headline+link list for news homepages/index pages; article: main article only; links: headline+link list; full: whole page as Markdown. RSS/Atom feeds always return their items.",
+  "enum": [
+    "auto",
+    "article",
+    "links",
+    "full"
+  ],
+  "type": "string"
+}

1 tool updateOct 15, 2026

Changedread_url1 field changed

changedInput schema / properties / render / description

Previous value: -"headless browser rendering: auto (default), never, always"New value: +"JavaScript rendering with headless Chromium: auto (default), never, always"

2 tool updatesOct 15, 2026
- First observedget_balance
- First observedread_url

Related MCP Connectors

Forum for Agents A
com.forumforagents
Free web reader for agents: any URL to clean Markdown. Plus a public message board for agents.
Communication Agent Orchestration
171
https://forumforagents.com/mcp
Vibes-Coded Agent Tools A
io.github.doteyeso-ops
Web search, page-to-markdown, memory, leases and proof for agents. x402, no signup.
Search Payments & Billing
331
https://vibes-coded-mcp-production.up.railway.app/mcp
Agent Read Proxy A
dev.workers.agent-read-proxy.agent-read-proxy
Read any web page (even JS sites), PDFs, tables, RSS & screenshots for AI agents. Pay via x402.
Browser Automation Web Scraping Payments & Billing
91
https://agent-read-proxy.agent-read-proxy.workers.dev/mcp
WebRead A
io.github.agentgate-builder
Read any public web page as clean Markdown for LLMs. Respects robots.txt. Free tier; x402 paid API.
Browser Automation Web Scraping
11
https://webread.agentgate.workers.dev/mcp

Related MCP Servers

skim-mcp
Browser Automation Web Scraping
JessieJanie
A
license
A
quality
C
maintenance
Pay-per-use clean web reader for AI agents. URL in, markdown plus metadata out, in milliseconds. Settled per-call in USDC over x402 — no signup, no API keys.
Updated 5 days ago (2026-11-01 15:02 UTC)
1
115 npm
3
MIT
Toll402
Agent Orchestration Autonomous Agents Browser Automation
toll402
A
license
Not graded
quality
B
maintenance
Pay-per-call tools for AI agents via x402 (USDC on Base): web-to-Markdown, PDF, provenance (human vs synthetic), trusted lookup with citations, a 3.9M-business global directory, LatAm ID validators, agent-forged tools and 2,000+ proxied x402 services. No API keys, charged only on success, free trial without a wallet. Remote: https://toll402.dev/mcp · Local: npx -y toll402-mcp
Updated a month ago (2026-09-29 18:03 UTC)
MIT
cleanfetch
Browser Automation Web Scraping
belzorash
A
license
A
quality
C
maintenance
Enables AI agents to read web pages reliably, returning clean markdown content, hyperlinks, and metadata without navigation or ad noise.
Updated 4 months ago (2026-06-21 21:36 UTC)
3
10 npm
MIT
web-scraper
Web Scraping RAG Systems
Br0ski777
A
license
Not graded
quality
D
maintenance
Enables extracting clean, structured markdown from any URL—stripping nav, ads, and scripts—for RAG pipelines and AI research agents, with pay-per-call micropayments via x402.
Updated 2 months ago (2026-09-02 19:58 UTC)
MIT

Try in Browser

Let your AI agent see the webWeb-to-screenshot MCP for Claude, Cursor and Codex. No cookie banners. Free to start.snap-render.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?