Summary

The v3.3.2 release artifact on PyPI ships a .claude-plugin/plugin.json that declares "command": "mempalace-mcp", but the same artifact's pyproject.toml only declares the mempalace console script — not mempalace-mcp. Net effect: a fresh pip install mempalace yields a Claude Code plugin config that points to a binary the package didn't install. MCP server fails to launch with "command not found."

First surfaced by @raphaelsamy in #1049#issuecomment-4292661... — filing as a dedicated issue so it has a tracking home.

Reproducer

python3 -m venv /tmp/mpv && source /tmp/mpv/bin/activate
pip install "mempalace==3.3.2"

# The binary that plugin.json calls doesn't exist:
which mempalace        # /tmp/mpv/bin/mempalace   ← present
which mempalace-mcp    # (nothing)                 ← missing

# The plugin config tries to invoke it anyway:
cat $(python3 -c "import mempalace, os, pathlib; print(pathlib.Path(mempalace.__file__).parent.parent / '.claude-plugin' / 'plugin.json')") | grep command
#   "command": "mempalace-mcp"

Then opening Claude Code with the MemPalace plugin installed: MCP server startup fails silently or with exec: "mempalace-mcp": executable file not found in $PATH.

Root cause

Two changes were supposed to ship together but landed on different branches relative to the v3.3.2 cut:

The release/3.3.2 branch appears to have been cut before #340/#805 made it into the release cherry-pick set, but after the plugin.json update landed. The two changes are independently correct; together on v3.3.2 they aren't compatible.

Who's affected

• Fresh PyPI installs, right now. Every user running pip install mempalace today gets a broken Claude Code plugin config.
• Plugin-cache users on v3.3.0 (e.g. @kidwords per #1034) — when the marketplace refresh rolls them to v3.3.2. Their currently-working install breaks the moment the cached plugin.json flips to the new "command": "mempalace-mcp" form against a pip-installed package that doesn't have the binary.
• Not affected: anyone running from a source checkout of current develop (both changes landed together on that branch).

Workaround for affected users (courtesy @raphaelsamy)

Patch the installed plugin.json back to the pre-#340 launch shape:

"mcpServers": {
  "mempalace": {
    "command": "python3",
    "args": ["-m", "mempalace.mcp_server"]
  }
}

Re-introduces the venv-mismatch problem #1049 documents, but gets MCP back online until a proper fix ships.

Proposed fix

Cut v3.3.3 from current develop as a restore-integrity release. develop currently has both the plugin.json change and the pyproject.toml change, so v3.3.3 would ship them together and unbreak the fresh-install path.

Bonus effect: v3.3.3 would also carry #661, #673, #1021 (merged 2026-04-22) and #851 (pagination fix for #802 / #1015 / #1016), so several real user-blockers land simultaneously.

Related

• #1049 — the parent thread where @raphaelsamy first flagged this
• #1034 — @kidwords's "plugin stuck at v3.3.0" report; will become this bug's next casualty when the marketplace refreshes
• #340 / #805 — the PRs that introduced mempalace-mcp; not at fault, just not yet in a published release together with the plugin.json consumer

Optional: release-checklist addition

If helpful, a docs/RELEASING.md (or equivalent) step along the lines of "before cutting: run grep mempalace-mcp pyproject.toml .claude-plugin/plugin.json and verify both files reference it, or neither" would make this class of defect impossible to repeat. Happy to open a small PR for that if desired — tracking it here rather than in this issue's scope.

Environment

• Ubuntu 6.17.0-20, Python 3.12.3 (reproduced)
• macOS-side reports: @raphaelsamy (see #1049 comment)
• pypi: mempalace==3.3.2
• Claude Code: any version reading .claude-plugin/plugin.json