Give your AI agent a tool to read PDFs (with MCP)

Agents can write PDFs. Reading them is the hard part.

Generating a PDF from an agent is a solved problem: call a tool, get a file. Reading one is where things quietly break. The document is often a URL the agent can't safely fetch, or an upload trapped in a chat with no clean path into a workflow. Scanned PDFs have no text layer, so naive extraction returns empty strings or garbled characters. And dumping every page as an image into the model burns the context window and the bill — before you even hit a document that exceeds the model's own page limit.

The fix is a dedicated tool that does the things the agent can't or shouldn't do in-context: fetch untrusted URLs safely, extract deterministically at near-zero cost, detect scans, and return compact markdown instead of raw page images.

What a good read_pdf tool returns

The goal is output an agent can trust and act on, not a wall of text. A useful reader returns the extracted content as markdown (or plain text), the page count, and — crucially — a flag telling the agent whether the PDF actually had a text layer:

{
  "content": "# Invoice INV-042\n\nBilled to: Acme Corp\n\nTotal: $1,280.00",
  "pageCount": 1,
  "hasTextLayer": true,
  "needsOcr": false
}

That needsOcr flag is the single most important behavior. Roughly 70–80% of real-world PDFs are born-digital and have a real text layer, so native extraction reads them at essentially zero cost. The rest are scans. Returning needsOcr: true instead of an empty string is what makes the tool trustworthy — the agent knows to escalate to OCR rather than confidently reasoning over nothing.

Reading a PDF over MCP

With an MCP server, your agent gets a read_pdf tool it can call directly — a URL or base64 bytes in, markdown out — no HTTP plumbing in the agent's context. Docweave's MCP server exposes read_pdf next to generate_pdf, so an agent can both read a document and write one:

curl https://docweave.dev/api/v1/read \
  -H "Authorization: Bearer dw_live_your_key" \
  -H "Content-Type: application/json" \
  -d '{
    "source": { "type": "url", "url": "https://example.com/invoice.pdf" },
    "options": { "format": "markdown" }
  }'

The security gotcha nobody mentions

Letting an agent hand you an arbitrary URL to fetch is a textbook SSRF vector — a crafted URL can point at cloud metadata endpoints or internal services. A reader that fetches URLs must validate the target, re-check it on every redirect hop (a 302 to a private IP must not slip through), and verify the bytes are actually a PDF before parsing. base64 input avoids the fetch entirely and is safe by construction. If you're building this yourself, don't skip it; if you're using a hosted tool, make sure it does this for you.

Why this matters now

Agent demand for reading documents dwarfs demand for generating them — the most popular document MCP servers are readers, not writers, by a wide margin. As agentic workflows shift from static retrieval to reading documents live as tools, a reliable read_pdf tool becomes part of the standard agent toolkit. Pairing it with a generator gives an agent a full document I/O layer: one tool to read a document, one to write one.

If you'd rather not build the fetch-guard, extraction, and scan-detection yourself, Docweave gives you read_pdf and generate_pdf from one API, priced per document.