Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@io.github.tidybytetools/pdf-table-pull-lite extract the tables from ~/Downloads/invoice.pdf and save each as a CSV"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Free tool that pulls the tables out of a text PDF and saves each one as a CSV file. Need Excel output, scanned PDFs or tables joined across pages? The paid version does that: pdf-table-pull on Gumroad
Runs on your own computer, so your PDFs are never uploaded anywhere. MIT license. Python 3.10 or newer, on Windows, Mac and Linux.
pip install pdf-table-pull-liteOr use pipx, which keeps it in its own space:
pipx install pdf-table-pull-liteWant the newest code from GitHub instead?
pip install git+https://github.com/tidybytetools/pdf-table-pull-liteRelated MCP server: MokuPDF
pdf-table-pull-lite statement.pdf # CSVs go in statement_tables/
pdf-table-pull-lite statement.pdf -o out/ -p 2-5 # only pages 2 to 5
pdf-table-pull-lite statement.pdf -s text # tables with no border linesExample run:
Found 2 table(s).
page1_table1: 2 rows x 3 columns
page1_table2: 2 rows x 2 columns
Saved: statement_tables/page1_table1.csv
Saved: statement_tables/page1_table2.csvYou get one CSV per table, named after its page. The CSVs open straight in Excel (they're saved as UTF-8 with a BOM so accents show correctly).
--strategy (-s): lines is for tables with ruled borders, text is for tables lined up by spacing, and auto (the default) tries lines first, then text.
When you run it in a terminal it ends with one short line about the paid version. --quiet turns it off, and it never shows when output is piped or redirected.
Scanned PDFs. Pages that are just an image (no text layer) are skipped, and the tool tells you which ones.
Tables that continue onto the next page come out as separate CSVs, one per page.
Odd layouts. Tables with merged cells or no clear columns can come out with cells in the wrong spot. Check the CSV.
CSV only. No Excel or JSON output, no number cleanup (so (40) stays as text), and no password-protected PDFs.
lite (free) | ||
Text PDFs, ruled or spaced tables | yes | yes |
CSV output | yes | yes |
Excel (one sheet per table) and JSON output | no | yes |
Scanned PDFs (OCR) | no | yes |
Join tables across pages | no | yes |
Numbers cleaned ( | no | yes |
Password-protected PDFs | no | yes |
All of these are free and open source. Pick what fits you.
pdf-table-pull-lite | ||||
What it is | Command line tool | Python library | Python library + CLI | Python wrapper for Tabula |
Needs Java | no | no | no | yes |
One command to get CSVs | yes | no, you write code | yes | yes |
Picks border or spacing mode for you | yes ( | no | no | yes (guess) |
Tells you which pages are scans | yes | no | no | no |
Built-in MCP server for AI apps | yes | no | no | no |
Lots of tuning knobs | no | yes | yes | some |
This tool is built on pdfplumber. If you want full control in your own code, use pdfplumber or Camelot directly.
There is a small free MCP server built in. It gives your AI app one tool, extract_pdf_tables. It needs uv.
Run it by hand to check it starts (it waits quietly for an app to talk to it):
uvx --from pdf-table-pull-lite pdf-table-pull-lite-mcpClaude Desktop (claude_desktop_config.json) or Cursor (~/.cursor/mcp.json):
{
"mcpServers": {
"pdf-table-pull-lite": {
"command": "uvx",
"args": ["--from", "pdf-table-pull-lite", "pdf-table-pull-lite-mcp"]
}
}
}Tool: extract_pdf_tables(path, pages="", strategy="auto", output_dir=""). It returns a list with the CSV text of each table. If you set output_dir, it saves the CSVs there and returns the file paths instead.
Use when: you have a local PDF with real text (you can select the words) and need its tables as rows.
Don't use when: the PDF is a scan or photo, it has a password, or you need Excel. Those pages get skipped. Use the paid version for those.
Input: a file path, plus optional pages like 1,3-5 and strategy (auto, lines, text).
Output: a list of CSV strings, one per table, first row is the header. Empty list means no tables were found.
CLI exit code is 0 on success and 1 on error (message on stderr). See also llms.txt.
pip install pdfplumber "mcp<2"
python3 -m unittest discover testsMIT. See LICENSE.
Pull the tables out of a local text PDF.
path: full path to a PDF on this computer. pages: optional, like "1,3-5". Empty means all pages. strategy: "auto" (default), "lines" (ruled borders) or "text" (lined up by spacing). output_dir: optional. If set, each table is saved there as a CSV and the file paths are returned. If empty, the CSV text of each table is returned.
Scanned (image-only) pages have no text and are skipped. Returns [] if no tables.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| pages | No | ||
| strategy | No | auto | |
| output_dir | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations supplied, the description carries the full burden and does well: it discloses that output_dir causes side effects (each table written as a CSV file, paths returned) versus in-memory CSV text otherwise, and that scanned pages are silently skipped with [] returned when nothing is found. It stops short of stating what happens to pre-existing files in output_dir or whether files are overwritten.
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?
A single front-loaded purpose sentence followed by a compact name-to-meaning list; every line carries information (formats, defaults, consequences) with no filler. The structure maps directly onto the parameters an agent must fill.
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?
For a four-parameter extraction tool with an output schema already covering return values and no annotations to lean on, the description supplies the remaining essentials: path format, page-selection syntax, strategy tradeoffs, the on-disk side effect of output_dir, and the empty-result case. An agent could invoke it correctly without opening the schema.
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 0%, so the description must compensate fully and it does: every one of the four parameters is explained with format examples ('1,3-5' for pages), defaults, and the enumerated strategy values with their meanings. This adds substantial meaning beyond the bare typed properties in the schema.
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?
States a concrete verb and resource — 'Pull the tables out of a local text PDF' — and even scopes it to text PDFs, noting that image-only pages are skipped. There are no sibling tools, so no differentiation is required, and an agent can tell immediately what this tool produces.
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?
Guidance is embedded per option: pages defaults to all when empty, and strategy lists 'lines' (ruled borders) vs 'text' (lined up by spacing), which implies when each applies. What's missing is an explicit statement of when to prefer 'auto' over forcing a strategy, or when to prefer returning CSV text versus writing files.
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.
v1.1.0extract_pdf_tablesScored across 1 tool
There is only a single tool, so there is no possibility of selecting the wrong one. Its purpose—extracting tables from a local text PDF—is stated clearly and unambiguously.
The lone tool follows a clear snake_case verb_noun pattern (extract_pdf_tables). With one tool there is no convention mixing, and the name is self-describing.
A single tool is defensible for a deliberately 'lite', single-purpose extractor, but the surface is thin: there is no companion operation to inspect a PDF before extracting. It sits at the borderline of minimal rather than well-scoped.
The core extraction workflow is covered, including page ranges, strategy choice, and CSV output, but there are notable gaps: no way to discover page count or check whether a PDF is text-based, and scanned/image pages are simply skipped with no fallback. Agents working with real-world PDFs will hit these dead ends.
Extract every table from PDFs and scans to Excel, CSV and JSON.
Pull tables out of a PDF as rows and cells, ready for a spreadsheet or a data pipeline.
Extract tables, text and formulas from PDFs, including scanned pages and broken text layers.
Extract text, tables and metadata from every PDF linked in a dataset, CSV or Google Sheet.