Authentication

The public MCP Gateway follows the MCP HTTP authorization model

The public MCP gateway at https://mcp.uselovelace.com/mcp is a protected resource. Standards-compliant MCP clients should discover authorization requirements from the gateway itself, then use Lovelace Accounts as the authorization server.

What a client should expect

When a client connects without valid credentials, the gateway responds with a 401 Unauthorized challenge that includes a resource_metadata pointer:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="mcp",
  resource_metadata="https://mcp.uselovelace.com/.well-known/oauth-protected-resource"

The client should then fetch the Protected Resource Metadata document:

https://mcp.uselovelace.com/.well-known/oauth-protected-resource

Clients that derive discovery from the MCP endpoint path can also fetch the path-aware form:

https://mcp.uselovelace.com/.well-known/oauth-protected-resource/mcp

That metadata identifies:

• the protected resource: https://mcp.uselovelace.com/mcp
• the authorization server: Lovelace Accounts
• the supported scopes for the MCP Gateway

After discovery, the client completes the normal OAuth 2.1 authorization flow with the authorization server and sends the resulting bearer token on MCP requests.

Token transport

Authenticated requests use the standard header:

Authorization: Bearer YOUR_ACCESS_TOKEN

The gateway validates the bearer token against Lovelace Accounts and requires an audience/resource indicator for the MCP endpoint itself.

Supported scopes

The canonical public scope surface is:

The gateway also accepts a few older read/write aliases for backward compatibility, but the launch contract above is the one new integrations should request and document.

Client registration and OAuth behavior

The gateway is the protected resource, not the authorization server.

That means:

1. your MCP client discovers auth requirements from the gateway
2. the client talks to Lovelace Accounts for authorization-server metadata, client registration, and user authorization
3. the client sends the resulting access token back to the gateway

If your MCP client already implements the MCP authorization flow, you usually only need to configure the MCP endpoint URL. If your client requires manual OAuth setup, use the authorization server metadata discovered through the PRM document.

Client ID Metadata Documents

For MCP clients that do not already have a Lovelace-issued client registration, the preferred no-prior-relationship path is a Client ID Metadata Document. In that flow, the OAuth client_id is an HTTPS URL that serves client metadata, including the client display name, redirect URIs, and requested scopes.

Lovelace Accounts fetches and validates that document before authorization. Unsafe metadata URLs, private-network targets, non-HTTPS URLs, redirects during metadata fetch, and redirect URIs not listed in the document are rejected before the user can approve access.

During authorization, the consent surface identifies:

• the client name from the metadata document
• the redirect destination that will receive the authorization response
• the scopes requested for MCP Gateway access

The issued access token is resource-bound to the MCP Gateway endpoint requested through the OAuth resource parameter. Dynamic Client Registration remains available for clients that need an explicit registration record, but it is a fallback rather than a prerequisite for standard MCP onboarding.

Security guidance

• Request only the scopes your workflow needs
• Do not log bearer tokens, codes, or secrets
• Store client credentials and tokens in secure storage
• Validate that your client is using the MCP Gateway endpoint as the protected resource

Local development

The local MCP server is a separate path. Local Ada CLI and daemon workflows do not use the public MCP Gateway’s remote OAuth discovery contract.

See Local Server for the local setup.