enhancement: simplify MCP auth to a single /mcp endpoint with optional api_key query parameter

[electather]

Summary

Simplify MCP authentication and endpoint exposure by removing the custom multi-tenant path-based implementation and moving toward a single public MCP endpoint:

• /mcp

As an incremental step toward future OAuth support, remove the current multi-tenant mode and add support for passing the Seerr API key via an api_key query parameter in addition to the existing header-based mechanism.

The API key must be present in at least one location:

• request header, or
• api_key query parameter

Motivation

The current MCP security surface has diverged into multiple custom mechanisms:

• standard MCP endpoint at /mcp
• route-token path prefix support
• custom multi-tenant routing via /{seerr-api-token}/mcp

This increases implementation complexity, test surface, documentation burden, and the chance of configuration mistakes.

Short term, we can simplify this by removing the custom multi-tenant flow and keeping a single MCP endpoint, while still allowing clients that cannot easily set headers to pass the Seerr API key as a query parameter.

Long term, the preferred direction is OAuth-based user login, rather than custom tenant routing.

Scope

In scope

• Remove the custom multi-tenant MCP mode
  • remove --multi-tenant
  • remove tenantRoutingHandler
  • remove path-based /{token}/mcp routing
• Keep MCP served from a single endpoint:
  • /mcp
• Add a new flag to allow the Seerr API key to be accepted from the query string as:
  • ?api_key=...
• Require that the Seerr API key be present in at least one supported location
  • header and/or query parameter
• Update docs, examples, config schema, and tests accordingly

Out of scope

• Full OAuth implementation
• Per-user login/session management
• Broader auth redesign beyond the MCP API key transport simplification

Suggested behaviour

Endpoint shape

Only expose:

• /mcp

Authentication / API key input

Support at least these inputs:

• header-based API key transport
• optional query parameter transport via api_key

If both are present, the implementation should define and document precedence explicitly.

If neither is present, the request should fail clearly.

Design notes

A few implementation details the team should decide explicitly:

• final flag name for enabling query param support
  • example: --allow-api-key-query-param
• whether query param support is opt-in or on by default
• precedence when both header and query param are present
• whether query parameter support should be logged/redacted specially

Affected areas

Likely files include:

• cmd/mcp/serve.go
• cmd/mcp/mcp.go
• cmd/mcp/flags.go
• cmd/mcp/logger.go
• tests/mcp_serve_test.go
• README.md
• seerr-cli.schema.json

Acceptance criteria

• --multi-tenant is removed
• custom path-based tenant routing is removed
• MCP is served only from /mcp
• a new flag exists for query-parameter API key support
• requests may provide the API key via header or api_key query parameter
• requests fail when neither location provides an API key
• sensitive values are redacted from logs
• docs and examples are updated
• tests cover:
  • header-only API key
  • query-param-only API key
  • both present
  • neither present
  • removed multi-tenant mode

Migration notes

This is a breaking change for anyone currently using:

• --multi-tenant
• /{token}/mcp style endpoints

The issue should include a short migration note in the docs describing how to move those clients to /mcp with either:

• header-based API key transport, or
• ?api_key=... transport

Future follow-up

Once this simplification lands, a later issue can introduce OAuth-based authentication for separate user login flows.