AX-1644 - add jfrog mcp

[yanivt-jfrog]

No description provided.

[YoniMelki]

Review — AX-1644: built-in always-on JFrog MCP (VS Code / Copilot)

The docs and copilot-instructions.md hard-rules are consistent with the Cursor/Claude siblings and read well. My concern is that this is the one client where the bundled launch shape is most likely to actually fail, for two compounding reasons:

1. ${VAR:-default} may not expand in VS Code. VS Code's mcp.json interpolation is ${env:VAR} / ${input:...} — it does not implement bare ${VAR} or bash-style :-default. If so, npx receives the literal ${JFROG_AGENT_GUARD_REPO:-https://...} as --registry and the server never launches. (inline)

2. The agent-guard-hook will reject this entry. The VS Code PreToolUse hook — the governance on-ramp enterprises deploy — reads the raw mcp.json and requires --registry <value> to pass isHttpUrl(value). I verified isHttpUrl("${JFROG_AGENT_GUARD_REPO:-https://...}") is false, so a deployed hook denies every tool call on the built-in jfrog server (or reports server not found if it doesn't scan plugin/.mcp.json). The hook isn't updated to know about the built-in jfrog exception. (inline)

Net: please verify end-to-end in VS Code with the agent-guard-hook installed (the realistic enterprise config) and with JFROG_AGENT_GUARD_REPO unset. The likely fix is to ship a concrete http(s) --registry URL in the bundled config (drop the :-default) and/or coordinate a hook change — see the agent-guard PR where I raised the same point.

Smaller: the troubleshooting entry's "reinstall to restore the entry" advice won't help if the bundled config itself is what the hook rejects. (inline)

Verified OK: README ### JFrog MCP → #authentication cross-ref is valid and that section lists both JFROG_URL (with scheme) and JFROG_ACCESS_TOKEN.

[YoniMelki]

Two compounding problems with this --registry value in the VS Code context:

(a) Expansion. VS Code mcp.json interpolation is ${env:VAR} / ${input:...}; it does not implement bare ${VAR} or bash :-default. If that holds, npx gets the literal ${JFROG_AGENT_GUARD_REPO:-https://...} as the registry and @jfrog/agent-guard fails to resolve, so the server never starts.

(b) Hook rejection. The agent-guard-hook (the VS Code PreToolUse allowlist) reads the raw mcp.json and requires the --registry value to satisfy isHttpUrl(). I confirmed isHttpUrl("${JFROG_AGENT_GUARD_REPO:-https://releases.jfrog.io/...}") returns false, so with the hook deployed every tool call on this jfrog server is denied ('--registry ... is not an http(s) URL'), or 'server not found in mcp.json' if the hook doesn't scan plugin/.mcp.json. The hook has no awareness of a built-in jfrog exception and isn't changed in this PR set.

Suggested fix: ship a concrete http(s) --registry URL here (no :-default), or use ${env:JFROG_AGENT_GUARD_REPO} if VS Code supports a literal fallback, and coordinate the hook update on the agent-guard PR. Please smoke-test in VS Code with the hook installed and JFROG_AGENT_GUARD_REPO unset.

[YoniMelki]

Both sub-points resolved. The --registry value is now the hardcoded https://releases.jfrog.io/artifactory/api/npm/coding-agents-npm/: (a) no ${env:VAR} / ${VAR:-default} interpolation needed, so the VS Code-vs-bash expansion gap is moot; and (b) I verified the new entry passes agent-guard's agent-guard-hook.mjs — validateAgentGuard returns null, whereas the old ${VAR:-...} string returned "not an http(s) URL" and would have denied every tool call on the built-in jfrog. 👍

[YoniMelki]

This entry attributes a missing built-in jfrog to env vars or "launch shape blocked by an admin policy," and advises reinstalling to restore the entry. If the actual cause is the agent-guard-hook rejecting the ${VAR:-default} --registry value (see my note on .mcp.json), reinstalling restores the same rejected config and won't help. Once the .mcp.json fix lands, consider distinguishing "env vars not exported" (fixable by the user) from "launch shape rejected by the hook" (a config/hook issue, not user-fixable).

[YoniMelki]

Resolved. My original concern was that this entry blamed a missing built-in on env vars / admin policy while the real root cause was the unexpandable ${VAR:-default} registry. Now that the registry is hardcoded, the remaining failure mode genuinely is the env vars — and the rewritten entry reflects that accurately: it points at JFROG_URL/JFROG_ACCESS_TOKEN not being exported, adds the "JFROG_URL must include https://" detail, the fail-fast-at-startup behavior, and the "never edit the bundled .mcp.json" guidance. Good fix. 👍

[YoniMelki]

Re-review — both findings resolved ✅

Re-reviewed at head 939a6137 (was CHANGES_REQUESTED). Both blocking findings are addressed:

1. plugin/.mcp.json registry expansion — now a hardcoded https://releases.jfrog.io/artifactory/api/npm/coding-agents-npm/. This was the sharpest concern for VS Code specifically (its mcp.json interpolation is ${env:VAR} / ${input:...} and does not honor bash-style ${VAR:-default}). With the literal URL, that gap is moot, and I verified the entry passes agent-guard's agent-guard-hook.mjs (validateAgentGuard → null; the old ${VAR:-default} form returned "not an http(s) URL" → would have denied every tool call). ✅
2. copilot-instructions.md troubleshooting entry — rewritten. Previously it attributed a missing built-in to env vars / admin policy while the real root cause was the unexpandable registry. Now that the registry is hardcoded, the remaining failure mode genuinely is the env vars, and the entry is accurate: it names JFROG_URL/JFROG_ACCESS_TOKEN, requires the https:// scheme, notes fail-fast-at-startup + the MCP: List Servers failure indication, and tells the user not to edit the bundled .mcp.json. ✅

marketplace.json bumped 1.0.3 → 1.0.4; JFROG_URL documented with scheme; no JFROG_PLATFORM_URL rename concern here (none existed). New "JFrog MCP" README section and copilot-instructions hard-rules are consistent with the cursor/claude plugins.

Switching to APPROVE.