MCP OAuth

Add one server URL per chat. Approve in the browser. That's the default way in - no fjk_ key in the config.

API keys remain fully supported as a second option. See Setup for both.

Add the server with a URL

In your MCP client (Claude Desktop, Cursor, Windsurf, or anything that speaks Streamable HTTP). Reader chat:

{
  "mcpServers": {
    "feedjolt-reader": {
      "url": "https://api.feedjolt.com/mcp/reader/"
    }
  }
}

Writer chat, a different project:

{
  "mcpServers": {
    "feedjolt-writer": {
      "url": "https://api.feedjolt.com/mcp/writer/"
    }
  }
}

Do not put both in the same mcp.json. Combined https://api.feedjolt.com/mcp/ is legacy. The OAuth resource (and JWT aud) stays https://api.feedjolt.com/mcp.

No Authorization header. No fjk_ string. The client hits the server, gets an OAuth challenge, registers itself, and opens a browser.

What the consent screen shows

You pick a workspace. The token is bound to that one workspace.

You see the redirect hostname in monospace - 127.0.0.1:33418 or cursor.com. That is how you spot a malicious client. If the host is loopback (127.0.0.1, localhost, ::1), Feedjolt adds an extra warning: only approve if you started that app on your machine.

The client name is untrusted text from registration. It is never rendered as HTML. There is no remote logo.

Scopes

Same three as API keys. You choose them on the consent screen.

The screen pre-selects only what the app actually asked for - nothing more. If a client requests read alone, write arrives unticked. delete is never pre-selected, even when the app explicitly requests it.

Reader (/mcp/reader/) is read-only at consent: only read is offered, even if the client asked for write or delete. Writer (/mcp/writer/) and Combined keep the Write and Delete checkboxes.

delete is opt-in because it cannot be undone. A contributor cannot grant delete even if they tick it - the server caps scopes by workspace role and by connector.

See Permissions for the full split.

Step-up for delete

If an agent tries a delete tool without the delete scope, the server refuses and tells the client to ask again with that scope. The agent does not silently gain destructive permission. You get another consent screen, with delete still unchecked unless you opt in.

Membership must be accepted

OAuth consent and token exchange require an accepted workspace membership (accepted_at set). A pending invite — email sent, link not clicked — cannot complete OAuth. The workspace won't appear in the consent picker, and a token issued against a stale session will fail on the next MCP call.

Fix: accept the workspace invite first, then connect the MCP client.

Connected apps

Dashboard → Developers → MCP → Connected apps lists every grant: app name, scopes, last used.

Revoke invalidates the connection’s access and refresh tokens. The next MCP request fails, including requests using an existing session. A request already in progress can finish. You can approve the app again later.

After the grant-state upgrade, clients with older access tokens must reconnect or refresh their token. Existing refresh-token families are migrated; revoked families stay revoked.

Workspace owners and admins can see and revoke. Contributors cannot manage grants.

API keys still work

Nothing about fjk_ keys changed. Put Authorization: Bearer fjk_... in the client config if you want a static credential. OAuth is the default; keys are the labelled alternative, not a deprecation.

Account and permission changes

MCP checks your account and current workspace permissions on every request. Disabling your account, forcing a sign-out, or removing your membership invalidates your OAuth grants. Removing a member and inviting them again does not restore their old connection.

If an admin becomes a contributor, previously granted delete access stops immediately. Permission reductions revoke OAuth grants; reconnect and approve the remaining scopes. A later promotion does not add scopes to an existing token. Reader remains read-only.