Extract tables from a PDF. x402 $0.01 USDC, Base. As is, no warranty.
Scored across 1 tool
The server exposes exactly one tool, so there is no possibility of selecting the wrong tool. Its purpose (extract tables from a PDF) is stated unambiguously in the name and description.
With a single tool, consistency is trivially satisfied; the name 'extract-table-from-pdf' follows a clear verb-noun-target convention in kebab-case. There is no conflicting convention to contrast against.
One tool is on the thin side for a general MCP server, but it matches a tightly scoped, single-purpose utility (PDF table extraction). It is neither bloated nor an extreme mismatch, landing in borderline territory.
For its stated purpose the tool covers key inputs (base64 or URL), optional schema mapping, page limits, and structured JSON output with warnings. Minor gaps exist (e.g. no batch/multi-file extraction or output format options), but core workflows are fully supported.
Extract tables from a PDF ($0.01 USDC via x402). Pass pdf_base64 or a https pdf_url. Optional schema maps headers. Optional max_pages (1-10). Returns JSON { pages, tables: [{ page, headers, rows }], warnings }. Text PDFs are parsed in-worker; scans require HOSTED_PARSER_URL. Provided as is, with no warranty or guarantee of accuracy or fitness. Nothing is stored.
| Name | Required | Description | Default |
|---|---|---|---|
| schema | No | Optional header mapping. Object maps extracted header -> output name; array replaces headers in column order. | |
| pdf_url | No | https URL of a PDF. Provide this or pdf_base64. Max 8 MB. | |
| max_pages | No | Max pages to read. Capped at 10. | |
| pdf_base64 | No | Raw PDF encoded as base64 (optionally a data: URL). Provide this or pdf_url. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely non-derivable behavior: the x402 micropayment cost, that scans need an external parser service while text PDFs run in-worker, the 1-10 page cap, and the 'nothing is stored' data-handling statement. The no-warranty disclaimer further sets accuracy expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Information is front-loaded and dense — input modes, cost, return shape, and the text-vs-scan caveat all land early. The trailing 'Provided as is, with no warranty or guarantee of accuracy or fitness' is boilerplate that does not directly aid tool selection, but the overall length is reasonable for a 4-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema present, the description compensates by spelling out the return shape ({ pages, tables: [{page, headers, rows}], warnings }). Combined with the payment note, input modes, and scan-handling caveat, an agent has everything needed to call and interpret this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters, including the object-vs-array behavior of `schema` and the 8 MB URL limit. The description restates pdf_base64/pdf_url/max_pages and adds only the header-mapping purpose, so it does not meaningfully exceed the schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb+resource ('Extract tables from a PDF') and immediately scopes the operation with cost, input modes, and output shape. There are no sibling tools to disambiguate against, so nothing further is required for an agent to know exactly what this does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete invocation context: provide pdf_base64 or an https pdf_url, and it states the key precondition that scans require HOSTED_PARSER_URL while text PDFs parse in-worker. It also discloses the $0.01 USDC x402 charge up front. It stops short of explicit when-not-to-use guidance, but no alternative tool exists to route against.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
extract-table-from-pdfWord .docx to text and tables. x402 $0.005 USDC, Base. As is, no warranty.
https CSV to headers and rows. x402 $0.005 USDC, Base. As is, no warranty.
Extract tables, text and formulas from PDFs, including scanned pages and broken text layers.
Extract every table from PDFs and scans to Excel, CSV and JSON.
Add one secure layer between your agents and this server.