A PyPI package squatting the name 'mcp' (version 2.0.0) broke a developer's Claude Desktop MCP server setup, according to a Dev.to debugging log. The developer, d1n35h_v, spent significant time tracing the ModuleNotFoundError before discovering the unrelated package had been pulled in instead of the real modelcontextprotocol SDK.
Key facts
- PyPI squatter 'mcp' version 2.0.0 broke FastMCP import
- Fix: pin 'mcp[cli]>=1.2.0,<2.0.0' installed SDK 1.29.0
- MCP SDK requires Python 3.10+, developer pinned 3.12
- MCP Inspector via 'uv run mcp dev' tests tools standalone
- Developer's custom server code was ~20 lines of Python
The Model Context Protocol (MCP), introduced by Anthropic in November 2024, is meant to let models like Claude call external tools. But a recent debugging log from developer d1n35h_v on Dev.to shows that the ecosystem's packaging ecosystem can still trip up even a prepared developer.
Key Takeaways
- A developer's Claude Desktop MCP setup broke due to a PyPI package squatting the 'mcp' name.
- Pinning 'mcp[cli]>=1.2.0,<2.0.0' fixed it, highlighting supply-chain risks in the MCP ecosystem.
The Package Name Trap
After setting up a custom MCP server to publish blogs to Dev.to, the developer ran into a ModuleNotFoundError: No module named 'mcp.server.fastmcp' — even though import mcp worked. The culprit: uv pip show mcp revealed version 2.0.0 with dependencies like httpx2, mcp-types, pyjwt, and pywin32, none of which belong to the real MCP SDK. An unrelated package was squatting the name mcp on PyPI. The fix was pinning uv add "mcp[cli]>=1.2.0,<2.0.0", which pulled in the legitimate SDK 1.29.0, per the developer's log.
This is a supply-chain risk that goes beyond a simple annoyance. A developer installing mcp without version pinning could end up with a package that behaves differently or contains malicious code. The fact that the squatter package had a version number higher than the legitimate SDK (2.0.0 vs 1.x) means naive version resolution would always pick it.
Environment Debugging Dominates
The developer's log also highlights that most of the time spent was on standard environment issues: PATH not being updated in PowerShell, a stale requires-python = ">=3.9" in pyproject.toml conflicting with the MCP SDK's 3.10+ requirement, and a JSON nesting mistake in claude_desktop_config.json where the server was added as a sibling of mcpServers instead of nested inside it. On Windows, Claude Desktop also didn't inherit the shell's PATH, requiring the full path from where.exe uv.
The developer notes the actual MCP server code was only about 20 lines of Python with a docstring. The value of the MCP Inspector — launched via uv run mcp dev — was highlighted as a way to test tools standalone before involving Claude, showing raw request/response payloads.
The Real Lesson
This log underscores that agent tooling reliability is gated by the underlying plumbing, not the AI model itself. The developer's successful flow — Claude reading a draft via the filesystem server, rewriting it, and publishing via the custom publish_blog_to_devto tool — worked only after the environment was sane. The developer's next plan is to add a tool that pulls GitHub commit history to auto-draft "what I built this week" posts, which would extend the same pattern to a new data source.
What to watch
Watch whether Anthropic or the MCP project adds official guidance or a package verification step to prevent name squatting. Also track if the squatter package gets yanked from PyPI, and whether more developers report similar supply-chain issues as MCP adoption grows beyond early adopters.
Source: dev.to
[Updated 02 Aug via devto_mcp]
A second MCP server debugging log [per Dev.to developer enjoy_kumawat] reveals a recurring supply-chain pitfall: the same CWD-relative path bug appeared twice in one server.py file. After fixing a .env load that relied on ".env" instead of os.path.dirname(os.path.abspath(__file__)), the developer found an unfixed logs/article_updates.jsonl path in an update_article tool just 19 lines below. Because MCP clients launch server.py as a subprocess without setting cwd, the audit log can silently write to the wrong directory, undermining the tool's purpose of tracing bad writes. The developer verified the issue by running the function standalone, confirming plain os.path behavior.
