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., "@Business PDF Field Extractor MCP Server Extract the invoice number, date, and total from https://example.com/invoice.pdf"
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.
An MCP server for the Mamba Labs Business PDF Field Extractor actor on Apify. Read invoices, purchase orders, and contracts from PDFs as fixed fields.
Related MCP server: doc-extract
Give PDF addresses. The actor reads each file's text, or runs OCR on scanned pages, works out whether it is an invoice, a purchase order, or a contract, and returns fixed fields. Invoices and purchase orders return numbers, dates, parties, totals, line items, and a check that the amounts add up. Contracts return parties, dates, term, renewal, notice days, governing law, and which standard clauses appear. It uses labels and column position with no AI, so a value with no known label stays null and is listed as missing.
All of the work runs on Apify. This package is a thin client that starts the actor run, waits for it, and hands back the dataset rows.
You need Node.js 18 or newer and an Apify account with an API token.
Add this to your Claude Desktop config (claude_desktop_config.json), Cursor, or any MCP client:
{
"mcpServers": {
"mamba-business-pdf-field-extractor": {
"command": "npx",
"args": [
"-y",
"@mambalabsdev/mcp-business-pdf-field-extractor"
],
"env": {
"APIFY_TOKEN": "your-apify-token"
}
}
}
}Restart the client. The extract_business_pdf_fields tool appears.
Node.js 18 or newer.
An Apify API token from console.apify.com/account/integrations, set as APIFY_TOKEN. The server lists its tool without a token; a call needs one.
"Extract the fields from this invoice PDF: "
"Read these purchase orders and list the line items: "
"What is the renewal and notice wording in this contract PDF: "
extract_business_pdf_fields. One tool. Example arguments:
{
"pdf_urls": [
"https://docs.oasis-open.org/ubl/cd-UBL-1.0/fs/Order/pdf/OfficeOrder.Example-us.pdf",
"https://raw.githubusercontent.com/Azure/azure-sdk-for-python/main/sdk/formrecognizer/azure-ai-formrecognizer/samples/sample_forms/forms/Invoice_1.pdf",
"https://gba.georgia.gov/document/publication/services-contractsample-agreement-templatepdf/download"
]
}Every buyer facing input of the actor. Omitted inputs take the actor's own defaults.
Input | Type | Required | Description |
| array | 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. |
| string | no | Optional. One PDF file from your computer, stored in your Apify account. |
| string | no | auto (default) works it out per file. Set invoice, purchase_order, or contract to read every file as that type. |
| string | 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. |
| boolean | 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. |
| string | no | Language of scanned pages: eng (default), deu, fra, spa, nld, ita, or por. |
| number | no | Pages to read per file, up to 500. Default 50. |
| number | no | Scanned pages to read per file, up to 100. Default 10. This caps the OCR charge per file. |
| number | no | Files to read in this run, up to 1,000. Default 100. |
| boolean | 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. |
| boolean | no | yes: add the document text to the row, up to 200,000 characters. Default no. |
| string | no | Optional. The run stops before a charge that would pass this amount. Summary rows are always returned. |
Pay per event on Apify, billed to your Apify account. Prices in USD.
Event | Free plan | Bronze | Silver | Gold |
| $0.01 | $0.0095 | $0.009 | $0.0085 |
| $0.015 | $0.01425 | $0.0135 | $0.01275 |
| $0.004 | $0.004 | $0.004 | $0.004 |
Line item rows, documents with no fields read, failed downloads, and refused input are free. Mamba Labs pays the platform costs of the run, Apify proxy traffic included.
apify.com/mambalabs/business-pdf-field-extractor
MIT. See LICENSE.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0extract_business_pdf_fieldsScored across 1 tool
There is only one tool, so there is no possibility of tool selection confusion. Its purpose (extracting fixed fields from business PDFs) is stated clearly and covers both invoice/PO and contract extraction paths.
The single name extract_business_pdf_fields follows a clear verb_noun snake_case convention that matches the domain. There are no competing conventions to introduce inconsistency.
A single tool is thin relative to the stated scope, which spans invoices, purchase orders, and contracts with two distinct output schemas. It is defensible as a wrapper around one extraction actor, but a second tool (e.g. contract vs. invoice extraction, or batch input) would sharpen the surface.
The tool covers the full read-only extraction lifecycle, including OCR, line items, totals validation, and contract clauses, which is complete for a pay-per-document extractor. Minor gaps exist: no batch/multi-document input, no schema or field-selection option, and null results for unlabeled values leave no verification path beyond the totals check.
Turn any PDF into structured JSON via AI + OCR: invoices, bank statements, contracts.
Extract PDFs into structured tables, query records, and configure document inbox workflows.
Extract invoices, receipts and contracts into structured JSON. EU-hosted, per-field confidence.
Turn documents into verified, structured data: fields, tables, and automatic checks.
