Feedjoltdocs
DevelopersMCP

MCP OAuth

Connect Feedjolt MCP with a URL and no API key. How consent works, why the redirect hostname matters, scopes, step-up for delete, and how to revoke connected apps.

Add the server URL. 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):

{
  "mcpServers": {
    "feedjolt": {
      "url": "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.

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.

ScopeCovers
readList, get, and search.
writeCreate, update, move, assign, reorder, publish.
deletePermanent removal. Unchecked by default.

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.

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.

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.

Connected apps

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

Revoke kills the refresh-token family immediately. The next request from that agent fails. You can approve it again later.

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.

On this page