Spec: should local (@loopover/mcp) and remote (src/mcp/server.ts) MCP tool implementations share a core?

[JSONbored]

Problem

packages/loopover-mcp/bin/loopover-mcp.js (local, published npm CLI, --stdio transport) and src/mcp/server.ts (remote, hosted, HTTP/SSE transport) each independently implement their own registered tools — even after the 6 parity-fill issues filed this session (#6149-#6154) bring their tool lists into alignment, the underlying handler code for any tool that exists on both sides is still two separately-maintained implementations. packages/loopover-miner/lib/github-token-resolution.js's own header comment already documents one instance of this tension being deliberately resolved in favor of duplication: "Deliberately reimplements loopover-mcp's own config-file read here rather than depending on @loopover/mcp as a package... a hard runtime dependency between them would mean installing one always pulls in the other."

Area

packages/loopover-mcp/bin/loopover-mcp.js, src/mcp/server.ts, and whatever shared module (if any) the decision below implies — likely @loopover/engine if a real shared-core path is chosen, given that's already the established convergence point for ORB/AMS logic (see this session's separate de-duplication epic, #6202).

Proposal (open questions a design pass needs to answer — not yet decided)

• Is duplication actually a problem here, or the correct tradeoff? Unlike the src/ ↔ @loopover/engine case (Epic: converge remaining 15 hand-duplicated src/ <-> @loopover/engine files onto thin re-export shims #6202), local and remote MCP serve genuinely different transport models (stdio vs. HTTP/SSE) and are intentionally separately-installable. The right answer may be "keep them separate, just hold tool-list parity" — that's a legitimate outcome of this spec, not a failure to find one.
• If convergence is worth it: what's shareable? Tool handler logic (the actual REST/GraphQL calls each tool makes) is the most promising target — the transport/registration layer (stdio vs. HTTP) is not, and shouldn't be forced together.
• Packaging implication: if handler logic moves to a shared package, does it become a new @loopover/mcp-core (or similar) that both @loopover/mcp and the root src/mcp/server.ts depend on, and does that reintroduce the exact "installing one pulls in the other" concern github-token-resolution.js was written specifically to avoid? If so, is that concern still valid for handler logic (no CLI-installation implication) even though it wasn't for config-file reading?
• Precedent to weigh: @loopover/engine's existing convergence pattern (thin re-export shims) is the proven playbook if a shared-core answer comes back "yes" — reuse it rather than inventing a new pattern.

Deliverables

• A decided answer: converge tool-handler logic onto a shared module, or explicitly keep the two implementations separate (tool-list parity only).
• If converging: a package/module boundary decision and a plan matching @loopover/engine's existing shim pattern.
• If not converging: a written rationale (this issue's own body, updated) so a future contributor doesn't re-raise the same question without context.

Resources

• packages/loopover-mcp/bin/loopover-mcp.js, src/mcp/server.ts
• packages/loopover-miner/lib/github-token-resolution.js (the existing "separately-installable CLIs" rationale)
• #6202 (the @loopover/engine convergence epic and its proven shim pattern, if this spec decides to reuse it)

Boundaries

• maintainer-only — this is a packaging/architecture decision with real distribution implications (what a contributor installs, and what installing one thing pulls in), not mechanical engineering.
• Whatever is decided must not break @loopover/mcp's standalone installability (a user should still be able to npm install -g @loopover/mcp without pulling in @loopover/miner or the full server).

[linear-code]

JSO-4315