Zovo PDF to Spreadsheet

Convert PDF tables to Excel

convert_pdf_tables

Read-onlyIdempotent

Use this when the user wants to convert a PDF to Excel, convert PDF to Excel, extract a table from a PDF, convert PDF table to Excel, PDF to CSV, PDF to XLSX, get a bank statement PDF to Excel, or turn a PDF to spreadsheet. It reads the tables in a text-based PDF and returns an Excel workbook (one sheet per table) and a ZIP of CSV files, with column types and a preview of the first rows. Handles up to 15 MB and 50 pages. Does not read scanned or image-only pages (no OCR), does not edit the PDF, and keeps files for about 1 hour. Do not use for a PDF that is only a form to fill or for reading a PDF as plain text.

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": {
      "file": "<file>"
    },
    "name": "convert_pdf_tables"
  }
}

Input Schema

Name	Required	Description
`file`	Yes	The text-based PDF that holds the tables, e.g. statement.pdf or price-list.pdf.
`pages`	No	Pages to read, e.g. 1-3,5. Default: every page (first 50).
`column_types`	No	Force a column type when the detected one is wrong, e.g. [{"table":1,"column":3,"type":"text"}]. The widget's type switches send this.
`merge_tables`	No	true (default): join the last table on a page to the first on the next page only when their column count and whitespace-normalized source headers match; drop the repeated header.

Output Schema

Name	Required	Description	Default
`file`	Yes
`note`	Yes
`status`	No
`tables`	Yes
`warnings`	Yes
`downloads`	No
`truncated`	Yes
`page_count`	Yes
`pages_read`	Yes
`scanned_pages`	Yes
`table_details`	Yes
`other_text_rows`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 22, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description layers on operational facts the schema cannot convey: 15 MB and 50-page limits, no OCR so scanned/image-only pages fail, one sheet per table plus a CSV ZIP, column types and a row preview, and files retained ~1 hour. It also rules out mutation of the source PDF, which is exactly the kind of trait an agent needs before committing.

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?

Front-loaded well with triggers first, limits and exclusions after, but roughly half the opening sentence is redundant keyword repetition ('convert a PDF to Excel, convert PDF to Excel', 'PDF to CSV, PDF to XLSX, turn a PDF to spreadsheet'). The substantive sentences earn their place; the trigger list is bloated with near-duplicates.

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?

With an output schema present the description needn't enumerate return values, and it still sketches the deliverables, and it covers the operational envelope (size, page cap, no-OCR limitation, retention window) that determines whether the tool can be used at all. Nothing an agent needs to call this correctly 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%, so file, pages, column_types, and merge_tables are all documented inline at a level the description does not exceed. The description's only parameter-adjacent additions ('column types', 'preview of the first rows', page/size limits) are output-oriented rather than clarifying argument semantics, which matches the baseline 3 when the schema carries the load.

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+resource ('reads the tables in a text-based PDF and returns an Excel workbook') with concrete output artifacts, so an agent knows exactly what it produces. It never names or contrasts with the sibling list_pdf_tables, leaving the convert-vs-list routing to inference from the output description.

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?

Opens with an explicit trigger ('Use this when the user wants to convert a PDF to Excel...') covering several phrasings including bank statements, and closes with explicit exclusions ('Do not use for a PDF that is only a form to fill or for reading a PDF as plain text'). Both the when and the when-not are stated outright rather than implied.

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

All Zovo PDF to Spreadsheet tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?