feat(mcp): JFrog Platform remote MCP (token auth) + install hint

[michaelfrog]

Summary

Adds the JFrog Platform remote MCP to the OpenCode plugin (token auth, headless), on top of the skills work (#16). When JFROG_URL + JFROG_ACCESS_TOKEN are set, the plugin registers config.mcp.jfrog so the JFrog platform tools appear in OpenCode alongside the skills.

What changed

• Remote MCP injection in the config hook: config.mcp.jfrog → remote https://<host>/mcp, oauth:false, Authorization: Bearer <token>. Env-gated (host and token required), host precedence JFROG_URL → JF_URL → JFROG_PLATFORM_URL + scheme/trailing-slash normalization, idempotent (never clobbers a user-defined jfrog), JFROG_MCP_DISABLE opt-out. No network on load.
• Token handling: OpenCode does not expand {env:…} in config a plugin injects at runtime, so the plugin reads the token from the environment and sets the resolved Bearer <token> header directly. The token lives in the in-memory session config (sourced from env); the plugin never writes it to disk. Prefer a short-lived jf atc token.
• Install-jf hint: a tool.execute.before hook nudges once/session to install the CLI when jf is missing and a jf command runs. MCP setup problems (missing env, non-JWT token, 401) are surfaced by OpenCode's own mcp list/TUI + the README — a WARNING line is logged (debug) for a non-JWT token.
• Functional refactor + tests: pure helpers (resolveMcpCredentials, mcpServerEntry, commandExists, looksLikeJwt); unit tests for registration, gating, idempotency, host/token precedence + normalization, reference-token-still-registers, and the install hint.
• README: JFrog Platform MCP section — prerequisites (JWT not reference token), token handling, context cost, opt-out, and 401 troubleshooting.

Verification

• lint / typecheck / test (26 pass) / build green; sync-skills:check + pack:check pass.
• Manual: with a JWT → opencode mcp list shows ✓ jfrog connected + jfrog_* tools; reference token → 401 (surfaced by OpenCode) + debug WARNING; no env → not registered; JFROG_MCP_DISABLE=true → not registered.

Notes

• The JFrog MCP exposes 56 tools (+32K tokens/request; OpenCode has no lazy tool loading). Enabled by default for parity with the Cursor/Claude plugins; opt out with JFROG_MCP_DISABLE=true or scope via tools globbing.
• Squash-merge recommended.

[YoniMelki]

4 findings, 2 confirmed bugs + 2 design issues:

• Windows commandExists (line 53): split(':') hardcodes Unix PATH separator; .exe/.cmd extension not probed. hasJfCli is always false on Windows.
• Silent http://→https:// upgrade (line 97): normalizeHost strips scheme, mcpServerEntry hardcodes https://. On-prem HTTP instances get a broken MCP URL with no warning.
• No dedup guard on error toast (line 115): The nudgeShown guard was removed with the info toast, but the broken-package error toast has no equivalent — it fires on every config call.
• registerMcp skipped when skills broken (line 196): Two independent features are coupled; a missing skills/ dir silently prevents MCP registration.

[YoniMelki]

Bug: Windows PATH separator

split(':') hardcodes the Unix separator. On Windows PATH uses ;, so the entire path string is treated as one token and accessSync always fails — hasJfCli is always false, and the install-hint toast fires on every jf command even when jf.exe is installed.

Also: even with the correct separator, Windows executables are named jf.exe, so accessSync(join(dir, 'jf'), X_OK) won't find them.

// fix
import { delimiter } from 'path';

(process.env.PATH ?? '').split(delimiter).some((dir) => {
  if (!dir) return false;
  const names = process.platform === 'win32' ? [cmd + '.exe', cmd + '.cmd'] : [cmd];
  return names.some((name) => {
    try { accessSync(join(dir, name), constants.X_OK); return true; }
    catch { return false; }
  });
});

[michaelfrog]

Fixed in c38990f — commandExists now splits on path.delimiter (not a hardcoded :) and probes .exe/.cmd/.bat on Windows, so hasJfCli resolves correctly cross-platform.

[YoniMelki]

Bug: http:// scheme silently upgraded to https://

normalizeHost strips the scheme unconditionally, and mcpServerEntry always prepends https://. A user with JFROG_URL=http://internal.corp gets url: 'https://internal.corp/mcp' — a TLS handshake failure against an HTTP-only server, with no log or toast explaining the mismatch.

Fix: either preserve the original scheme through resolveMcpCredentials and pass it to mcpServerEntry, or reject http:// URLs early with an error toast saying HTTPS is required.

[michaelfrog]

Fixed in c38990f — replaced normalizeHost with toBaseUrl, which preserves an explicit http:///https://, defaults to https:// only when no scheme is given, and strips trailing slashes. Added unit tests covering both the http-preserved and https-default cases.

[YoniMelki]

Bug: error toast has no dedup guard

The old nudgeShown flag prevented repeated toasts across multiple config calls. That guard was removed with the info toast, but the error toast here has no equivalent. OpenCode calls the config hook multiple times per session (that's exactly why nudgeShown existed), so a broken install spams this toast on every call.

Add a module-level flag (e.g. let errorShown = false) and short-circuit here — same pattern as installHintShown.

[michaelfrog]

Fixed in c38990f — added a module-level skillsErrorShown guard so the broken-package error logs and toasts at most once per session, even though the config hook runs multiple times.

[YoniMelki]

Design: registerMcp silently skipped when skills are broken

Skills and MCP are independent features — a missing skills/ dir (broken package layout) shouldn't disable token-auth MCP registration. A user with valid JFROG_URL + JFROG_ACCESS_TOKEN and a partially corrupted install loses both features, but only sees the skills error.

// current — MCP never runs if skills are broken
if (!registerSkills(cfg, log, toast)) {
  return;
}
registerMcp(cfg, log);

// suggested — run both regardless
registerSkills(cfg, log, toast);
registerMcp(cfg, log);

[michaelfrog]

Fixed in c38990f — the config hook now calls registerSkills(...) and registerMcp(...) unconditionally instead of early-returning on a skills failure, so token-auth MCP registration is no longer coupled to the skills dir being present.