The changelog is the honest description here: page content retrieval was broken and now works, and personal notebooks were unreachable and now are not. Credential caching is the third fix, and the reason the manual first run matters — skip it and the client launch fails with no obvious cause. The author's warning about write permissions is worth respecting; read-only is the safe configuration.
A fork of an Azure OneNote MCP server, revised to work with personal notebooks rather than organisational ones only. It reads through the Microsoft Graph API, caches the access token on disk so Claude Desktop does not need to re-authenticate on every launch, and was updated to a current MCP SDK version.
- `listNotebooks` — enumerate the notebooks available to the signed-in account
- `getPageContent` — read a page's content, fixed in this fork by implementing a readable stream where the original failed
- Working API calls against personal Microsoft accounts, which requires setting `signInAudience` to `AzureADandPersonalMicrosoftAccount` on the app registration
- Disk caching of the authentication credential, so the token generated once is reused when the client launches the server later
An Azure app registration with Microsoft Graph permissions — `Notes.Read` and `Notes.Read.All` — and a client secret. Supply `AZURE_CLIENT_ID`, `AZURE_CLIENT_SECRET` and `AUTH_CACHE_DIR` in a `.env` file and in the client's `env` block. Node, with `npm install` and a build from a clone. Run the server manually once first so the cached credential exists before the client tries to launch it. Write permissions are optional, and the author warns of a risk of losing notes if you grant them.
One command plus a key — npx -y mcp-server-onenote, then supply credentials