A self-hosted MCP server for your private notes
A self-hosted MCP server lets Claude, ChatGPT, Cursor and your own agents read your private knowledge without handing it to another company. Here is what that means, when it matters, and what to require of one.
What an MCP server is
The Model Context Protocol (MCP) is the open standard AI assistants use to call tools and read data outside the chat. Claude, ChatGPT, Claude Code, Cursor and many agent frameworks speak it.
An MCP server is the other end: it offers tools such as search or read a file, and the assistant calls them when it needs to. A remote MCP server does this over HTTPS, so any assistant you use can reach it, on any device, with a sign-in.
Hosted or self-hosted
With a hosted MCP service, the vendor runs the server. Your documents are copied to, indexed by or streamed through their infrastructure, and their terms decide what happens to them.
With a self-hosted MCP server, you run it on a machine you control. Assistants connect straight to your server, the content stays there, and it leaves only as the answer to a call made by someone you allowed. Accounts, permissions and logs are in your own database.
For public documentation the difference rarely matters. For a company handbook, client projects, security runbooks or personal notes, it usually does.
Why not give an assistant your Git token
The quickest way to let an assistant read a private repository is to give it a personal access token or connect it to your Git account. That token reaches everything the account reaches — every repository, often with write access — and the git host has no record of which note the assistant read for which person.
A notes server built for this holds one narrow credential per repository, a read-only deploy key, and never gives it to the assistant. People sign in as themselves, see only the repositories assigned to them, and every call is logged.
What to require of a self-hosted MCP server
Whatever you choose, ask for these. Next to each is how Notedigit does it.
- Standard sign-in
- Assistants should connect with the user’s own account, not a shared secret pasted into a config file.
- Notedigit: OAuth 2.1 with discovery and dynamic client registration: Claude and ChatGPT configure themselves, and you approve once.
- Access per person
- Not everyone who uses an assistant should read every document.
- Notedigit: Access per user, per repository, or opened to the whole team when you choose.
- Read-only by design
- A prompt should never be able to edit or delete your source of truth.
- Notedigit: Three tools — search, read_file, list_files. Write tools do not exist.
- A record of every call
- You need to know what an assistant read, for whom, and when.
- Notedigit: Every session and tool call logged with client, user, tool, arguments, status and duration.
- Narrow credentials to Git
- The server’s own access to your repositories should be the minimum it needs.
- Notedigit: A read-only deploy key per repository, generated by the server. Any git host that supports SSH.
- Limits and network rules
- A leaked token or a runaway agent should not be able to drain the server.
- Notedigit: Rate limits per token and IP, and an optional IP allowlist per repository.
- Current content
- Answers should quote the version people agreed on, not a stale copy.
- Notedigit: Repositories are cloned on demand and discarded after 15 idle minutes, so a new session reads the branch as it is.
- A way in for automation
- Agents and scripts can’t click through a browser sign-in.
- Notedigit: Personal access tokens that act as one user, expire after 90 days, and are logged like everyone else.