Since 29 September 2026, QuanticData's MCP server supports OAuth 2.1 sign-in. Add https://api.quanticdata.io/mcp to any MCP client that supports MCP authorization, such as a Claude custom connector, sign in to QuanticData and click Allow access. The 25 hosted tools appear, with no API key to copy and one revocable key per connection.
Until today, connecting an agent to the hosted endpoint meant creating a key on the dashboard and pasting it into a config file or a header field. That still works. OAuth adds the path most people expect from a remote MCP server in 2026: paste a URL, sign in, approve, done.
- Endpoint:
https://api.quanticdata.io/mcp, Streamable HTTP. - Sign-in: OAuth 2.1 as defined by the MCP authorization spec, PKCE S256 required.
- Tokens: 1-hour access tokens, rotating 30-day refresh tokens with reuse detection, bound to the MCP endpoint.
- Disconnect: one click under Connected clients on the dashboard's MCP page. Each connection is its own key, named
MCP · <client name>. - API keys: still accepted on the same endpoint, and still the way the local npm package authenticates.
Who MCP server OAuth is for
OAuth is for anyone who adds remote MCP servers by URL rather than by editing a JSON file. The clearest case is a Claude custom connector: Claude's own help center says that adding one typically goes through an OAuth sign-in, and that the connection runs from Anthropic's cloud, not from your laptop. A client like that has nowhere comfortable to paste a long-lived secret, and it should not need one.
It also suits teams. When a colleague connects their assistant, the connection lands on their account as its own named key, billed to the account balance like any other usage, and it can be cut off without rotating the key your production code depends on.
If you run the web scraping MCP server locally through npx quanticdata-mcp, nothing changes for you: the local package reads QUANTICDATA_API_KEY as before.
Connect in 3 steps
- Add the server URL. In your MCP client, add a remote server with the URL
https://api.quanticdata.io/mcp. In Claude, that is a custom connector. Leave any key or client-secret field empty: the client registers itself. - Sign in and allow access. The client opens the QuanticData sign-in page in your browser. Sign in, then click Allow access.
- Use the tools. The client is connected and lists the hosted tools: search, scrape, map, crawl, batch, seo_audit, the collector, dataset and parser tools, and the proxy tools. Ask it to search or read a page and it calls them on its own.
If your client does not support MCP authorization, it will not see a sign-in page. Use an API key instead, as shown further down: the endpoint and the tools are the same.
What happens behind the sign-in
The sequence is the one the MCP authorization spec describes, so any compliant client can follow it without QuanticData-specific code. Every step is discoverable from the endpoint itself:
| Step | What the client does | Where |
|---|---|---|
| 1. Challenge | Calls the endpoint without credentials and gets 401 | https://api.quanticdata.io/mcp |
| 2. Resource metadata | Reads which authorization server protects the endpoint (RFC 9728) | /.well-known/oauth-protected-resource/mcp on api.quanticdata.io |
| 3. Server metadata | Reads the authorization and token endpoints (RFC 8414) | https://app.quanticdata.io/.well-known/oauth-authorization-server |
| 4. Registration | Registers itself, by Dynamic Client Registration (RFC 7591) or a Client ID Metadata Document | app.quanticdata.io |
| 5. Sign-in and consent | Opens the browser with a PKCE S256 challenge; you sign in and click Allow access | app.quanticdata.io |
| 6. Tokens | Exchanges the code for a 1-hour access token and a 30-day refresh token issued for the MCP endpoint (RFC 8707) | app.quanticdata.io |
After step 6 the client sends the access token on every call and refreshes it on its own. Each refresh rotates the refresh token, so a copied one stops working once it has been used, and presenting a used one again revokes the connection. For how the host, client and server divide that work in general, see how MCP servers work.
One key per connection, and how to disconnect
Each OAuth connection is backed by a dedicated API key on your account, named MCP · <client name>, which you will find on the dashboard's API keys page next to the keys you created yourself, tagged as an MCP connection. The same connections are listed under Connected clients on the dashboard's MCP page. That design has three practical effects:
- You can see every connected client. One row per connection, named after the client that asked for it.
- You disconnect one client without touching the others. Click Disconnect next to it under Connected clients: its key is switched off and the client loses access, while your production keys and other connections keep working. Allow the same client again later and the connection comes back on the same key, not a second one. Deleting the key on the API keys page removes the connection for good.
- Billing does not change. Usage through the connection is billed to your account balance like any key, pay per success: blocked pages and internal retries are not charged.
Security properties of the OAuth flow
| Property | What it protects against |
|---|---|
| PKCE with S256, required | An intercepted authorization code cannot be exchanged by anyone but the client that started the flow |
| 1-hour access tokens | A leaked access token expires within the hour |
| Rotating 30-day refresh tokens with reuse detection | A refresh token works once; if a used one is presented again, the whole connection is revoked |
| Tokens bound to the MCP endpoint (RFC 8707) | A token issued for https://api.quanticdata.io/mcp is not accepted as a credential elsewhere |
| Token never forwarded | The OAuth token stops at the MCP endpoint and is never passed on to other services |
| Explicit consent screen | A client gets access only after you sign in and click Allow access for that client |
The client never sees your QuanticData password: you type it on the QuanticData sign-in page, not in the client.
OAuth or API key: which one to use
Both reach the same tools on the same endpoint and bill the same balance. Pick by how the client is configured:
| OAuth sign-in | API key | |
|---|---|---|
| Setup | Paste the URL, sign in, Allow access | Create a key, paste it into the config |
| Best for | Clients with MCP authorization, such as Claude custom connectors | Config files, CI, scripts, the local npm package |
| Credential lifetime | 1-hour access token, 30-day rotating refresh | Until you delete the key |
| Revoke | Disconnect under Connected clients, on the MCP page | Delete the key |
API keys work on the hosted endpoint exactly as before, in either header:
Authorization: Bearer qd_live_your_key_here
X-Api-Key: qd_live_your_key_here
And the local package keeps its one-line install in Claude Code:
claude mcp add quanticdata \
-e QUANTICDATA_API_KEY=qd_live_your_key_here \
-- npx -y quanticdata-mcp
The MCP server and the REST API are two doors to the same platform; if you are weighing one against the other, read is an MCP server like an API. The full parameter reference is in the API documentation.
The hosted endpoint now always knows who is calling
With OAuth in place, every call to https://api.quanticdata.io/mcp carries either an OAuth token or an API key. A request with neither gets 401, and a client with MCP authorization answers that by opening the sign-in page. For you that means one account, one balance and one list of connected clients, whichever way an agent reaches the tools.
The setting that works for your agent
- Endpoint:
https://api.quanticdata.io/mcp(Streamable HTTP), ornpx -y quanticdata-mcplocally. - Authentication: OAuth 2.1 sign-in from a client with MCP authorization; an API key everywhere else.
- Tools: 25 on the hosted endpoint, from search and scrape to crawl, batch and the collectors, all listed on the MCP server page; the same calls exist as REST in the web data API for AI.
- Billing: your account balance, pay per success, whether the call arrived by OAuth or by key.
- Free tier: $2 of free API usage per month, and failed requests are never billed.
Sources & further reading
- Model Context Protocol specification: Authorization (2025-11-25)
- The OAuth 2.1 Authorization Framework, IETF draft
- RFC 9728: OAuth 2.0 Protected Resource Metadata
- RFC 8414: OAuth 2.0 Authorization Server Metadata
- RFC 7591: OAuth 2.0 Dynamic Client Registration Protocol
- RFC 8707: Resource Indicators for OAuth 2.0
- Get started with custom connectors using remote MCP, Claude Help Center