Click on "Install 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., "@mdify convert budget.xlsx to markdown"
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.
Automatically converts files to markdown when Claude Code reads them - cutting token usage by up to 98%.
When you attach a PDF, DOCX, XLSX, or CSV to a Claude Code chat, Claude normally receives raw binary content - thousands of tokens of unreadable garbage. mdify intercepts the Read call via a PreToolUse hook, converts the file to clean markdown, caches it, and redirects Claude to the compact version. You do nothing differently.
These numbers use real files measured against Claude's tokenizer (1 token ~ 4 chars).
File | Type | Original | Raw tokens | After mdify | Saved |
Resume (2 pages) | 180 KB | ~45,000 (binary, unreadable) | ~820 tokens | 98% | |
Project report (12 pages) | DOCX | 520 KB | ~130,000 (XML garbage) | ~3,100 tokens | 97.6% |
Budget spreadsheet (500 rows) | XLSX | 95 KB | ~23,750 (binary) | ~8,400 tokens | 64.7% |
Metrics export (200 rows) | CSV | 14 KB | ~3,500 (already text) | ~3,100 tokens | 11.4% |
What "raw tokens" means: Without mdify, Claude Code reads the file bytes directly. PDFs and DOCX files are binary formats - Claude receives a stream of unreadable characters that costs tokens but conveys nothing. mdify makes these files usable, not just smaller.
# Claude gets this from Read("report.pdf"):
%PDF-1.4
1 0 obj << /Type /Catalog /Pages 2 0 R >> endobj
2 0 obj << /Type /Pages /Kids [3 0 R] /Count 1 >> endobj
xref 0 4
0000000000 65535 f
0000000009 00000 n
...
[~45,000 tokens of this - unreadable, unusable]<!-- mdify | source: /Users/you/report.pdf | original: 180 KB | ~820 tokens -->
# Quarterly Report Q3 2025
## Executive Summary
Revenue grew 24% year-over-year, driven primarily by expansion in the
enterprise segment. Operating margins improved to 18.4% from 14.2%...
## Key Metrics
| Metric | Q3 2024 | Q3 2025 | Change |
|---------------|---------|---------|--------|
| Revenue | $4.2M | $5.2M | +24% |
| Gross Margin | 61% | 64% | +3pp |
...
[820 tokens - clean, structured, immediately useful]Related MCP server: MarkltDown MCP Server
Node.js 18+
Claude Code (any version with MCP support)
git clone https://github.com/sundeepsuddala/mdify
cd mdify
npm install
node setup.jsRestart Claude Code, then run /mcp to confirm mdify appears as connected.
That's it. No configuration needed.
Extension | Library | Notes |
| pdf-parse | Text extraction; images in PDFs are skipped |
| mammoth | Preserves headings, bold, tables, lists |
| xlsx (SheetJS) | Each sheet becomes a markdown table |
| built-in | Proper quoted-field parsing; renders as table |
Files over 50 MB are passed through unchanged (too large to convert reliably).
You mention "read report.pdf"
|
Claude calls Read(file_path="report.pdf")
|
PreToolUse hook fires -> calls mdify MCP tool: convert_to_markdown
|
mdify checks cache (~/.claude-md-cache/)
|
[cache hit] -----> return cached .md path
|
[cache miss] -> convert -> save -> return .md path
|
Claude Code swaps the Read path: reads .md instead of original
|
Claude gets clean markdown, uses ~98% fewer tokensThe converted files are cached in ~/.claude-md-cache/ keyed by file path + modification time. Re-attaching the same file costs nothing. Stale cache entries (older than 7 days) are pruned automatically on each server start. Set the MDIFY_CACHE_DIR environment variable to use a different cache location.
setup.js makes exactly two changes:
~/.claude.json - registers the MCP server:
{
"mcpServers": {
"mdify": {
"type": "stdio",
"command": "node",
"args": ["/path/to/mdify/src/index.js"]
}
}
}~/.claude/settings.json - adds the hook:
{
"hooks": {
"PreToolUse": [
{
"matcher": "Read",
"hooks": [
{
"type": "mcp_tool",
"server": "mdify",
"tool": "convert_to_markdown",
"timeout": 30
}
]
}
]
}
}Both changes are additive - existing config is preserved.
/mcp does not show mdify as connected
Make sure you restarted Claude Code after running node setup.js
Check ~/.claude.json has mcpServers.mdify pointing to the correct path
Run node src/index.js manually to see startup errors
A file is not being converted
Only PDF, DOCX, DOC, XLSX, XLS, and CSV are converted. All other files pass through.
Files over 50 MB pass through.
Check ~/.claude-md-cache/ to see if a cached .md exists
I want to clear the cache
rm -rf ~/.claude-md-cacheI want to uninstall
node setup.js --uninstallThis removes the mcpServers.mdify entry from ~/.claude.json and the mdify hook from ~/.claude/settings.json, leaving all your other config untouched. Restart Claude Code afterward. To also clear cached conversions: rm -rf ~/.claude-md-cache.
The xlsx (SheetJS) package has a known prototype pollution advisory. Since mdify only reads files you explicitly provide from your own machine, the practical risk is negligible. If this is a concern, avoid XLSX/XLS files and only use CSV exports instead.
MIT
Called automatically by the PreToolUse hook when Claude Code reads a file. Converts PDF, DOCX, XLSX, and CSV files to compact markdown before they enter the context window, reducing token usage by up to 98%.
| Name | Required | Description | Default |
|---|---|---|---|
| tool_input | No | The hook event tool_input payload from Claude Code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It explains that the tool runs automatically, converts files before they enter the context window, and reduces token usage—useful context. However, it does not explicitly state that the original file is not modified or address failure/edge-case behavior.
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?
The description is a single, tightly packed sentence that conveys the trigger, input types, transformation, timing, and benefit. Every clause adds value with no repetition or 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?
Given the simple one-parameter schema, the description fully explains what triggers the tool, what it does, when it occurs, and why it is useful. The lack of an output schema is acceptable because the transformation outcome (markdown in the context window) is clearly implied.
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 single parameter 'file_path' is already well-documented in the schema. The description does not add parameter-specific detail beyond naming the input file, which meets the baseline for high schema coverage but does not exceed it.
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?
The description uses a specific verb ('converts') and explicitly lists the supported file types (PDF, DOCX, XLSX, CSV) and output format (markdown). It clearly distinguishes this tool's function as an automatic preprocessing hook, even in the absence of siblings.
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?
The description states that the tool is 'Called automatically by the PreToolUse hook when Claude Code reads a file,' which clearly communicates when it is triggered. It does not explicitly rule out manual invocation or name alternatives, but the automatic nature is clearly established.
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. Dates show when Glama detected each change.
v1.0.1convert_to_markdownWith only one tool, there is no possibility of confusion between tools. The single tool's purpose is clearly distinct and unambiguous.
The tool name 'convert_to_markdown' follows a clear verb_noun pattern in snake_case. Since there is only one tool, naming consistency is trivially maintained.
The server has a single, narrowly-scoped purpose: converting files to markdown. One tool is perfectly appropriate for this focused task, and the tool earns its place.
The tool covers all major document formats (PDF, DOCX, XLSX, CSV) for conversion to markdown, fully addressing the server's stated purpose without obvious gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Convert PDF, DOCX, HTML, and URLs to clean, LLM-ready markdown with tables preserved
Convert documents and web pages to clean Markdown: PDF, DOCX, XLSX, EPUB, scanned files, any URL.
High-fidelity PDF to structured Markdown conversion and document field extraction.
Parse PDF/Word/PPT/HTML to Markdown; tables as JSON, image extraction, RAG chunking, page ranges.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/SundeepSuddala/mdify'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
