decision: should madtea ship a Claude Code plugin at all, or is the MCP server the whole product? #450

Closed
opened 2026-08-21 22:19:08 +00:00 by hexajon · 1 comment
Owner

The question

madtea ships two things: the MCP server, and a Claude Code plugin that bundles the same server plus the hooks and skills. #437 and #443 settled HOW to distribute the plugin. This issue asks the prior question I skipped past: should the plugin exist at all, or is the MCP server the whole product? I want this answered before I spend more on the distribution machinery in #443.

Why I am asking

The MCP server is the real surface. It is the cross-client install, and every madt_ tool call goes through it. The plugin manifest can only claim Claude Code support anyway; the cross-client story is the server, a separate install (already noted in #437 and #443).

The plugin bundles a copy of that same MCP server. When both the standalone server and the plugin are active in one Claude Code install, every madt_ tool registers twice, because the plugin namespaces its server as mcp__plugin_madtea_madtea__*. Suppressing the duplicate needs an explicit deny in the client config. So for a user who already has the server, the plugin does not add the server; it adds a second copy of it, plus the hooks and skills.

That reframes the plugin's real value as: a one-command install for Claude Code that also delivers the hooks and skills. The question is whether that convenience is worth its cost.

What the plugin gets us (the case to keep it)

  • One-command install for Claude Code users, versus a manual MCP server setup.
  • It is the only delivery path for the hooks and skills. The bare MCP server does not carry them.
  • Discovery through a marketplace listing.

What it costs (the case to drop it)

  • A second distribution path for the same server, with its own repo (sixfold-space/claude-plugins), a vendor-and-assemble step, and a manifest.
  • The version-drift and update-detection traps in #437 and #443 exist only because the plugin exists.
  • The duplicate-tool problem above: a user with both the server and the plugin gets every madt_ tool twice unless they deny one.
  • ADR churn (ADR 0010, ADR 0033) tied to keeping the plugin shippable.

Options

  1. Keep the plugin. Continue #443. Accept the second distribution path as the price of one-command install plus bundled hooks and skills, and document that a user installs the plugin OR the server, not both.
  2. Drop the plugin. Ship the MCP server as the single product. Deliver the hooks and skills another way (documented setup, or a small installer), and retire claude-plugins, the assemble step, and the related ADR consequences. #443 becomes moot.
  3. Keep it, but narrow it. Ship a plugin that carries ONLY the hooks and skills and does not bundle the MCP server, so there is no duplicate-tool problem and the server stays the single tool surface.

I have not decided this. I need the answer before #443 lands, because option 2 or 3 changes or removes that work.

  • #437 (plugin distribution contradicts the docs; assumes the plugin ships).
  • #443 (implements the keep-and-distribute decision; downstream of this question).
  • ADR 0010, ADR 0033.
## The question madtea ships two things: the MCP server, and a Claude Code plugin that bundles the same server plus the hooks and skills. #437 and #443 settled HOW to distribute the plugin. This issue asks the prior question I skipped past: should the plugin exist at all, or is the MCP server the whole product? I want this answered before I spend more on the distribution machinery in #443. ## Why I am asking The MCP server is the real surface. It is the cross-client install, and every `madt_` tool call goes through it. The plugin manifest can only claim Claude Code support anyway; the cross-client story is the server, a separate install (already noted in #437 and #443). The plugin bundles a copy of that same MCP server. When both the standalone server and the plugin are active in one Claude Code install, every `madt_` tool registers twice, because the plugin namespaces its server as `mcp__plugin_madtea_madtea__*`. Suppressing the duplicate needs an explicit deny in the client config. So for a user who already has the server, the plugin does not add the server; it adds a second copy of it, plus the hooks and skills. That reframes the plugin's real value as: a one-command install for Claude Code that also delivers the hooks and skills. The question is whether that convenience is worth its cost. ## What the plugin gets us (the case to keep it) - One-command install for Claude Code users, versus a manual MCP server setup. - It is the only delivery path for the hooks and skills. The bare MCP server does not carry them. - Discovery through a marketplace listing. ## What it costs (the case to drop it) - A second distribution path for the same server, with its own repo (`sixfold-space/claude-plugins`), a vendor-and-assemble step, and a manifest. - The version-drift and update-detection traps in #437 and #443 exist only because the plugin exists. - The duplicate-tool problem above: a user with both the server and the plugin gets every `madt_` tool twice unless they deny one. - ADR churn (ADR 0010, ADR 0033) tied to keeping the plugin shippable. ## Options 1. **Keep the plugin.** Continue #443. Accept the second distribution path as the price of one-command install plus bundled hooks and skills, and document that a user installs the plugin OR the server, not both. 2. **Drop the plugin.** Ship the MCP server as the single product. Deliver the hooks and skills another way (documented setup, or a small installer), and retire `claude-plugins`, the assemble step, and the related ADR consequences. #443 becomes moot. 3. **Keep it, but narrow it.** Ship a plugin that carries ONLY the hooks and skills and does not bundle the MCP server, so there is no duplicate-tool problem and the server stays the single tool surface. I have not decided this. I need the answer before #443 lands, because option 2 or 3 changes or removes that work. ## Related - #437 (plugin distribution contradicts the docs; assumes the plugin ships). - #443 (implements the keep-and-distribute decision; downstream of this question). - ADR 0010, ADR 0033.
Author
Owner

Decision: option 3. Narrow the plugin to the hooks and skills only. It no longer bundles the MCP server.

The server is the single tool surface and the cross-client install. A plugin that also bundled the server registered every madt_ tool twice for anyone who already ran the server, fixable only by a manual deny. Narrowing the plugin removes that, and keeps the one thing the bare server cannot deliver: the agent-safety hooks and the workflow skills.

Result:

  • The plugin ships the hooks and skills, no MCP server.
  • The server stays a separate install. A user installs the server for the tools and the plugin for the hooks and skills. They no longer overlap, so there is no "one or the other" caveat.
  • Implementation is #443 (rescoped) and #437. The assemble step vendors hooks and skills only; the manifest drops the server and the cross-client claim.

Closing: the product-shape question is answered.

Decision: option 3. Narrow the plugin to the hooks and skills only. It no longer bundles the MCP server. The server is the single tool surface and the cross-client install. A plugin that also bundled the server registered every `madt_` tool twice for anyone who already ran the server, fixable only by a manual deny. Narrowing the plugin removes that, and keeps the one thing the bare server cannot deliver: the agent-safety hooks and the workflow skills. Result: - The plugin ships the hooks and skills, no MCP server. - The server stays a separate install. A user installs the server for the tools and the plugin for the hooks and skills. They no longer overlap, so there is no "one or the other" caveat. - Implementation is #443 (rescoped) and #437. The assemble step vendors hooks and skills only; the manifest drops the server and the cross-client claim. Closing: the product-shape question is answered.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
sixfold-space/madtea#450
No description provided.