Authentication

The public Lovelace 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

That metadata identifies:

• the protected resource: https://mcp.uselovelace.com/mcp
• the authorization server: Lovelace Accounts
• the supported scopes for the Lovelace 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.

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 Lovelace MCP endpoint as the protected resource

Local development

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

See Local Server for the local setup.