Claude already knowswhat you are working on
Every chat starts the same way: five minutes explaining the project again. Khint keeps that context as a work session on your Mac, and Claude Desktop reads it live over MCP. Ask what you were working on and it answers with your real week.
Not a copy of your work,
the session you are in
An MCP connector that syncs your documents somewhere is a different product. This one exposes the thing that is genuinely missing from a chat: what you are doing right now, compacted into a working state Khint already maintains for its own agents. Claude reads it at the moment you ask, not from an index built last night.
The context is live
get_active_context reads the working state of your current session at the moment Claude calls it. Start a session, work for an hour, and the answer changes with your morning, without a sync or a re-index.
Nothing is pasted
Your tickets, notes and pulled pages are already in the session because your work put them there. Claude reaches them through the connector, so the chat starts where you are rather than where you can be bothered to explain.
It can write back, and you will know
add_session_entry lets Claude file a conclusion into your session so your Khint agents see it next. Every one of those writes raises an OS notification and lands in an audit log: no silent injection into your own memory.
What Claude can read
- list_sessions: enumerate your work sessions
- get_session: fetch one session by id
- get_active_context: the live compacted state of the session you are in
- search_session_entries: search across everything you logged
- All four go through a read-only database handle
What Claude can write
- add_session_entry: append a note to your active session
- Routed through a local loopback server, never straight into the file
- Bearer-token auth, with Host and Origin checks
- 60 writes a minute, an audit log, and an OS notification each time
Two minutes, and one restart
There is nothing to copy. Khint writes Claude Desktop's config file for you and the binary is already inside the app.
Turn Claude Desktop on in Khint's Integrations page
Khint adds itself to claude_desktop_config.json for you. The khint-mcp binary ships inside the app, so there is nothing to install and no path to paste.
Quit Claude Desktop completely, then open it again
Cmd+Q, not just closing the window. Claude loads its connectors at startup, so a running instance will not see Khint until it restarts.
Ask it something only your session knows
"What was I working on in Khint?" Claude calls get_active_context and answers with your real session rather than a guess.
Let it write back when it is useful
Ask Claude to save a conclusion into your session and it lands as an entry your Khint agents will read next. Khint raises a notification each time that happens.
Prefer to wire it by hand, or using a different client? The MCP server page has the manual configuration and the full tool reference.
What it is allowed to do
Handing an AI client a door into your own memory is only reasonable if the door is narrow. This one is.
Reads cannot change anything
The four read tools open the local database through a read-only handle. There is no code path from a read to a write, whatever a chat asks for.
Writes do not touch the database directly
add_session_entry is proxied through a loopback HTTP server inside the running Khint app, on 127.0.0.1 with an OS-assigned port, behind a 256-bit bearer token stored with 0600 permissions.
Every write is visible
An OS notification fires and the write is recorded in an audit log next to the token file. A rate limit of 60 writes a minute caps what a runaway loop can do.
Sessions only
The connector exposes your Khint sessions and nothing else. Not your history, not your agents, not your credentials, and not the tools you connected: if Claude sees a Jira issue, it is because you pulled it into a session yourself.
It never leaves your machine
stdio to the client and loopback HTTP back to the app. Khint's servers are not part of this at any point, and your sessions are never synced to them for any reason.
Off is off
Turning the toggle back off removes Khint from Claude's config. There is no residual process and nothing left listening.
The other integrations
All integrations
Common questions about Claude Desktop and Khint
What does Claude Desktop actually see?
Your Khint work sessions: the list of them, one session by id, the live compacted state of the active one, and a search across their entries. Nothing else. It cannot see your action history, your connected tools, your credentials or your files, and a Jira issue only appears if you pulled it into a session yourself.
Do I need to copy a config file?
No. Flipping the toggle writes claude_desktop_config.json for you, and the khint-mcp binary ships inside the app. The only manual step is restarting Claude Desktop, because it loads connectors at startup. The manual route is documented on the MCP server page if you would rather do it yourself.
Can Claude change my Khint data?
It can append an entry to your active session, and that is the only write. It goes through a local loopback server with bearer-token auth and a 60-per-minute rate limit, raises an OS notification, and is recorded in an audit log. The four read tools use a read-only database handle, so nothing else Claude does can alter anything.
Does any of this go through Khint's servers?
No. The client talks to the binary over stdio, and the binary talks back to the running app over 127.0.0.1. Memory sessions are local-only by design and are never synced to Khint's servers, so there is no copy anywhere for a connector to reach.
Does it work with Claude Code, Cursor or another client?
Yes, with a manual config: any MCP-compatible client can point at the bundled khint-mcp binary and gets the same five tools. Khint writes the config automatically for Claude Desktop and Codex only because those are the two it knows the file format of.
Stop re-explaining your project to a chat
Free with 300 credits a month. No credit card. macOS 13+ or Windows 10 22H2+.