May 8, 2026 By Evert Van den Bruel

Connect Cursor to Your Knowledge Base with MCP

Cursor knows your codebase. It does not know your decisions.

Last Tuesday you spent an hour weighing Postgres against SQLite. You wrote down why, picked SQLite, moved on. Three weeks later Cursor confidently scaffolds a new feature on Postgres. It cannot read your mind, your Slack, or the note where you settled this.

There is a fix, and it is not "paste the decision into the prompt every time."

What Cursor is good at, and what it forgets

Cursor is excellent inside a file. It autocompletes the function you are writing. It refactors three call sites in one keystroke. It reads open buffers and understands imports.

The weakness shows up between files and between sessions. Cursor has no built-in memory of what you decided last week. It does not know which library you swore off after the migration. It cannot quote the post-mortem. The longer the project, the wider that gap gets, because the volume of decisions grows faster than any single context window.

This is not a Cursor problem to be fixed by Cursor. The model that ships in Cursor next month will be smarter, and it will still not have read your architecture notes. The information has to come in from somewhere.

What MCP fixes here

Model Context Protocol (MCP) is an open standard that lets a model call tools. One of those tools can be your knowledge base. Cursor can search it, read entries from it, and write back to it during a coding session, without leaving the editor. If you want the long version, What is MCP? covers it. I will not relitigate the basics.

The point: connect a knowledge base over MCP and Cursor stops pretending each session starts from zero.

How to connect a remote MCP server to Cursor

Cursor supports two MCP transports. Local stdio servers, the kind that boot via command: npx ..., and remote servers over Streamable HTTP. For a hosted knowledge base, you want the remote variety. No daemon to babysit.

Two ways in:

Click an "Add to Cursor" link. Many MCP servers now ship a deep link on their docs page. Click it, Cursor opens a confirmation dialog with the server URL prefilled, runs the OAuth flow if the server requires one, and you are done.

Edit mcp.json directly. Open Cursor Settings, go to the MCP Tools section, and add a new server. That opens ~/.cursor/mcp.json (global) or .cursor/mcp.json in your repo (project-scoped). Project config wins when both exist, which is the right default for shared team servers.

For a remote MCP server like Hjarni, the entry is short:

{
  "mcpServers": {
    "hjarni": {
      "type": "streamable-http",
      "url": "https://hjarni.com/mcp"
    }
  }
}

Save, reopen the agent panel, and the tools show up. OAuth triggers on first use.

Two gotchas worth knowing before you debug them the hard way:

Cursor caps you at roughly 40 active tools across all servers combined. Past that the agent silently drops some. If you have five large MCP servers connected, prune.
MCP only fires when the agent is the one driving. Tab completion and inline edits do not call tools. Open the agent panel, ask it something.

Cursor's MCP support keeps moving, so check Cursor's MCP documentation before you debug anything that should work.

A real workflow

What this unlocks is not theoretical. Three patterns I run weekly with Hjarni connected to Cursor:

Search a decision mid-edit. I am in app/services/billing.rb, about to add a retry. I ask the Cursor agent: "Search Hjarni for the payment gateway decision and tell me the constraints we agreed on." It calls the search tool, pulls the note, summarizes it inline. I write code that is consistent with the decision instead of rediscovering it from scratch.

Save research as you go. Halfway through a debugging session I will tell the agent: "Save this finding as a note in Hjarni under Engineering > Postmortems. Title it 'Solid Queue stuck job: cause and fix.'" It writes the note, tags it, links it to the related ones. Next time I see the same symptom in a different repo, the answer is one search away.

Generate code that respects the architecture. "Read my Project Conventions and Service Object Patterns notes, then write a new service for X." The output matches the patterns I documented instead of generic patterns the model picked up from someone else's Rails app on the open web.

You will notice none of this changes how you use Cursor. You ask the agent things. The agent calls tools. The tools happen to include your project's accumulated context.

Where this fits in a developer's day

Cursor edits. The knowledge base remembers. The two together replace the workflow most teams settle into by accident: Cursor open in one window, Notion in another, Slack search in a third, last week's PR descriptions in a fourth. You stop being the protocol that shuttles context between them. Most note tools fail at this for the reasons covered in Your Tools Do Too Much: they were built to host meetings, not to be read by an LLM mid-edit.

If you also use Claude or ChatGPT, point them at the same knowledge base over MCP. That is the LLM wiki pattern, hosted instead of local. Same notes from the editor, the chat client, and your phone. The setup mirrors the Claude and ChatGPT walkthroughs. Different client, same MCP server.

Beyond Hjarni

Cursor is happy to talk to any MCP server. GitHub, Linear, Sentry, Postgres, your internal company server, something you wrote yourself this weekend. The pattern in this post is "connect a knowledge base," not "use this specific knowledge base." Hjarni is a fine choice if you do not want to host your own, and it is the one I work on, so I will recommend it on those terms. If you would rather wire up a Markdown vault behind your own MCP server, the protocol does not care. The win is the same: project memory that persists, available where you write code.

If you want a starting structure that Cursor can navigate well, the Knowledge Wiki template gives you sources, decisions, conventions, and AI instructions out of the box. It is the layout I use.

Closing

The setup is ten minutes. One JSON entry, one OAuth click, one note about your stack. The payoff shows up the next time you open Cursor and it remembers that you picked SQLite, and why.

Most of your tools already know too much. Cursor knows too little across sessions. MCP closes the gap. Pick the knowledge base you are willing to keep up with, and let your editor read it.