TL;DR - Do not choose an MCP document tool by file extension alone.
Choose it by the job:
- Turn finished Markdown into a shareable file: use a conversion tool.
- Edit, comment on, or redline an existing Word file: use a DOCX editing tool.
- Search or extract information from an existing PDF: use a PDF reading tool.
- Merge, sign, redact, or transform existing files: use a document-operations
tool.
depapel's public MCP server fits the first job. It turns
Markdown into PDF or DOCX; it is not a Word redlining system or a general PDF
editor.
"I need an MCP tool for PDF" sounds specific.
It is not.
The person asking might want an agent to create a report, read a contract,
change a Word document, merge several PDFs, or simply save a good Markdown
answer as a file.
Those are different workflows. A tool that is excellent at one can be the
wrong choice for another.
The useful first question is:
What exists before the tool runs, and what should exist after it finishes?
The four document jobs people mix together
Use this decision table before looking at servers or tool catalogs:
| Job |
Starting point |
Desired result |
Tool shape |
| Create a deliverable |
Markdown or structured text |
New PDF or DOCX |
Conversion |
| Review or revise a Word file |
Existing DOCX |
Edited DOCX, comments, or tracked changes |
DOCX editing |
| Read a PDF |
Existing PDF |
Extracted text, answers, or citations |
PDF reading and retrieval |
| Operate on files |
Existing PDF or DOCX files |
Merge, sign, redact, split, or transform |
Document operations |
The file extension appears in every row, but the agent needs a different
capability in each one.
That is why "best MCP PDF server" lists are often less useful than they look.
They rank tools that do different jobs as if they were interchangeable.
What MCP standardizes—and what it does not
The Model Context Protocol tool specification
gives clients a common way to discover tools with tools/list and invoke them
with tools/call. The
Streamable HTTP transport
gives remote servers a standard HTTP connection shape.
That solves an important integration problem: an agent can discover a tool,
inspect its input schema, and call it without a custom integration for every
service.
It does not guarantee that every MCP host presents generated files the same
way.
The host still decides the interaction model. A widget-capable chat host can
show buttons and previews. A coding agent may receive a structured HTTP
contract and use its own shell or HTTP client to save the bytes. Another
client may support tool calls but not a rich component at all.
Current OpenAI Apps SDK guidance reflects that difference. ChatGPT supports
optional widget file APIs, including temporary download URLs for file
references, while the baseline tool result still uses normal MCP fields such
as structuredContent and content.
Claude Code's MCP documentation
recommends remote HTTP servers for cloud services and exposes their tools
inside the coding-agent workflow.
The practical lesson is simple:
A document tool needs a generation contract and a delivery contract.
"The PDF was created" is only half the job if the user cannot open or save it.
When conversion is the right tool
Use a conversion tool when the content already exists as Markdown or structured
text and the next step is a real document.
Typical examples:
- an agent drafted a technical brief,
- a research workflow produced a Markdown memo,
- a coding assistant wrote release notes with tables and code,
- or a project update now needs to leave chat as an attachment.
The source might look like this:
# Agent Handoff Brief
## Decision
Use PDF for fixed delivery and DOCX for review.
## Evidence
- The source stays in Markdown.
- The agent requests a real file.
| Output | Use it when |
|---|---|
| PDF | Layout should stay fixed |
| DOCX | Reviewers need comments and edits |
This is not a document-editing problem. There is no existing Word file to open
and no PDF to inspect. It is a rendering problem: preserve the headings, list,
and table while producing the requested format.
That is where depapel fits.
How depapel's MCP path works
depapel exposes a public remote MCP endpoint:
https://depapel.ginylil.com/api/mcp
The exact configuration syntax depends on the client. For Claude Code, the
current remote HTTP form is:
claude mcp add --transport http depapel https://depapel.ginylil.com/api/mcp
Once connected, there are two delivery shapes:
- Widget-capable hosts can use the chooser and download tools.
- Other MCP clients can use the direct PDF or Word tools, receive a
save-ready
/api/convert request contract, and execute it with an available
HTTP client.
The conversion itself is intentionally narrow:
- Markdown in,
- PDF or DOCX out,
- with headings, lists, tables, code blocks, images, and Mermaid diagrams
handled as document structure.
For this post, we tested the live public endpoint rather than relying only on
the repository. We discovered the tools through tools/list, requested one PDF
contract and one DOCX contract, executed both against /api/convert, and
inspected the results.
The PDF was a valid one-page A4 document containing the expected title,
sections, bullets, and table. The DOCX was a valid Word 2007+ file, and its
OOXML contained the same structured content.
That proves the conversion and download path. It does not prove that every MCP
host renders the same UI, because MCP does not require that.
When a DOCX editor is the right tool
Use a DOCX editing tool when a Word document already exists and the agent needs
to work inside it.
Examples:
- add or reply to comments,
- suggest tracked changes,
- redline a contract,
- change styles in selected paragraphs,
- or preserve an existing template while revising content.
That is a different architecture from Markdown conversion. The tool must
understand the existing OOXML package, document relationships, comments,
styles, numbering, and possibly tracked-change semantics.
Microsoft's current
Work IQ Word MCP server,
for example, is a preview aimed at creating and retrieving Word documents in
OneDrive or SharePoint and working with comments. Other document-editor MCP
servers expose more granular local or headless DOCX editing operations.
Use those tools when the Word file itself is the workspace.
Use depapel when Markdown is the source and Word is the handoff format.
When a PDF reader is the right tool
Use a PDF reading or retrieval tool when the PDF already exists and the agent
needs information from it.
That tool may need:
- page-aware text extraction,
- OCR for scanned pages,
- table or image extraction,
- search across a large document,
- or citations back to exact pages.
Generating a PDF does not provide those capabilities automatically. A
purpose-built reader such as
pdf-mcp, for example, exposes page-aware
search, selective reading, table extraction, rendering, and optional OCR.
depapel can import text-based PDFs back into Markdown, but it does not run OCR.
If the job starts with a scanned contract or a 500-page reference manual, use a
PDF reader designed for that workload.
When document operations are the right tool
Some jobs are neither generation nor reading.
If the request is to merge, split, sign, redact, compress, encrypt, or transform
existing files, choose a document-operations tool with those explicit
capabilities.
Do not assume that a tool advertising "PDF support" performs all PDF jobs.
Check the tool list and input schema, then confirm where output files are
written or returned.
A better prompt for your agent
Weak prompt:
Find an MCP PDF tool and make this a PDF.
Better prompt:
The source below is complete Markdown. Create a new PDF named
agent-handoff-brief.pdf. Preserve the headings, list, and table. Do not edit
an existing file. Return or save the final PDF and confirm where it was
written.
For review instead:
Create an editable DOCX from this Markdown because reviewers need comments
and changes in Word. Preserve the structure and save the final file.
Those prompts tell the agent the starting state, target format, required
structure, and delivery expectation.
Honest limits
- depapel converts document-shaped Markdown; it does not edit an existing DOCX
in place.
- It is not a PDF redaction, signing, or merge tool.
- PDF import requires extractable text and does not include OCR.
- MCP hosts differ, so widget presentation and local file saving are separate
client capabilities.
- Generated AI content still needs human review before formal delivery.
Those limits are useful. They make the tool choice predictable.
Final rule to remember
Do not ask only, "Does this MCP server support PDF or Word?"
Ask:
- What is the input: Markdown, DOCX, or PDF?
- Is the job creation, editing, reading, or file operations?
- How will the final file reach the user?
If the answer is "finished Markdown should become a new shareable PDF or
editable DOCX," use a conversion tool such as
depapel's public MCP server.
If the answer starts with an existing document, choose the tool built for that
document operation instead.
That one decision prevents most bad MCP document-tool choices.
References
Please enable JavaScript to use depapel.