docbridge

Overview Schema Source Related Servers Discussions Admin

pdf_to_markdown

Idempotent

Convert a PDF's text layer to Markdown with page markers, validating text, numbers, and identifiers while marking inferred structure and non-text pages for review.

Instructions

Markdown from a PDF's text layer, with page markers. Headings, lists and tables are INFERRED (reported NOT_CHECKED); the text, numbers and identifiers are validated against the PDF. Pages with no text layer are marked, never guessed (no OCR). [docbridge schema 0.2.4]

Input Schema

TableJSON Schema

Name	Required	Description	Default
`detail`	No	summary: report_summary + report_id (get_report has the rest). full: the whole report inline.	summary
`overwrite`	No
`input_path`	Yes	Absolute file path.
`output_path`	No
`report_path`	No
`page_markers`	No
`detect_tables`	No
`max_differences`	No	Differences kept in the full report; the rest are counted.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`tool`	Yes
`error`	No
`report`	No	The full report. Over MCP only with detail='full'.
`outputs`	No
`report_id`	No	Pass to get_report for the full report (held for this server session).
`disclaimer`	No		docbridge never alters, summarizes or silently truncates source evidence. docbridge reports what it compared. PASS on an axis covers only that axis's stated scope; NOT_CHECKED and UNSUPPORTED are never passes. PDF text is the text layer as PyMuPDF decodes it, not the rendered glyphs. Nothing here interprets meaning: numbers are compared as characters, not as values.
`report_path`	No
`report_summary`	No
`schema_version`	Yes
`conversion_notes`	No
`operation_completed`	Yes	The operation ran and wrote its outputs. Says NOTHING about fidelity: read the report status.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.4Sep 28, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations cover the safety profile (destructive=false, idempotent=true), and the description adds substantial context beyond them: headings/lists/tables are INFERRED and flagged NOT_CHECKED, text/numbers are validated, and no-OCR pages are marked rather than guessed. It stops short of describing write/overwrite behavior or output file handling.

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?

Dense but front-loaded: the core output and its reliability model come first, the no-OCR guarantee last. Every clause carries meaning; only the schema version tag in brackets is arguably filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and the fidelity model is well covered. However, for a tool that writes Markdown to a path, the description never explains the output_path/overwrite/report_path contract, leaving real gaps given the low parameter coverage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 38% across 8 parameters. The description alludes to page markers and the report, but overwrite, output_path, report_path, and detect_tables are undocumented in both description and schema, so it fails to compensate for the coverage gap.

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+resource (Markdown from a PDF) and immediately scopes it to the text layer with page markers, which cleanly separates it from docx_to_markdown and the OCR-based alternatives. An agent knows exactly what artifact this produces.

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

Usage Guidelines3/5

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

The description implies the appropriate context (PDFs that have a text layer) and states the failure mode for pages without one, but never names an alternative tool or an explicit when-to-use/when-not-to-use rule against siblings like docx_to_markdown or validate_conversion. Usage is inferable, not stated.

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

Deploy Server