fix: use gateway-supplied MCP endpoint URL instead of window.location.origin

[marekdano]

Fixes IBM/mcp-context-forge#6632

Depends on IBM/mcp-context-forge#6656 — please don't merge this before that backend PR lands. VirtualServer.url only exists in gateway responses once #6656 ships; until then this PR is a no-op and silently keeps today's window.location.origin fallback behavior.

Summary

Flagged in review on #101:

getVirtualServerEndpoint (src/components/gateways/utils.ts:21-27) still builds the virtual server's MCP endpoint as ${window.location.origin}/servers/{id}/mcp, the same assumption about who owns the origin that this PR removes from redirect_uri. The BFF proxies only /api/*, so that URL hits the SPA fallback and returns index.html with a 200.

Same class of bug as the OAuth redirect_uri fix in #101: the web UI's own origin isn't necessarily where the gateway serves its endpoints in a split deployment. IBM/mcp-context-forge#6656 adds a url field to ServerRead, computed server-side from the gateway's own APP_DOMAIN (the same base URL OAuth's redirect_uri default already uses). This PR switches the frontend to use it.

Changes

• src/types/server.ts: add url?: string to VirtualServer.
• src/components/gateways/utils.ts: getVirtualServerEndpoint now takes the server object and prefers server.url over constructing from window.location.origin, which remains only as a fallback for gateways older than the url field.
• src/components/gateways/VirtualServerDetailsPanel.tsx: updated the one call site.
• Tests: utils.test.ts covers the url-preferred path and both fallback cases.

[vishu-bh]

LGTM 🚀

[a-effort]

Reviewed the diff. No blockers.

getVirtualServerEndpoint now takes a Pick<VirtualServer, 'id' | 'url'> instead of a bare string and returns server.url directly when present. The fallback to window.location.origin is preserved. The type addition on VirtualServer is optional (url?: string), which is correct since the field only exists on gateways after the corresponding backend PR lands.

One thing to track: the PR description says this is a no-op until IBM/mcp-context-forge#6656 ships and the url field appears in gateway responses. That means the fallback path (window.location.origin) is the only one exercised in any deployed environment right now. Once the backend PR lands, it would be worth a follow-up to confirm the url value in real responses matches the expected format — the tests cover the happy path with a hardcoded value but not the actual shape the backend will emit.

[a-effort]

Approved 🚀

Non-blocking LLM review feedback:

The function returns server.url verbatim, which is correct given the backend contract, but that contract (url already includes the /mcp suffix) is implicit. If the backend PR ships the field without that suffix the caller breaks silently. Worth confirming the API contract is locked before merging.

VirtualServer.url and MCPServer.url now coexist with different semantics (MCP endpoint vs transport URL). The JSDoc on VirtualServer.url covers it, but flag this for backend reviewers so the field naming is intentional on their side too.

Otherwise the change is correct: the function prefers the server-supplied url, retains encodeURIComponent in the fallback, all three branches are tested, and the one call site is updated.

[gcgoncalves]

Approving with an optional nit.

[gcgoncalves]

NIT: This coment here is annoying more than helping. Would you consider cutting it?