Back to DevLog

Fixing MCP Setup Instructions: When Documentation Gets Out of Sync

2 min read

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:

  1. ~/.claude/mcp_servers.json – the correct one
  2. ~/.claude/.mcp.json – a debugging leftover with wrong settings
  3. ~/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.json file
  • 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 – python alone is unreliable
  • The module entry point is memstack_skill_loader, not memstack_skill_loader.server
  • --scope user is 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.

Share this post