A SaaS issue tracker wants to offer one MCP endpoint that any customer's MCP client can connect to, even clients the vendor has never seen before. Which design fits?
Select an answer to reveal the explanation.
Short Explanation
You're opening a public front door, so you need a real lock and a way to recognize visitors you've never met. That's OAuth on Streamable HTTP plus metadata documents, and the trap is the old DCR-and-SSE combo the spec now steers you away from.
Full Explanation
A hosted service reaching many customers fits a remote server on Streamable HTTP, a single POST endpoint that serves many clients. Because it is HTTP-based, it should implement MCP authorization: the server acts as an OAuth 2.1 resource server, publishes Protected Resource Metadata pointing to its authorization server, validates that every token was issued for its own audience, and answers missing or invalid tokens with 401. For clients with no prior relationship, the spec recommends Client ID Metadata Documents, where the client's identifier is an HTTPS URL to its own metadata, after pre-registration where available and before Dynamic Client Registration, which is deprecated. A downloadable stdio server shifts installation and secret handling onto every customer and loses per-user authorization. Accepting tokens without an audience check enables confused-deputy and token-reuse attacks that the authorization rules exist to prevent. HTTP+SSE is deprecated, new implementations should not adopt it, and DCR remains only as a fallback for authorization servers without metadata-document support. Exam caveat: authorization is optional in MCP overall, but a multi-tenant SaaS endpoint is exactly where it should be used. Operational check: call the endpoint without a token and confirm a 401 whose header points to protected resource metadata, then confirm the authorization server advertises metadata-document support.