Claude Desktop MCP extension (tooluniverse 1.0.16) fails to start due to yanked fitz dep — please cut a new extension release once #516 lands

[DrGilbert2]

Summary

The Claude Desktop extension bundle (tooluniverse v1.0.16, internal package tooluniverse-mcp-native 1.0.15) no longer starts: its bundled pyproject.toml declares fitz>=0.0.1.dev2, and since that version was yanked from PyPI, uv cannot resolve the environment. The server process exits before completing the MCP handshake, and Claude Desktop reports the extension as disconnected.

PR #516 fixes this in the main repo (fitz → pymupdf), but the Desktop extension ships its own pyproject.toml/uv.lock, so installed extensions remain broken until a new bundle version is published. Filing this so the extension release isn't missed after #516 merges.

Environment

• macOS (Apple Silicon), Claude Desktop, ToolUniverse extension v1.0.16
• uv 0.11.24, Python 3.12 (as pinned by the extension manifest)

What happens

Claude Desktop launches the server via uv run --directory <ext> --with . --python 3.12 src/run_stdio.py, which fails immediately:

× No solution found when resolving `--with` dependencies:
╰─▶ Because only fitz==0.0.0 is available and
    tooluniverse-mcp-native==1.0.15 depends on fitz>=0.0.1.dev2, we can
    conclude that tooluniverse-mcp-native==1.0.15 cannot be used.
    And because only tooluniverse-mcp-native==1.0.15 is available and you
    require tooluniverse-mcp-native, we can conclude that your requirements
    are unsatisfiable.
 
[ToolUniverse] [info] Server transport closed unexpectedly, this is likely
due to the process exiting early.
[ToolUniverse] [error] Server disconnected.

(From ~/Library/Logs/Claude/mcp-server-ToolUniverse.log.)

Root cause

Same as #516: the PyPI package named fitz is an unrelated placeholder, never PyMuPDF; its 0.0.1.dev2 release was yanked, leaving only 0.0.0, which makes the requirement unsatisfiable. The extension bundle's pyproject.toml (line 35) carries the same dependency as the main repo.

Verified fix (tested locally on the installed extension)

Editing the installed bundle confirms the swap works end-to-end:

1. In the extension's pyproject.toml: "fitz>=0.0.1.dev2" → "pymupdf>=1.24.0"
2. uv lock (also sheds the stray transitive packages the placeholder fitz pulled in)
   After that, the environment builds (PyMuPDF 1.28.2), the server starts and loads 775 tools, exposes the 5 compact-mode discovery tools, and passes an MCP Inspector initialize + tools/list check. PyMuPDF's import fitz compatibility alias satisfies existing imports (with a deprecation warning — the import pymupdf as fitz change from Fix the fitz dependency: CI is blocked repo-wide, and the declared package was never PyMuPDF #516 applies to the bundle source too).

Ask

Publish an updated extension bundle (e.g. 1.0.17) with the corrected dependency once #516 merges, so auto-update repairs installed extensions. Locally patched installs will be overwritten by that update, which is fine — as long as the new bundle carries the fix.

Related: #516

[gasvn]

Thanks for the detailed report and for testing the workaround. We have published a fixed ToolUniverse 1.4.1 extension.

Could you please download tooluniverse.mcpb, quit Claude Desktop, and install it from Settings → Extensions → Advanced settings → Install Extension…? If the old ToolUniverse extension is still listed, remove it first. After reopening Claude Desktop, try asking: Use ToolUniverse to list the available tool categories.

Please let us know whether it works. If it still disconnects, paste the latest ToolUniverse extension error or the last part of ~/Library/Logs/Claude/mcp-server-ToolUniverse.log.

[01ehex]

Confirming the same failure independently on Windows (not just macOS) — same root cause, same fix.

Environment: Windows, Python 3.12 (uv run --python 3.12), tooluniverse-mcp-native 1.0.15, installed via Claude Desktop "ToolUniverse" extension (manifest v0.4, extension version 1.0.16).

Fix verified locally, same as above:

- "fitz>=0.0.1.dev2",
+ "PyMuPDF>=1.24.0",

Resolves cleanly (Installed 181 packages), server starts and connects.

Haven't yet tried the published 1.4.1 bundle — will reinstall via tooluniverse.mcpb and report back whether it resolves cleanly on Windows too. Noticed #528 was filed for the same extension ID (ant.dir.gh.tooluniverse.tooluniverse-mcp) a day after 1.4.1 shipped — worth checking whether that's a fresh regression or just a stale install.

[craigbdavis]

Confirming this reproduces on Windows 11 (Claude Desktop 1.30096.5, ToolUniverse extension v1.0.16, tooluniverse-mcp-native 1.0.15, Python 3.12), so it isn't macOS-specific.

Identical resolver failure from %APPDATA%\Claude\logs\mcp-server-ToolUniverse.log:

× No solution found when resolving `--with` dependencies:
╰─▶ Because only fitz==0.0.0 is available and
    tooluniverse-mcp-native==1.0.15 depends on fitz>=0.0.1.dev2, we can
    conclude that tooluniverse-mcp-native==1.0.15 cannot be used.
    And because only tooluniverse-mcp-native==1.0.15 is available and you
    require tooluniverse-mcp-native, we can conclude that your requirements
    are unsatisfiable.
[ToolUniverse] [info] Server transport closed unexpectedly, this is likely due to the process exiting early.
[ToolUniverse] [error] Server disconnected.

The fix in the installed bundle works here too. Editing line 35 of the extension's pyproject.toml from "fitz>=0.0.1.dev2" to "pymupdf>=1.24" was sufficient on its own — I did not need to run uv lock. The next launch rebuilt the environment (177 packages) and the server came up clean:

[ToolUniverse] [info] Server started and connected successfully
[ToolUniverse] [info] Message from client: method="initialize" id=0
DEBUG: Loaded static lazy registry with 240 tools.
🚀 Starting ToolUniverse SMCP Server...

One detail that may help others searching for this: the extension's manifest.json reports version 1.0.16 while the bundled pyproject.toml still reports 1.0.15, which makes the version mismatch confusing when diagnosing from the manifest alone.

+1 on cutting a new bundle release once #516 merges — the local edit gets overwritten on the next extension update, so users hitting this have to reapply it or wait.

[fbjk2000]

Verified 1.4.1 on macOS (arm64), Claude Desktop's bundled uv 0.9.7, Python 3.12.

• Downloaded tooluniverse.mcpb from the mcpb release (8,522,559 bytes, sha256 2a42c7d5e86712707249bf234717b288df2d247ce3815c16a03032cae42d9ae0).
• The bundled pyproject.toml no longer declares fitz; dependency resolution succeeds.
• Started the unpacked bundle with the exact invocation Claude Desktop uses (uv run --directory <bundle> --with . --python 3.12 src/run_stdio.py, TOOLUNIVERSE_STDIO_MODE=1): the MCP initialize handshake completes and reports ToolUniverse SMCP Server 3.4.7. First start took about 4 minutes for the fresh environment build; subsequent starts are seconds.

So the resolver failure from this issue is fixed by 1.4.1. For anyone on the broken 1.0.16 bundle who cannot update yet, the one-line local workaround (replace "fitz>=0.0.1.dev2" with "pymupdf>=1.24.0" in the extension's pyproject.toml) also works on macOS, same as reported above for Windows.

One follow-up worth knowing: in 1.4.1 uspto_downloader_tool.py now does import pymupdf as fitz, but pymupdf is not declared in the bundle's pyproject.toml and is absent from the resolved environment. Startup is unaffected because remote tools load lazily, but that tool will fail at call time. Details added to #521, where the same pattern is already tracked for easyocr and python-docx.

[Bongulielmi]

Confirming the shipped Claude Desktop extension (1.0.16, ant.dir.gh.tooluniverse.tooluniverse-mcp) was still failing as of late August — every launch dies at dependency resolution:

x No solution found when resolving `--with` dependencies:
  Because only fitz==0.0.0 is available and
  tooluniverse-mcp-native==1.0.15 depends on fitz>=0.0.1.dev2, we can
  conclude that tooluniverse-mcp-native==1.0.15 cannot be used.

Working local fix for anyone hitting this before a new extension release is cut (macOS paths):

1. Edit ~/Library/Application Support/Claude/Claude Extensions/ant.dir.gh.tooluniverse.tooluniverse-mcp/pyproject.toml and replace "fitz>=0.0.1.dev2" with "pymupdf>=1.24.0" (matching merged PR Fix the fitz dependency: CI is blocked repo-wide, and the declared package was never PyMuPDF #516 — the bundled code only uses the fitz module, i.e. the PyMuPDF API, in src/tooluniverse/remote/uspto_downloader/uspto_downloader_tool.py).
2. In that same directory run uv lock --python 3.12 — the bundled uv.lock also still pins fitz 0.0.1.dev2, so a re-lock is needed, not just the pyproject edit.
3. Fully restart Claude Desktop (Cmd+Q).

Verified working since 2026-08-26: resolution succeeds (172 packages), and the server completes the MCP initialize handshake and serves tool calls (serverInfo "ToolUniverse SMCP Server" v3.2.4; uv 0.9.5, Python 3.12, macOS arm64).

A new extension release with the #516 fix would resolve this for everyone still on 1.0.16. Thanks!