Bundle the full Morph experience (Fast Apply + WarpGrep MCP + Compact) into the plugin instead of splitting install across dashboard command and marketplace

[ichoosetoaccept]

Summary

Getting the full Morph experience in Claude Code today requires two separate install paths, and the split isn't technically necessary. The README itself says "We strongly recommend having BOTH the MCP and Plugin installed" — if that's the recommendation, it should also be the default that ships.

Current state

To get everything Morph offers, a user has to:

1. Run the dashboard-provided shell command:

   claude mcp add morph-mcp --scope user -e MORPH_API_KEY=... -- npx -y @morphllm/morphmcp \
     && mkdir -p ~/.claude \
     && echo "Fast Apply: ... Warp Grep: ..." >> ~/.claude/CLAUDE.md
   

   This installs morph-mcp (Fast Apply's edit_file tool + WarpGrep subagent) and appends usage hints to ~/.claude/CLAUDE.md.

2. Then, inside Claude Code:

   /plugin marketplace add morphllm/morph-claude-code-plugin
   /plugin install morph-compact@morph
   /morph-compact:install
   

   This installs Compact and wires up the API key + compact sentinel instructions.

Confirmed by reading the repo:

• .claude-plugin/plugin.json declares only morph-compact with a compaction-focused description.
• .claude-plugin/marketplace.json lists exactly one plugin: morph-compact v0.2.5.
• No .mcp.json exists anywhere in the plugin.
• skills/ contains only install and uninstall — setup/teardown for Compact. No skill teaches Claude about edit_file or warp-grep; that guidance only reaches Claude via the dashboard command's >> append to ~/.claude/CLAUDE.md.

Problems with the current split

1. Two separate mental models for one product. Users have to know that "Morph" = (MCP install + marketplace install + install skill). The marketing (https://www.morphllm.com/claude-code-plugins) positions plugins as a unified packaging format — the current repo doesn't reflect that.
2. The dashboard command uses >>. Running it twice duplicates the CLAUDE.md hint block. It's not idempotent and there's no uninstall equivalent.
3. Discoverability is poor. A user who finds this repo first has no signal that Fast Apply and WarpGrep exist until they hit the one-line Important callout in the README.
4. The split isn't technically required. Claude Code plugins can declare an .mcp.json at the plugin root, and skills can inject CLAUDE.md content — both of which are already in the toolbox the plugin uses for Compact.

Proposal

Bundle everything into this plugin (or into sibling plugins within the same morph marketplace). Concrete changes:

1. Add .mcp.json at the plugin root declaring morph-mcp, with MORPH_API_KEY read from the same ~/.claude/morph/.env that the existing install skill already creates. One API key, one source of truth.
2. Extend the install skill (or add a new fastapply-warpgrep skill) to append the Fast Apply and WarpGrep usage guidance to CLAUDE.md in an idempotent way (guarded block, or managed section with a sentinel), and have uninstall remove it cleanly.
3. Optionally split into two plugins in the same marketplace — e.g. morph-compact and morph-tools — so users who only want one can opt in granularly. But the README's top-line recommendation ("have both") should be reflected by making morph (the marketplace) install both by default, or by adding a meta-plugin.
4. Retire or deprecate the dashboard shell command once the plugin covers it, or have the dashboard simply show /plugin marketplace add morphllm/morph-claude-code-plugin + /plugin install morph@morph.

Why this matters

Right now the friction to "try the full Morph stack" is higher than it needs to be, and the split makes the product feel less coherent than it is. A single /plugin install that sets up Fast Apply + WarpGrep + Compact with one API key prompt would match what the README already tells users to do, and would put Morph's own installation story in line with the plugin-ecosystem pitch on the marketing site.

Happy to contribute a PR if the direction sounds right — just want to confirm this is a design decision open to revisiting and not a constraint I'm missing (e.g. the MCP being maintained separately so it can ship to Cursor/VS Code from the same artifact).

[bhaktatejas922]

@DhruvBhatia0