[Naming Discussion v1]: "Gateways" vs "MCP Servers" and "Servers" vs "Virtual Servers"

[gabe-l-hart]

🧭 Type of Feature

Please select the most appropriate category:

• [ ] Enhancement to existing functionality
• [ ] New feature or capability
• [ ] New MCP-compliant server
• [ ] New component or integration
• [ ] Developer tooling or test improvement
• [ ] Packaging, automation and deployment (ex: pypi, docker, quay.io, kubernetes, terraform)
• [x] Other (please describe below)

This issue is intended to host a naming discussion about a possible breaking change before a potential v1 release.

Discussion

Title: Align "Gateways" to "MCP Servers" naming Goal: Establish consistent naming between UI and API (and CLI #1414) Why now:

With the tool maturing towards a v1 release, the inconsistent naming between the UI (MCP Servers / Virtual Servers) and API (gateways / servers) is confusing. If we want to align on one of the two sets of terms, now is the time!

The proposal here is to align naming around the current UI names (MCP Servers / Virtual Servers). These names are more descriptive and intuitive, so users will be able to understand the data model intuitively rather than needing to read documentation or help messages to understand the difference between gateways and servers.

🔗 MCP Standards Check

• [x] Change adheres to current MCP specifications
• [x] No breaking changes to existing MCP-compliant integrations
• [x] If deviations exist, please describe them below:

---

🔄 Alternatives Considered

• We could just leave it as-is!
• We could make the CLI align to the API
• We could make both the CLI and UI align to the API

---

📓 Additional Context

As I'm working towards a client-side CLI in #1414, this naming disparity is particularly obvious. The CLI works directly with the API, but is designed to feel directly compatible with the UI. I've currently built aliases at the command level, but the naming runs deeper into things like the --gateway-id argument to the tools list command.