The server is a local, offline MCP read/extraction layer for documents (PDF first, but also HTML, DOCX, XLSX, PPTX, EML, EPUB, XBRL, markdown, plain text), designed to make large documents addressable without flooding context.
Probe: identify format, pages, scanned/digital status, and contents.
Outline: list headings/bookmarks with page anchors before extracting.
Find: locate text or regex matches, returning page locations/counts rather than content.
Extract: pull clean text for a requested page range, refusing when too large.
Extract tables: get table rows with confidence reflecting whether ruling lines or column gaps were used.
Read page: see one page's text, tables, links, and provenance.
To markdown: convert documents to Markdown within the token budget.
Supports passwords, page ranges, zip bundles (e.g. filing.zip::instance.xbrl), and optional URL fetching.
The broader project also includes edit tools (assemble, convert, optimize, ocr, protect, redact), though the provided schema covers the read tier.
Supports Markdown documents as a first-class format, allowing the server's reading, extraction, and manipulation tools to operate on Markdown files, and enabling conversion between Markdown and other document formats.
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., "@MCP_Documents Probe ~/Downloads/invoice.pdf and tell me if it's scanned."
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.
A self-hosted MCP server for reading, extracting from and manipulating documents — PDF first, but not PDF only.
The seventh repo in the MCP_* fleet, and the one that closes the research
leg of the research → analytics → reporting path the fleet exists to serve.
Release
v0.2.0— the second tagged release. All 13 tools are implemented and deployed; CI is green on Ubuntu, macOS and Windows. Source only: no wheel and no container image are published, so build the image yourself from theDockerfilehere. The documents indocs/remain the contract the implementation satisfies, andCLAUDE.mdis the rulebook for anyone changing it.
The commercial PDF sites are upload-first. The documents people actually run through them are contracts, invoices, payslips, medical and legal records.
This does the same work and nothing leaves the machine. No GPU, no cloud API, no model weights, no subscription — and it works offline.
Related MCP server: Knowledge Assistant MCP
Extraction from documents too large to read. A 500-page PDF is roughly 250,000 tokens; the agent driving it has about 10,000. So the server does not return documents, it makes them addressable:
probe what is this — pages, scanned or digital, where the structure is
find WHERE something is — locations and counts, never the content
extract one region you chose, cleaned, with a note on how it was obtainedThat path is what lets an agent answer a question about a 500-page bundle inside
a small context. With a regex and named groups, find over 300 pages returns
rows rather than prose — which is what the sibling data server loads.
Manipulation, the operations a PDF site offers, done locally: assemble (merge / split / reorder / rotate in one grammar), convert, compress, repair, OCR, protect, redact.
Any document, not just PDF. One reader per format normalising into a single
internal model, so every tool works the same on PDF, HTML, .docx, .xlsx,
.pptx, .eml, .epub, .xbrl, markdown and plain text. With URL fetching
enabled, every path argument also accepts a link — the same call, whether the
HTML came from disk or the web.
Bundles open too. A .zip reads as its manifest, and a member is read by
naming it — probe("filing.zip::instance.xbrl") — so a filing that arrives as
an archive does not have to be unpacked by hand first.
XBRL figures come back native. Every other format's numbers are recovered
from layout and carry a confidence to match; an XBRL instance states its facts
in machine-readable fields, and the response says so. Values are reported
exactly as filed and never rescaled.
docs-read probe · outline · find · extract · extract_tables · read_page · to_markdown
docs-edit assemble · convert · optimize · ocr · protect · redactThirteen, not the twenty-five a PDF website shows, because that number is a
property of user interfaces — a button cannot take an argument and an agent's
verb can. assemble alone covers merge, split, extract pages, remove pages,
organise and rotate.
File | What is in it |
| The rules. Read this first if you are an agent working here. |
| The three-step path, the intermediate representation, provenance, budgets |
| Every tool's signature, response shape and refusals |
| Libraries, licences, external binaries, the container budget |
| What was rejected and why — read before proposing a change |
Reconstruction announces itself. A PDF is glyphs at coordinates — paragraphs,
tables, reading order and headings are all inferred. Every extraction carries a
basis field saying how it was obtained: a table found from ruling lines and one
guessed from column gaps do not get the same confidence, and a page that is an
un-OCR'd scan says so instead of returning nothing.
PDF → Word/PowerPoint is reconstruction, not conversion. The commercial sites use commercial engines and there is no CPU-only open-source path to that quality. This ships it, labels it, and tells you when a document is a poor candidate.
Requires Python 3.14 and uv. Set MCP_CONSTRAINED_MODE=1 on small
hardware to tighten every budget.
uv sync
uv run python servers/docs_read/server.py # 7 read tools
uv run python servers/docs_edit/server.py # 6 edit toolsTwo entries in your client's mcp.json, one per tier. Everything runs on the
CPU with no network; convert(to='pdf') needs LibreOffice and ocr() needs
Tesseract, and both say so by name when they are missing rather than failing
inside a subprocess.
One container, both tiers on one port, so the PDF stack loads once:
cp tokens.example.json tokens.json # or use DOCS_API_KEY
mkdir -p oauth-state shared-files && sudo chown -R 999:999 oauth-state shared-files tokens.json
docker compose up -d --build
curl http://localhost:8850/health # aggregate
curl http://localhost:8850/read/health # per tierThe image carries LibreOffice and Tesseract. It does not carry Ghostscript
— that is a licence decision, not an omission, and optimize() reports the
capability it therefore lacks (see docs/DECISIONS.md §11). Build with
--build-arg INSTALL_GHOSTSCRIPT=1 if you accept AGPL for your own deployment.
Mounts are /read/mcp and /edit/mcp. Auth is bearer-token, by precedence:
DOCS_TOKENS_FILE > DOCS_TOKENS > DOCS_API_KEY > open. Open mode is for
localhost only — a reachable deployment with no token set has no auth at all.
Set DOCS_PUBLIC_URL to the public origin, or OAuth discovery falls back to the
internal bind address and no remote client can complete it.
To give a caller a link rather than a path inside the container, point
MCP_SHARED_DIR at a directory your file server serves and set
MCP_PUBLIC_BASE_URL to its URL; every produced file then comes back with a
public_url. MCP_FETCH_URLS=1 additionally lets any source argument be an
http(s) link — off by default, and private, loopback and cloud-metadata
addresses are refused even when it is on.
uv run python -m pytest tests/ -q # 408 offline tests
DOMAIN=http://localhost:8850 ./remote_smoke_test.sh # all 13 tools over HTTPThe smoke test is the only thing that exercises LibreOffice and Tesseract, and
it is worth more than its size suggests: it found six defects the whole offline
suite did not, because it is the only check that hands these tools a document
real software produced. DOMAIN has no default on purpose — no hostname
appears anywhere in this repo.
Extract clean text for a page range. Bounded; refuses when too big.
| Name | Required | Description | Default |
|---|---|---|---|
| pages | No | ||
| source | Yes | ||
| password | No | ||
| clean_text | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds genuinely useful behavioral context beyond annotations: the operation is 'Bounded' and 'refuses when too big,' which is important operational knowledge for an agent.
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?
The description is two short sentences with no filler. It front-loads the core purpose and then adds a critical behavioral warning, so every sentence earns its place.
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 four parameters, 0% schema coverage, and no output schema, this description is too thin. It does not explain what 'clean text' excludes, how to specify the page range, what source refers to, what happens on refusal, or what the return value looks like. The bounded/refusal note is helpful but not sufficient.
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. It maps loosely to two parameters: 'page range' hints at pages and 'clean text' hints at clean_text. However, it does not explain source, password, or page-range formatting, leaving significant parameter semantics unexplained.
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 uses a specific verb and resource: 'Extract clean text for a page range.' It clearly indicates the output type ('clean text') and scope ('page range'), which helps differentiate it from siblings like extract_tables and to_markdown, though it does not explicitly name or contrast any alternative.
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?
The phrase 'for a page range' implies the intended use case, and 'Bounded; refuses when too big' warns about size limits. However, there is no explicit guidance about when to prefer this tool over siblings such as read_page, extract_tables, or to_markdown, so the usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract tables as rows. Says whether ruling lines or gaps were used.
| Name | Required | Description | Default |
|---|---|---|---|
| pages | No | ||
| source | Yes | ||
| password | No | ||
| min_confidence | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety characteristics with readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds a useful behavioral detail: the tool also reports whether ruling lines or gaps were used. However, it does not discuss limitations, handling of malformed tables, or what happens when no tables are found.
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?
The description is concise and front-loaded with the primary action: 'Extract tables as rows.' The second sentence adds a worthwhile detail without padding. It is appropriately sized, though the unusual phrasing 'Says whether ruling lines or gaps were used' could be slightly clearer.
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?
Given four parameters, no output schema, and sibling tools that could easily overlap, the description is too sparse. It omits parameter semantics, input expectations, and any output structure beyond 'rows,' leaving important gaps for an agent deciding whether and how to call it.
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?
The input schema has 0% description coverage, and the description provides no information about the four parameters: source, pages, password, and min_confidence. Required source and optional parameters are left completely unexplained, so the agent cannot infer their meaning or valid formats from the description.
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 names a specific operation: extracting tables as rows, and adds a distinct behavioral detail about reporting ruling lines or gaps. It is clear about the resource and output, though it does not explicitly contrast itself with sibling tools like 'extract' or 'to_markdown'.
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?
No guidance is provided about when to use this tool versus alternatives such as 'extract', 'probe', 'outline', or 'to_markdown'. There are no explicit usage conditions, exclusions, or alternative recommendations, leaving the agent to infer selection context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Locate text: page numbers, counts, and a snippet each. Never a page.
| Name | Required | Description | Default |
|---|---|---|---|
| pages | No | ||
| query | Yes | ||
| regex | No | ||
| source | Yes | ||
| max_hits | No | ||
| password | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds useful behavioral detail beyond the annotations by stating the output components (page numbers, counts, snippets) and the hard boundary that it never returns a page.
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?
The description is extremely compact: two short sentences with no filler. The core behavior is front-loaded, and the key exclusion is delivered clearly at the end.
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 tool with six parameters and no output schema, the description conveys the essential result shape and boundary but leaves parameter semantics and edge-case behavior unexplained. It is minimally adequate for basic calls but incomplete for confident use of advanced options like regex or password-protected sources.
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 carries the full burden for explaining parameters, but it does not explain source, pages, regex, max_hits, or password. Only 'query' is implicitly understandable from 'Locate text', leaving most parameters underspecified.
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 uses a specific verb ('Locate text') and names the resource and output shape: page numbers, counts, and a snippet each. The final 'Never a page' clearly distinguishes this tool from sibling tools like read_page, making its purpose unmistakable.
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?
The description implies clear usage: use this when you need to find text locations rather than retrieve full page content. The 'Never a page' statement provides an explicit exclusion, though it does not name sibling alternatives like extract or outline by name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List headings and bookmarks with page anchors. Use before extract.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | ||
| password | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds some context beyond annotations—that output includes page anchors and that the tool is a precursor to extraction—but offers no detail on return format, limits, or error behavior.
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?
Twelve words in two sentences, with zero waste. The core purpose is front-loaded in the first sentence and the usage hint in the second. Every word earns its place.
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 simple read-only, idempotent listing tool with only one required parameter, the description covers the essential ground: what it returns (headings, bookmarks, page anchors) and when to run it (before extract). Since no output schema exists, the return description partially compensates. The main gap is the un-documentd 'source'/'password' semantics, which is likely shared across the sibling family but still left to inference.
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 carries the burden of explaining parameters, but it never explains what 'source' refers to or what 'password' unlocks. The only implicit hint is that source is a document containing headings and page anchors. The description does not compensate for the coverage gap.
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 specific verb ('List') and resource ('headings and bookmarks with page anchors'), clearly distinguishing it from reading content (read_page), extracting tables (extract_tables), or converting format (to_markdown). The purpose is immediately unambiguous.
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?
'Use before extract' provides clear workflow context by positioning this tool as the precursor to extraction. It does not name alternatives or state when-not-to-use, but the placement guidance is explicit enough for an agent to sequence correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Identify a document: format, pages, scanned or digital, what it holds.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | ||
| password | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior, so the safety profile is covered. The description adds what information the probe yields (format, pages, scanned/digital, content), but does not disclose details like whether it opens remote URLs, handles encrypted files, or what failure modes exist. No contradiction with annotations.
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?
The description is a single focused sentence with the core verb front-loaded and the informative scope listed after a colon. There is no fluff, repetition, or redundant restatement of the tool name.
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 tool with no output schema and undocumented parameters, the description is too sparse. It tells what the tool identifies but not how the result is structured, how to specify the source, or whether password is required for certain document types. An agent could call it correctly but would not know what to expect back or how to interpret the response.
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 for explaining 'source' and 'password'. It does not mention either parameter at all, leaving the agent to guess what 'source' refers to (path, URL, object ID?) and when password is needed. The parameter names are mildly self-evident but the description adds no semantic value.
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 uses a specific verb ('Identify') and resource ('a document'), and enumerates concrete aspects: format, pages, scanned/digital status, and content. It clearly conveys the tool's role as an inspection/reconnaissance tool, distinct from siblings like extract or to_markdown, though it does not explicitly name or contrast them.
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?
The description implies this tool is used to get an overview of a document before deeper operations like extraction or reading. However, it does not explicitly state when to prefer probe over siblings such as read_page, outline, or extract, and offers no exclusions or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one page: text, tables, and how each was obtained.
| Name | Required | Description | Default |
|---|---|---|---|
| page | Yes | ||
| source | Yes | ||
| password | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds that the output includes text, tables, and 'how each was obtained,' which is useful context, but it does not disclose password handling, error cases, or extraction limitations.
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?
The description is very concise and front-loads the main action. It wastes no words, though it could provide a bit more clarifying detail about parameters while remaining reasonably short.
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 and no parameter descriptions, this sparse description is not sufficient for reliable first-time invocation. An agent still needs to infer what source refers to, what password does, and how the provenance information is represented.
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 needed to clarify source, page, and password. It only hints at the page number via 'one page' and does not explain source or password at all, leaving required parameters under-specified.
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 states a specific action and resource: 'Read one page' and lists what is included (text, tables, and provenance). It is clear, though it does not explicitly differentiate this tool from siblings like extract or to_markdown.
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?
There is no guidance about when to choose read_page over sibling tools such as extract, outline, probe, or to_markdown. The phrase 'one page' weakly implies a use case, but no explicit context, prerequisites, or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a document to markdown. Refuses when over the token budget.
| Name | Required | Description | Default |
|---|---|---|---|
| pages | No | ||
| source | Yes | ||
| password | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already cover the safety profile with readOnlyHint=true and destructiveHint=false. The description adds a meaningful behavioral detail by stating it 'refuses when over the token budget,' which is useful operational context beyond the annotations.
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?
The description is two short sentences with the core purpose front-loaded and no filler. Both sentences contribute useful information: what the tool does and a key constraint on its execution.
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?
Given the absence of parameter documentation and no output schema, the description leaves important gaps: how pages and password affect conversion, what the markdown output contains, and how token-limit refusal is surfaced. The annotations cover safety but not these operational details.
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%, and the description does not explain the meaning or usage of source, pages, or password. The description's only reference to the input is the generic word 'document,' which does not compensate for the undocumented parameters.
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 states a clear action and result: 'Convert a document to markdown.' This is specific enough to identify the tool's function, though it does not explicitly distinguish it from sibling tools like extract or read_page.
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?
The description gives no guidance on when to use this tool versus alternatives such as extract, extract_tables, or read_page. There are no use-case conditions, exclusions, or examples of when to prefer a sibling tool.
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.
v0.0.1extractextract_tablesfindoutlineproberead_pageto_markdownScored across 7 tools
The tools are mostly distinct: find locates snippets, read_page returns one page, extract handles a page range, extract_tables targets tables, outline exposes structure, probe identifies the document, and to_markdown does full conversion. The only mild ambiguity is between extract and to_markdown, since both return document text and could be selected for similar high-level tasks.
Naming conventions are inconsistent: several bare verbs (find, extract, outline, probe), two verb_noun compounds (read_page, extract_tables), and one prepositional name (to_markdown). There is no shared prefix or pattern, though each name is readable on its own.
Seven tools is appropriate for a document-reading server: each one addresses a distinct need such as search, page reading, range extraction, tables, outline, probe, and conversion. The count feels neither thin nor bloated.
The set covers the main document workflow: identify, outline, search, read single pages, extract text and tables, and convert to Markdown. Minor gaps remain: scanned documents have no explicit OCR path, and to_markdown's token-budget refusal may require manual page-range reconstruction for very large documents.
Turn documents into structured data: parse, extract, classify, split, and fill PDF forms.
Composable APIs for document extraction, image transformation, and document & sheet generation.
High-fidelity PDF to structured Markdown conversion and document field extraction.
Convert and compress PDFs and images, redact personal data, and run text and data utilities.
