Authentication

MCP clients authorize through browser-based OAuth. People sign in to the first-party app with their approved account.

MCP endpoint and discovery

https://api.getdeeprecall.com/mcp

On the same API origin, clients can discover:

• /.well-known/oauth-protected-resource/mcp — protected resource metadata.
• /.well-known/oauth-authorization-server — authorization server metadata.

Use the exact advertised /mcp resource URL. Development and production are separate services. Do not mix a token or callback setup from one environment with the other.

OAuth flow

Compatible clients use Authorization Code with S256 PKCE. Current client metadata documents and dynamic registration are supported. Let the client perform discovery and registration, open the consent flow, and manage token refresh and revocation.

The browser sign-in and consent step grants access for the user. Registering an OAuth client or installing a plugin does not itself grant memory access. Redirect URIs and the resource binding must match; do not invent values to bypass a client configuration failure.

Scopes

Scope	Operations
memory:read	recall, ask
memory:write	remember, suppressing and permanently deleting through forget

Scope requirements apply when tools are called. A client listing a tool is not evidence that the token can successfully use it.

REST and MCP are separate

The app’s REST API uses a first-party sign-in access token. MCP uses an OAuth access token issued for its resource. They are not interchangeable. Never ask a user to paste a password or browser session token into an MCP configuration.

If an integration needs a REST-only capability, it needs that surface’s supported account authentication and authorization; do not reuse an MCP token as a shortcut.

Connection problems

Check the exact endpoint, supported remote HTTP transport, account approval, client callback configuration, and granted scopes. Start a fresh sign-in flow after correcting setup; authorization codes are single-use.

See troubleshooting.