nordnet-mcp

Read-only MCP server for Nordnet portfolio data.

It exposes Nordnet accounts, positions, trades, balances, and instrument lookup/search to MCP-compatible clients such as Claude Code, Claude Desktop, and Cursor.

Important:

• This project is unofficial and is not affiliated with, endorsed by, or supported by Nordnet.
• It uses your existing Nordnet session, established either via QR login (below) or a browser session token.
• Nordnet sessions are short-lived (a couple of hours) if left idle — but the server keeps its session alive on its own for as long as it keeps running (see Status).
• Never commit your token or share your .env file.

Status

The server can now log itself in: call the nordnet_auth tool (or just try any Nordnet tool — a 401 tells the model to call it) and a QR code appears in the conversation. Scan it with the Nordnet mobile app and the session is established automatically — no browser DevTools, no copy-pasting a cookie. NORDNET_HOST must match the market your Nordnet app is registered in (e.g. public.nordnet.no for a Norwegian account): the QR encodes a login link on that market’s domain, and an app from another market silently ignores the scan. In MCP Apps-capable hosts this renders as a live QR image that rotates itself every 100 seconds (up to 3 codes / 5 minutes) if you haven’t scanned it yet, and once approved it disappears and sends a follow-up message so you don’t have to retype what you originally asked. Whether that finishes the loop entirely or just saves you the retyping depends on the host: some submit it immediately, others (observed: Claude Desktop) pre-fill it in the composer and leave sending it to you — in the latter case, a single Enter is all that’s left. On hosts without MCP Apps support (e.g. Claude Code), the QR is shown as ASCII art text instead of an image, and there’s no automatic polling — once you tell the model you’ve scanned and approved it, it calls nordnet_login_poll itself to finish the login.

A session obtained this way is kept in memory only — applied to the running server immediately, but never written to .env or anywhere else on disk. If the server process restarts for any reason, the token is gone and you’ll need to log in again; writing it back to .env would avoid that, but at a security cost (a bearer token sitting in a plaintext file) that isn’t worth it unless this turns out to be too disruptive in practice — that’s the tradeoff to revisit if so. If the App view itself gets re-mounted (e.g. reopening a conversation you’d already authenticated in), a QR is never shown for a session that’s still good — this is checked twice, both live against Nordnet (not just “is a token string present,” since a present-but-dead token shouldn’t count): once server-side, before nordnet_auth would otherwise generate a new order, and once again in the view itself before it ever displays whatever content it was handed, since that content could be a stale replay of