Is Pdfintact MCP server safe?
Probably. Read the findings first.
Use with care. Some checks failed or could not be verified.
Public scan report
scanner v0.1.9 · 2026-09-20 · same rubric, same numbers if you re-run it
2 low
- –Code scanremote-only server, no package to scann/a
- Live reliabilityremote reachable in 2004ms17/20
- Tool poisoning3 tool descriptions checked13/15
- Auth qualityopen endpoint, read-only tools10/15
- Maintenanceno repository listed3/15
- Maintainer identityverified namespace with website, no repo4/10
Findings (2)
- lowUnusually long tool description (over 2,000 characters)
poison.long-descriptiontool convert_pdf: …Convert a PDF into structured content (tables, charts, formulas, headings, body text) using a two-stage pipeline (layout detection, then a vision-language model) rather than a single VLM call on the raw PDF -- calling a VLM on a raw PDF directly is a known-unreliable pattern for numeric tables. Measured accuracy (500-page real-world benchmark of government/corporate reports, ~51,000 table values checked): tables 95.2% digit-exact, body text 88.8%. This tool reads PDFs a VLM cannot read directly, including scanned pages and PDFs with corrupted/garbled text layers (common in older Japanese academic PDFs). For scanned Japanese documents the numbers hold up (99.4% on the same benchmark). For scanned Arabic, body text does NOT: characters are dropped mid-sentence and quantities can turn into different quantities, so body blocks from scanned Arabic are always flagged confidence:"estimated" -- tables in the same documents stayed exact in our measurement. Strong on Japanese-language documents specifically; the accuracy figures above were measured on Japanese material and are not a claim about every language. Chart values are extracted but are best-effort estimates (about 52% exact match, excluding axis tick labels) and are always flagged confidence:"estimated" in the result -- do not treat estimated chart numbers as authoritative. This is a PAID, ASYNCHRONOUS, per-page-billed operation: credits are reserved from the caller's PDFIntact balance before processing starts, and the response's _meta.credits_remaining shows the balance right after reservation. Processing takes real wall-clock time (roughly 7 seconds/page; a 500-page PDF takes about 42 minutes including a multi-minute cold start), so this tool returns a job_handle immediately without waiting -- call get_result with that job_handle to poll for completion instead of calling convert_pdf again. Always pass idempotency_key; reuse the exact same value if you retry the same request, otherwise retries can double-charge and double-process. Provide the PDF either as a public https URL (source.type="url", up to ~200MB) or inline base64 (source.type="base64", up to ~20MB) -- prefer the URL form for large files. Requires sign-in (OAuth): this session is not authenticated, so calling this tool will fail until the PDFIntact account is connected and authorized.…
- lowNo source repository listed
maint.no-repo
Overall 63/100. Components that don't apply are left out of the denominator. Any critical finding is an F.RubricAppeal a findingJSON
Other servers that do what Pdfintact does
- TooldashOffline PDF and text tools: merge, extract pages, inspect, clean text. No upload, no API key.not reviewedGrowingA
- pixelpactExtract a visual contract from a reference page and measure an implementation against itnot reviewedGrowingA
- TalonicExtract structured, schema-validated data from PDFs, scans, images, spreadsheets, and forms.not reviewedGrowingA