Fixing MCP Setup Instructions: When Documentation Gets Out of Sync
Had one of those classic moments today where my own documentation was completely wrong. You know the feeling – you ship something, then realize the setup instructions you wrote don't actually work.
I was working on memstack-skill-loader, and the README had users running pip install -r requirements.txt followed by manual JSON config editing. Turns out that's completely outdated. The real setup is much cleaner:
pip install -e . --break-system-packages
claude mcp add --scope user
That's it. The CLI handles everything.
But here's where it got interesting – I had THREE different MCP config files floating around:
~/.claude/mcp_servers.json– the correct one~/.claude/.mcp.json– a debugging leftover with wrong settings~/AppData/Roaming/Claude/claude_desktop_config.json– had the wrong MCP config injected
Classic config file sprawl. The debugging artifact had bare python instead of the full path, and memstack_skill_loader.server instead of just memstack_skill_loader. Small differences that break everything.
Cleaned it all up:
- Deleted the stale
.mcp.jsonfile - Restored the desktop config to preferences-only
- Updated the README with the correct flow
Key lessons learned:
- Windows needs full absolute Python paths in MCP configs –
pythonalone is unreliable - The module entry point is
memstack_skill_loader, notmemstack_skill_loader.server --scope useris the way to go for global MCP servers
Now everything's working properly with TF-IDF search running at about 1.8 seconds cold start. Not bad for a lazy afternoon of config archaeology.
Next up: deciding whether to keep those debug log files or finally clean them up. Sometimes the messiest part of coding is just keeping track of all the little files you create along the way.