Glossary
Remote MCP Server
A Model Context Protocol server reached at a URL rather than launched on your machine. It needs an identity model, sessions and abuse controls in exchange for working from any assistant with nothing to install.
General definition
A Remote MCP Server is a Model Context Protocol server that runs as a service at a URL and is reached over HTTP, instead of being launched on the user’s machine as a subprocess over stdio. The client posts JSON-RPC messages to a single endpoint, for example https://mcp.example.com/mcp, using the Streamable HTTP transport, and the server holds many concurrent sessions from many users. This is what makes a server usable from web assistants, hosted agents and any client that cannot run local processes, and it is what a connector points at.
Because the server is shared and public, it needs things a local server does not:
- An identity model. The MCP authorization spec uses OAuth 2.1 with PKCE, dynamic client registration (RFC 7591), authorization server metadata (RFC 8414) and protected resource metadata (RFC 9728): an unauthenticated request gets a 401 with a
WWW-Authenticateheader pointing at the metadata, the client finds the authorization server, registers itself, sends the user through login and returns with a Bearer token. Simpler deployments accept an API key in a header, and connectors that take a URL but no headers get the key in the path. - Sessions. The server may issue an
Mcp-Session-Idat initialisation; the client echoes it on every request, and state held for one session is never visible to another. - Discovery. A well-known document that tells clients and crawlers the endpoint, transport and auth options.
- Abuse controls. Rate limits, scope checks per tool and confirmation of destructive tools, because a public URL will be found by bots within days.
Pros: nothing to install, one deployment serves every user and client, it works from Claude, ChatGPT and browser-based agents, and upgrades happen in one place. Cons: you own hosting, TLS, uptime and authentication, and a bug or a leaked key affects everyone at once. Stdio remains the right choice for local development, CI and single-user tools where credentials can simply live in environment variables. The two are not exclusive; many servers ship both from the same code.
In the Ethora ecosystem
The Ethora MCP server is hosted at https://mcp.chat.ethora.com/mcp with three entry points: the open endpoint (identify inside the session with ethora-user-login or ethora-user-register, or send a Bearer token on every request), a personal URL with the API key in the path for connectors that cannot set headers, and /mcp/oauth for OAuth 2.1 with read, write and admin scopes, dynamic client registration and RFC 9728 metadata. An agent with no account can connect with no credentials, register, and receive an API key in one call. Each session keeps private in-memory state and the server never logs request URLs. See the MCP server page and authentication.
The same server ships with the Ethora monoserver deploy: enable the MCP service and it is served at mcp.<your domain>/mcp with identical tools and OAuth, so on a dedicated or self-hosted install agent traffic never leaves the customer’s infrastructure. That matters for healthcare and finance buyers who want assistants to build and manage rooms without a third party in the path. The stdio package on npm remains available for local work.