Summary
markitdown-mcp currently has a mandatory dependency on:
"markitdown[all]>=0.1.1,<0.2.0"
This makes installing the MCP server on native Windows ARM64 depend on every optional MarkItDown converter, even when those converters are not needed.
On a native ARM64 Surface Pro with CPython 3.14, the base markitdown package installs and works correctly, including native onnxruntime. However, installing the current markitdown-mcp dependency set pulls in the PDF stack and eventually cryptography==50.0.1.
There is no win_arm64 wheel for that current cryptography release, so the installer falls back to compiling it from source and requires a native Rust/OpenSSL build environment.
Environment
OS: Windows on ARM64, Surface Pro
Python: CPython 3.14 ARM64
Python package path: Python314-arm64
markitdown: 0.1.5
markitdown-mcp: 0.0.1a4
onnxruntime: 1.29.0 ARM64
The important part is that this is an entirely native ARM64 Python environment; no x64 emulation is involved.
Reproduction
For example:
eventually attempts to build:
from source:
🍹 Building a mixed python/rust project
🐍 Found CPython 3.14
...
error: failed to run custom build command for `openssl-sys`
...
$HOST = aarch64-pc-windows-msvc
$TARGET = aarch64-pc-windows-msvc
...
Could not find directory of OpenSSL installation
The dependency chain reported by the installer is:
markitdown-mcp
-> markitdown[all]
-> pdfminer-six
-> cryptography
By contrast, the base package installs normally:
and runs natively with ARM64 dependencies:
markitdown 0.1.5
magika 0.6.2
onnxruntime 1.29.0
The markitdown-mcp wheel itself is also pure Python and can be installed without this failure when its dependencies are handled separately.
Why this seems undesirable
The MCP server itself does not inherently require PDF, Office, Azure, audio transcription, YouTube transcription, etc. support just to start and expose convert_to_markdown.
Making markitdown[all] mandatory means an optional converter dependency can make the entire MCP server uninstallable on an otherwise supported Python/platform combination.
It also makes a lightweight local STDIO MCP installation substantially heavier than necessary.
Proposed direction
I think the cleanest dependency model would be for the MCP package to depend on base MarkItDown:
dependencies = [
"mcp>=...",
"markitdown>=0.1.1,<0.2.0",
]
and expose full converter support as an explicit extra, for example:
[project.optional-dependencies]
all = [
"markitdown[all]>=0.1.1,<0.2.0",
]
so users could choose:
pip install markitdown-mcp
for the lightweight/native server, or:
pip install "markitdown-mcp[all]"
when they explicitly want every optional converter.
Mirroring individual MarkItDown extras could also be considered later, but does not seem necessary to solve the underlying installation problem.
I would avoid solving this with an old cryptography pin: this is fundamentally an optional-dependency boundary issue, and pinning an older crypto package would create a maintenance/security liability.
Related
#2363 migrates markitdown-mcp to MCP SDK 2.x. That fixes a separate compatibility problem but currently retains the mandatory markitdown[all] dependency, so the Windows ARM64 installation problem remains independent of that PR.
Summary
markitdown-mcpcurrently has a mandatory dependency on:"markitdown[all]>=0.1.1,<0.2.0"This makes installing the MCP server on native Windows ARM64 depend on every optional MarkItDown converter, even when those converters are not needed.
On a native ARM64 Surface Pro with CPython 3.14, the base
markitdownpackage installs and works correctly, including nativeonnxruntime. However, installing the currentmarkitdown-mcpdependency set pulls in the PDF stack and eventuallycryptography==50.0.1.There is no
win_arm64wheel for that current cryptography release, so the installer falls back to compiling it from source and requires a native Rust/OpenSSL build environment.Environment
The important part is that this is an entirely native ARM64 Python environment; no x64 emulation is involved.
Reproduction
For example:
uvx markitdown-mcpeventually attempts to build:
from source:
The dependency chain reported by the installer is:
By contrast, the base package installs normally:
and runs natively with ARM64 dependencies:
The
markitdown-mcpwheel itself is also pure Python and can be installed without this failure when its dependencies are handled separately.Why this seems undesirable
The MCP server itself does not inherently require PDF, Office, Azure, audio transcription, YouTube transcription, etc. support just to start and expose
convert_to_markdown.Making
markitdown[all]mandatory means an optional converter dependency can make the entire MCP server uninstallable on an otherwise supported Python/platform combination.It also makes a lightweight local STDIO MCP installation substantially heavier than necessary.
Proposed direction
I think the cleanest dependency model would be for the MCP package to depend on base MarkItDown:
and expose full converter support as an explicit extra, for example:
so users could choose:
for the lightweight/native server, or:
pip install "markitdown-mcp[all]"when they explicitly want every optional converter.
Mirroring individual MarkItDown extras could also be considered later, but does not seem necessary to solve the underlying installation problem.
I would avoid solving this with an old
cryptographypin: this is fundamentally an optional-dependency boundary issue, and pinning an older crypto package would create a maintenance/security liability.Related
#2363 migrates
markitdown-mcpto MCP SDK 2.x. That fixes a separate compatibility problem but currently retains the mandatorymarkitdown[all]dependency, so the Windows ARM64 installation problem remains independent of that PR.