A remote MCP server with OAuth 2.1, not an API key in a config file
How the hosted 1Lookup MCP server authenticates a client: discovery, dynamic client registration, PKCE, and scoped tokens that expire on their own. Everything on this page is what the server does, not what the spec allows.
https://app.1lookup.io/api/mcpWhat happens when a client connects
You paste a URL. These five things happen behind it, and none of them involve an API key.
- 01
Discovery
The client fetches the protected resource document, which names the authorization server, then fetches the authorization server document for the authorize, token, and registration endpoints. Both are public, return JSON, and cache for one hour.
- 02
Dynamic client registration
The client registers itself at /api/mcp/oauth/register under RFC 7591. There is no app to create by hand and no client secret is issued, because the client is public. Redirect URIs must be https, or http on localhost, 127.0.0.1, or [::1], and they are recorded before any redirect happens.
- 03
Authorization with PKCE
The browser lands on the 1Lookup consent screen. PKCE with S256 is required, not optional: a request without a code challenge, or with any other method, is rejected. A redirect URI that was not registered for that client is never redirected to.
- 04
Code exchange
The authorization code is single-use and lives 60 seconds. It is bound to the client ID and the exact redirect URI it was issued for, and the PKCE verifier is checked before the code is spent, so an intercepted code cannot be burned to block the real client.
- 05
Calling tools
The access token is audience-bound to https://app.1lookup.io/api/mcp, so a token minted for this endpoint is not accepted elsewhere. Refresh tokens rotate on every use: the replacement is recorded before the presented token is consumed.
Discovery documents
Both are public and need no credentials, so a client can work out how to authenticate before it has any.
Protected resource metadata (RFC 9728)
https://app.1lookup.io/.well-known/oauth-protected-resourceNames the authorization server that protects the MCP endpoint. The endpoint's WWW-Authenticate challenge points here.
Authorization server metadata (RFC 8414)
https://app.1lookup.io/.well-known/oauth-authorization-serverPublishes the authorize, token, and registration endpoints, the supported grants, and the S256 code challenge method.
Nothing here is long-lived
Tokens are scoped to a single lookup scope and expire on their own. Access tokens last one hour and refresh tokens last thirty days, so a connection that stops being used stops working without any action from you.
| credential | lifetime | note |
|---|---|---|
| Authorization code | 60 seconds | Single use |
| Access token | 1 hour | Audience-bound to the MCP endpoint |
| Refresh token | 30 days | Rotates on every use |
| Registered client | 90 days | Registered dynamically, no manual setup |
Transport, scope, and limits
The three things a client author needs to know before writing any code against the endpoint.
Streamable HTTP, SSE disabled
The transport is streamable HTTP at /api/mcp. SSE is turned off, so any client that supports remote MCP over streamable HTTP can connect, and a client that only speaks SSE cannot.
One scope: lookup
The server publishes a single lookup scope, and that scope is what grants the five tools. A token that does not carry it is rejected at the API boundary as well as at the endpoint.
Same gate as an API key
Tool calls run under the same rate limit and the same paid-plan gate as an API key. A free-plan account receives HTTP 403 UPGRADE_REQUIRED on every tool call.
Running it safely
Treat MCP tools like any other tool your agent can call: enable human confirmation for actions that spend credits, and be careful running 1Lookup alongside untrusted MCP servers.
Questions people actually ask
Token lifetimes, transport, discovery, and why there is no API key in the flow.
Why OAuth instead of an API key in a config file?
An API key in a config file is a long-lived secret sitting in plain text, and it has to be copied into every client that needs it. With OAuth 2.1 the client registers itself, you approve the connection in a browser, and the client holds a scoped token that expires on its own. Your 1Lookup API key is never involved.
How long do 1Lookup MCP tokens last?
Authorization codes are single-use and live 60 seconds. Access tokens last one hour. Refresh tokens last thirty days and rotate on every use, so a presented refresh token is spent the moment it is exchanged. A dynamically registered client is remembered for 90 days.
Does the 1Lookup MCP server support SSE?
No. The transport is streamable HTTP and SSE is disabled, so any client that supports remote MCP over streamable HTTP can connect and a client that only speaks SSE cannot.
Where are the OAuth discovery documents?
Protected resource metadata (RFC 9728) is at https://app.1lookup.io/.well-known/oauth-protected-resource and authorization server metadata (RFC 8414) is at https://app.1lookup.io/.well-known/oauth-authorization-server. Both are public, return JSON, and cache for one hour.
One URL, no key to manage
The endpoint is the whole integration. Add it in Claude or Cursor, approve the connection once, and the client handles registration, PKCE, and refresh on its own.
https://app.1lookup.io/api/mcpProgrammatic access is a paid feature. A 7-day trial is available.