Abstract The Model Context Protocol (MCP), introduced by Anthropic in late 2024 and now an open standard, defines a uniform interface for connecting large language model hosts to external tools and resources. The published academic literature on MCP to date consists of ecosystem surveys, security taxonomies, and empirical maintainability studies of public MCP servers. In every published deployment, an MCP server is assumed to serve a single product owned by a single vendor. This paper presents the first multi-tenant hosting architecture for MCP, extended from the v1. 0 conference preprint with three architectural contributions that emerged from the v1. 2 reference deployment. One OAuth 2. 1 authorisation server and one Streamable HTTP load balancer drive N independently developed product backends behind a single connector entry on each AI marketplace. Adding the (N+1) -th product is a registry-file edit and a backend folder; the platform code does not change. Cross-tenant non-interference is enforced at the load-balancer layer by the conjunction of two claims on every issued JWT: an aud claim (RFC 8707) and a productᵢd claim. We further show that: The platform implements federated identity with isolated domain data on a unified billing substrate — a multi-tenancy pattern distinct from both row-level tenancy (Salesforce-style) and per-tenant database isolation (Atlassian-style), with one shared platform database holding identity / subscription / billing / audit, and N per-product domain databases that the platform database never cross-joins with. The same authorisation pipeline serves two channels simultaneously: an AI-marketplace channel (/mcp/) for Claude, ChatGPT, and Mistral connectors, and a REST channel (/api//*) for web and mobile frontends, sharing one JWT, one user pool, and one billing ledger. The SEP-1865 ui: // resource type can be used not merely for hand-coded tool-result widgets but as a generic distribution surface for (a) entire pre-existing single-page web applications and (b) auto-generated HTML produced server-side from arbitrary REST API responses by JSON-shape detection, with streaming partial-result delivery to the host iframe via ontoolinputpartial. The same cross-tenant non-interference argument extends, in the presence of the MCP 2026-07-28 Release Candidate's Multi Round-Trip Requests primitive (SEP-2322), to cryptographically-bound requestState blobs that survive the round-trip from server to client to server without becoming a side channel for cross-tenant leakage. The load balancer's HMAC-bound encoding pins every issued requestState to (userᵢd, productᵢd, jti) and rejects on any mismatch before the request reaches a backend. The same architecture, in the presence of the 2026-07-28 RC's HTTP Header Standardization (SEP-2243), exposes a three-way tenant binding — URL path segment, JWT productᵢd claim, and Mcp-Param-ProductId header must all agree, with any disagreement rejected at the load balancer with the standard -32001 HeaderMismatch error code and a distinct audit event type. We describe the architecture, formalise the cross-tenant non-interference property, characterise the requirements on hosted view bundles, document the dual-channel authorisation pipeline, present the UniConnector engine as a worked instance of auto-generated UI distribution, describe the cryptographic requestState binding pipeline that extends the gate model from five gates to six, and report deployment experience from a working three-product instance running behind a single Cloudflare tunnel on commodity Windows 11 hardware. We additionally report convergence with the MCP 2026-07-28 Release Candidate (locked 21 May 2026, Final 28 July 2026), identifying which of the v2. 0 contributions are validated by the RC, which require adaptation, and which are new. The paper is self-contained at the algorithmic level: the load-bearing algorithms for C8 and C9 are presented as language-neutral pseudocode in §11, sufficient for independent re-implementation in any reasonable host language.
Arindam Chakraborty (Mon,) studied this question.