@readfetch/mcp-x402-proxy

readfetch_pdf

Read-only

Extracts text and metadata from PDF files supplied by URL or base64 bytes, returning per-page text and a combined Markdown body for downstream processing.

Instructions

Extract text from a PDF (%PDF- magic, not Content-Type): send exactly one of url (downloaded through egress) or content_base64 (inline bytes, ≤ 20 MB). Returns per-page text in pages, one concatenated markdown body, plus title and metadata; $0.005 per document, not per page. max_pages limits how many pages are extracted (default 50, max 200); a document above the cap or above 200 pages returns 413 and is not billed. Image-only/scanned PDFs may return empty text with billed: false and a hint. Use readfetch_text or readfetch_scrape for HTML pages; use readfetch_batch for many HTML URLs, not PDFs.

Input Schema

Name	Required	Description
`url`	No	Public PDF URL; fetched through egress (≤ 20 MB). Mutually exclusive with content_base64.
`filename`	No	Optional label when using content_base64 (default upload.pdf); ignored for url-only requests.
`max_pages`	No	Extract at most this many pages. Default 50; raise up to 200 when the document is longer. Over cap → 413, unbilled.
`content_base64`	No	Base64-encoded PDF bytes (≤ 20 MB). Mutually exclusive with url; pair with filename when the label matters.

Output Schema

Name	Required	Description	Default
`hint`	No
`pages`	No
`title`	No
`billed`	No
`source`	No
`status`	No
`markdown`	No
`metadata`	No
`page_count`	No
`content_sha256`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv0.1.13Nov 1, 2026

changedInput schema / properties / content_base64 / description

Previous value: -"Inline PDF, up to 20 MB."New value: +"Base64-encoded PDF bytes (≤ 20 MB). Mutually exclusive with url; pair with filename when the label matters."

addedInput schema / properties / filename / description

Added value: +"Optional label when using content_base64 (default upload.pdf); ignored for url-only requests."

addedInput schema / properties / max_pages / description

Added value: +"Extract at most this many pages. Default 50; raise up to 200 when the document is longer. Over cap → 413, unbilled."

changedInput schema / properties / url / description

Previous value: -"PDF URL, fetched through egress."New value: +"Public PDF URL; fetched through egress (≤ 20 MB). Mutually exclusive with content_base64."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "billed": {
+      "type": "boolean"
+    },
+    "content_sha256": {
+      "type": "string"
+    },
+    "hint": {
+      "type": "null"
+    },
+    "markdown": {
+      "type": "string"
+    },
+    "metadata": {
+      "properties": {
+        "author": {
+          "type": "string"
+        },
+        "created": {
+          "type": "string"
+        },
+        "producer": {
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "page_count": {
+      "type": "integer"
+    },
+    "pages": {
+      "items": {
+        "properties": {
+          "page": {
+            "type": "integer"
+          },
+          "text": {
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "source": {
+      "format": "uri",
+      "type": "string"
+    },
+    "status": {
+      "type": "string"
+    },
+    "title": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedv0.1.0Nov 1, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the read-only and open-world annotations, the description discloses pricing ($0.005 per document, not per page), failure billing behavior (413 above page cap is not billed), and scanned-PDF behavior (empty text can return with `billed: false` and a hint). This is unusually complete behavioral context for 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.

Conciseness5/5

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

The description is front-loaded with the core action and then layers constraints, return shape, pricing, edge cases, and sibling alternatives in a compact paragraph. Every sentence carries operational value and there is no filler.

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?

Given the annotations, complete schema, and existing output schema, the description supplies the remaining operational context an agent needs: input selection, size/page limits, billing exceptions, and when to choose a sibling tool instead. Nothing important for correct invocation appears to be 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 schema already documents mutual exclusivity, the 20 MB limit, and max_pages default/max/413 behavior. The description reinforces these constraints clearly but adds little parameter-level meaning beyond what the structured schema already provides.

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 states a specific verb and resource: extract text from a PDF, with a clear magic-byte check rather than Content-Type. It also distinguishes from siblings by naming readfetch_text/readfetch_scrape for HTML and readfetch_batch for many HTML URLs, not PDFs.

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?

It gives explicit usage rules: send exactly one of `url` or `content_base64`, use the former through egress and the latter for inline bytes up to 20 MB. It also states when not to use it, routing HTML work to readfetch_text, readfetch_scrape, or readfetch_batch.

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

Deploy Server