Authorizing an MCP Client with OAuth

When you add Funnelfeedr to an MCP client, the client cannot simply start reading your data. It first has to be authorized by you. This happens through OAuth, the same kind of "Allow access" flow you know from connecting apps to Google or Microsoft.

This guide explains what happens during that flow, what the Funnelfeedr approval screen shows, and how to make the right decision on it.

The flow in five steps

You add the server in your client. You paste https://mcp.funnelfeedr.com/mcp into your MCP client and click Connect (or the client's equivalent).
Your browser opens Funnelfeedr. The client sends you to app.funnelfeedr.com. If you are not already signed in, you sign in first. Your original request is kept, so you land on the approval screen after signing in.
You review the approval screen. It shows which application is asking, what it wants to do, and which Funnelfeedr user and account it will act as. If you belong to several accounts, you pick the one to connect to here.
You click Allow access or Cancel.
You are sent back to the client. The client receives a token and the connection is live. You can start asking your assistant about your Funnelfeedr data straight away.

The whole flow usually takes well under a minute. The request itself is valid for 10 minutes. If you leave the approval screen open longer than that, it expires and you need to start again from the client.

Reading the approval screen

Who is asking

The top of the screen identifies the application. There are two cases:

Verified application. The screen shows a shield icon and a host name, for example claude.ai. This means the application identified itself with a public identity document hosted at that address, and Funnelfeedr fetched and validated it. The host is the part that was actually verified. If the application also states a display name, it appears as Calls itself "…" underneath, because that name is chosen by the application and not something Funnelfeedr can check.

Unverified application. The screen shows a warning icon, the heading Unverified application, and a yellow warning box. This means the application registered itself with Funnelfeedr on the spot, without a verifiable identity. Some legitimate clients still work this way. Continue only if you started the connection yourself, moments ago, from a client you trust. If this screen appears and you did not just try to connect something, click Cancel.

What it wants to do

Below the identity is a list of the permissions (scopes) being requested. Funnelfeedr has two:

Scope	What the assistant may do
Read (`mcp:read`)	Read your organizations, contacts, lists, saved searches and knowledge base.
Write (`mcp:write`)	Create lists and add organizations to lists.

Most clients request both. There are no other scopes: an MCP client can never push to your CRM, spend credits, reveal masked contact details, send email or delete data, regardless of what you approve here.

If you have connected this application before, scopes it already holds are marked Already granted. Approving again merges the new scopes with the old ones; it never removes anything.

Connect to account

If you belong to more than one Funnelfeedr account, the screen has a Connect to account picker listing every account you are a member of, starting on the one you are signed into. Whatever you choose here is the account the assistant reads and writes in. With only one account there is no picker, and the account is simply shown.

The choice is not final. You can move the connection later under Settings → MCP Connections, or ask the assistant to do it for you. A connection points at one account at a time, so changing it moves the connection rather than adding a second one.

Connecting as

This line shows the user and account the assistant will act as, for example anna@example.com · Example AB. The assistant gets exactly the access this user has in that account, nothing more. If your Funnelfeedr role does not allow editing leads, the assistant cannot create lists either, even with the Write scope approved.

Sends you back to

The exact address the client gave as its return address. For Claude on the web this is https://claude.ai/api/mcp/auth_callback; for Claude Code it is a localhost address. If this looks unrelated to the client you are using, cancel.

Allow access or Cancel

Allow access creates the connection and returns you to the client.
Cancel tells the client that you declined. Nothing is stored in Funnelfeedr and nothing needs to be cleaned up.

Either way, you can close the browser tab afterwards. Some clients close it for you.

What happens after you approve

The client receives a short-lived access token (valid for 60 minutes) and a refresh token (valid for 30 days). It renews the access token by itself; you will not see this happening.
As long as the client is used at least once every 30 days, the connection stays active without any action from you. After 30 days of inactivity the client will send you through the approval flow again.
The connection appears under Settings → MCP Connections with the application name, the account it uses, the scopes you granted, when it was created and when it was last used.

Revoking access

You can revoke any connection at any time under Settings → MCP Connections. The client's refresh tokens die at once, and an assistant that is mid-conversation loses access within about two minutes, once the server re-checks the connection. Account administrators can also see and revoke every connection in the account. See Managing MCP connections.

Deleting the connector inside the client does not revoke it on the Funnelfeedr side. If you want to be certain the tokens are dead, revoke them in Funnelfeedr.

Security details

For those who want to know exactly what is going on under the hood:

The flow is OAuth 2.1 with PKCE (S256). There is no client secret; the client proves it started the request by presenting a code it generated locally.
Funnelfeedr is both the authorization server (it issues tokens) and the resource server (it accepts them). Tokens are bound to https://mcp.funnelfeedr.com/mcp and are accepted nowhere else.
Clients identify themselves either through a Client ID Metadata Document (a public identity document at an HTTPS address, shown as a verified host) or through Dynamic Client Registration (shown as unverified).
The tokens the client holds identify you. Every tool call is authorized against your role and seats at the moment it happens, and every call is logged. The account a request runs in is read from the stored connection on every request, which is what lets a connection be moved between your accounts without reconnecting — and it is re-read at most every two minutes, which is the outer bound on how long a revoked or moved connection keeps its old access.
Standard discovery documents are published at https://mcp.funnelfeedr.com/.well-known/oauth-protected-resource/mcp and at the authorization server's /.well-known/oauth-authorization-server, so any compliant client can find the endpoints itself.

Common problems

"This connection request has expired or has already been used." More than 10 minutes passed, or you refreshed the page after approving. Start the connection again from the client.

"We could not find this connection request." The link is incomplete or was opened in a different browser than the one that started the flow. Start again from the client.

The approval screen never appears and the client reports an error. Make sure you entered the server address exactly as https://mcp.funnelfeedr.com/mcp, and that nothing on your network (a corporate proxy or a firewall) blocks app.funnelfeedr.com or mcp.funnelfeedr.com.

The assistant says a tool needs a scope that was not granted. Remove the connector in the client and connect again, approving both scopes on the approval screen.

More cases are covered in MCP troubleshooting.