Skip to main content
Glama

pdf_tables

Extract the tables (CSV, JSON, Markdown) and per-page text from one PDF at a public URL. Digital PDFs ~97% cell accuracy; scanned pages (OCR) ~80%. Priced per page via x402 USDC on Base: $0.005/page with ocr=never, $0.015/page with ocr=auto. Charged only if every page succeeds. Max 20 pages per call. Retry with the PAYMENT-SIGNATURE header.

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": "pdf_tables"
  }
}

Input Schema

NameRequiredDescriptionDefault
ocrNonever (default, digital PDFs) or auto (OCR scanned pages, 3x price)
urlYeshttp(s) URL of a PDF
pagesNopage range, e.g. 1-3,7 (default: all, max 20)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.9/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 substantial work: it discloses per-page pricing tied to the OCR mode, that billing only occurs if every page succeeds, a 20-page cap, and the PAYMENT-SIGNATURE retry path for x402 payment. Remaining gaps are return-shape details (inline content vs. links) and non-payment failure modes, which keeps it short of a 5.

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?

Five dense sentences, front-loaded with the purpose before accuracy, price, limits, and the retry instruction. No filler; each sentence contributes a fact an agent needs to call the tool correctly.

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 paid, single-input extraction tool with no output schema, the description covers cost model, accuracy expectations, size limits, and payment retry, which is what an agent needs to decide and invoke. It stops short of describing the response structure (how tables are returned per format) and what happens on partial-page failure beyond 'not charged'.

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 baseline is 3, but the description adds real meaning beyond the schema by pairing the ocr enum with absolute per-page prices ($0.005 vs $0.015) where the schema only says '3x price'. The pages parameter is only echoed as 'max 20 pages per call' without adding syntax guidance beyond the schema example.

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 set: extract tables (CSV, JSON, Markdown) plus per-page text from a single PDF at a public URL. The scope (one PDF, public URL, tables + text) implicitly separates it from page_to_markdown, but no sibling is named, so the differentiation is inferred rather than explicit.

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?

Gives clear operating context (max 20 pages per call, ocr=never vs auto, price tiers, retry on payment failure), which tells an agent when the tool is applicable and what its limits are. However, it never states when NOT to use it or points to an alternative such as page_to_markdown for non-table extraction.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.