Business PDF Field Extractor MCP Server

Extract fields from business PDFs

extract_business_pdf_fields

Read-onlyIdempotent

Extract structured invoice, purchase order, and contract fields from PDFs, including line items and OCR for scanned pages, with rule-based extraction that leaves unlabeled values null.

Instructions

Read invoices, purchase orders, and contracts from PDF addresses and return fixed fields: numbers, dates, parties, totals, line items, and a totals check, or contract parties, dates, term, renewal, notice days, governing law, and clauses found. Scans go through OCR. Rule based with no AI, so a value with no known label stays null. Pay per event on Apify: 0.01 USD per document, 0.015 USD per scanned page.

Input Schema

Name	Required	Description
`pdf_file`	No	Optional. One PDF file from your computer, stored in your Apify account.
`pdf_urls`	No	Web addresses of PDF files, up to 1,000. Each file up to 40 MB. The address must answer without a login. In Clay, put the column in a one item list.
`max_pages`	No	Pages to read per file, up to 500. Default 50.
`date_order`	No	How to read a date such as 03/04/2025 when both readings are valid. mdy (default) reads March 4, dmy reads 3 April. Unambiguous dates ignore this.
`read_scans`	No	yes (default): a page with no text layer goes through OCR, charged per page. no: those pages are skipped and the row says so.
`include_text`	No	yes: add the document text to the row, up to 200,000 characters. Default no.
`ocr_language`	No	Language of scanned pages: eng (default), deu, fra, spa, nld, ita, or por.
`document_type`	No	auto (default) works it out per file. Set invoice, purchase_order, or contract to read every file as that type.
`max_documents`	No	Files to read in this run, up to 1,000. Default 100.
`max_ocr_pages`	No	Scanned pages to read per file, up to 100. Default 10. This caps the OCR charge per file.
`line_item_rows`	No	yes (default): each line item is also its own free row, which suits CSV and Clay. no: line items stay in the line_items field only.
`max_charge_usd`	No	Optional. The run stops before a charge that would pass this amount. Summary rows are always returned.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 9, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, yet the description adds real value: OCR handling for scanned pages, deterministic rule-based extraction with null for unknown labels, and explicit per-document and per-scanned-page pricing. It does not cover run duration, async job behavior, or failure handling for unreachable URLs, which are meaningful for a batch Apify actor.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, front-loaded with the resource and return shape, followed by OCR, determinism, and price. Dense but every sentence carries information; minor terseness in 'Pay per event on Apify' but no filler.

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 12-parameter batch tool with no output schema, the description does the heavy lifting by naming the returned fields and the cost model. Gaps remain around result row structure (it mentions summary rows only implicitly), per-file error reporting, and whether the call is synchronous, which matter for a run that can process up to 1,000 documents.

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 the baseline is 3; every parameter is already documented, including date_order, max_ocr_pages, and document_type. The description adds only indirect color (the per-scanned-page price implicitly frames max_ocr_pages) and does not explain parameters beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (read) plus the exact resources (invoices, purchase orders, contracts) and enumerates the returned fields (numbers, dates, parties, totals, line items, totals check; contract parties, dates, term, renewal, notice days, governing law, clauses). An agent knows precisely what it gets without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies the right context (business documents in PDF form, scanned or text-layer) and sets a boundary by noting it is rule-based with no AI, so unlabeled values stay null; it also explains that scans route through OCR and can be skipped via read_scans. No sibling tools exist, so there is no alternative to route to, but when-not-to-use is only implied rather than stated.

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

Deploy Server

Other Tools

extract_business_pdf_fieldsA