📌 Discussion: Which Gateway Endpoint Should Be Used Primarily — /rpc vs Virtual Server Path?

[snmanikanta98]

Hi team,
I’d like to open a discussion regarding the recommended primary endpoint usage in Context Forge Gateway, especially when Virtual Servers are introduced.

Background

Currently, the gateway exposes its default endpoint as:
https://:/rpc
However, when Virtual Servers are configured, the endpoint pattern changes to something like:
https:///servers//mcp

This raises a few questions around what should be considered the primary and recommended endpoint for client integrations.

Key Questions

1. Which endpoint should be used as the standard entry point?
   Should client applications always call the default:
   /rpc
   Or should they move to Virtual Server–scoped endpoints:
   /servers//mcp

2. How does request routing flow internally?

When a request is sent to:
https://:/rpc
Does the gateway internally route it to a default server context?
And when using:
https:///servers//mcp
Is the request processed differently (e.g., isolated configuration, policies, routing rules)?

3. What is the intended purpose of Virtual Servers?
   Are Virtual Servers meant for:
   Multi-tenancy separation?
   Multiple environments/domains?
   Routing isolation?
   Future-proofing gateway deployments?
   Or are they optional and only needed for advanced use cases?

4. Best Practice Guidance Needed

From an operational standpoint, we want clarity on:
What endpoint should be exposed externally
What endpoint should backend integrations rely on
Whether /rpc remains supported long-term
Whether Virtual Server endpoints are the preferred future direction

Why This Matters

In production deployments, the choice impacts:
API consumer configuration
Load balancer routing
Observability and logging paths
Multi-team gateway governance
Upgrade/migration planning
Request for Maintainers / Community
Could you please confirm:

✅ Recommended endpoint to use going forward
✅ Expected routing behavior between /rpc and Virtual Server paths
✅ Whether Virtual Servers are the preferred architecture for new deployments

Any documentation pointers or real-world guidance would be really helpful.

Thanks in advance!

[crivetimihai]

Hi @snmanikanta98, great question. If you want a quick default: use virtual server endpoints for tenant-scoped, policy-controlled usage, and /rpc for lower-level direct behavior. I can add a short endpoint-selection note to docs with trade-offs if you can confirm your client pattern (chat app, MCP inspector, load balancer, etc.).

[snmanikanta98]

our client/request pattern is:
Browser → Chat App (Kubernetes) → Ingress (Kubernetes) → MCP Gateway (Kubernetes) → Backend Agent (Kubernetes)
We tested using the virtual server endpoint as recommended, but the behavior is still the same in our DEV/UAT setup.
So it doesn’t seem specific to /rpc vs virtual server routing in our case.

[crivetimihai]

Hi @snmanikanta98, expanding on the earlier guidance with concrete recommendations:

TL;DR: Use virtual server endpoints (/servers/{id}/mcp) for all standard deployments.

Endpoint	Use Case	Auth	RBAC Scoping
/servers/{id}/mcp	Production, multi-tenant, client-facing	Per-server OAuth (RFC 9728)	Team-scoped tool visibility
/rpc	Admin tooling, debugging, direct API calls	Gateway-level JWT	Global (admin) scope

Detailed guidance:

1. /servers/{id}/mcp is the recommended primary endpoint. Each virtual server provides:

   • Isolated tool/resource/prompt sets per server
   • Per-server OAuth configuration and team scoping
   • RFC 9728 metadata discovery (.well-known/oauth-protected-resource/servers/{id}/mcp)
   • Transport negotiation (SSE, streamable HTTP) per MCP spec
   • This is what you expose externally and what MCP clients connect to

2. /rpc is a lower-level JSON-RPC endpoint for:

   • Direct tool invocation without MCP session management
   • Admin/debug use cases
   • It remains supported but is not the intended primary client-facing endpoint

3. Request routing: Both paths eventually invoke the same tool_service.invoke_tool() backend, so tool execution is identical. The difference is in session management, auth model, and transport protocol handling.

4. For new deployments: Always create virtual servers and point clients to /servers/{id}/mcp. Use /rpc only for administrative or programmatic access where MCP session management isn't needed.

For load balancers: Expose /servers/{id}/mcp (and the corresponding /.well-known/ paths) externally. Keep /rpc on an internal network or behind admin authentication.