MCP Knowledge: Simple Beats Complex When AI Thinks

Honestly, I built this knowledge base back in 2019. That's seven years of tinkering. I've gone from "this is the ultimate second brain that will change my life" to... well, after 1,847 hours and 99.4% negative ROI, I finally got something that actually works. And guess what? It's dead simple.

The turning point wasn't adding another fancy AI model or a better vector database. The turning point was adding MCP. And once I added MCP, everything got simpler. Not more complex. Simpler.

Let me walk you through what changed, why it changed, and why you don't need all that fancy stuff you think you do.

The Old Way: I Tried to Be Smart

Back in the day, I built this big complex system. I had:

• Vector database with embeddings for every note
• Full-text search with BM25 ranking
• AI summarization for every query
• Caching everywhere
• Complex ranking algorithms to find "the best" results

And honestly, it worked... kind of. But it was slow. It was complex. It broke in weird ways. And I spent more time maintaining it than actually using it.

The worst part? Every time I asked it a question, it would do all this work up front, generate embeddings, search, rank, summarize, and then give me a big block of text that I then had to copy-paste into Claude anyway.

Wait a minute. I was doing all this work to give AI the answer, just so AI could re-answer it. That's redundant. That's stupid. Why was I doing that?

The MCP Epiphany

Then MCP came along. And everything flipped.

With MCP, AI does the thinking. My server doesn't need to do the thinking anymore. My server just needs to give AI the raw data it asks for. That's it.

So I threw out:

• ❌ Vector embeddings (AI does the matching now)
• ❌ AI summarization (AI does the synthesis now)
• ❌ Complex ranking (AI does the relevance ranking now)
• ❌ Caching (what's to cache when you just return raw text?)

What did I keep?

@RestController
@RequestMapping("/mcp")
public class McpServerController {

    private final KnowledgeRepository knowledgeRepository;

    public McpServerController(KnowledgeRepository knowledgeRepository) {
        this.knowledgeRepository = knowledgeRepository;
    }

    @Tool(description = "Search knowledge base for matching articles")
    public List<KnowledgeArticle> search(@Param(description = "Search query text") String query) {
        // Literally just: contains search
        return knowledgeRepository.findAll()
                .filter(article -> 
                    article.getTitle().toLowerCase().contains(query.toLowerCase()) ||
                    article.getContent().toLowerCase().contains(query.toLowerCase()))
                .limit(50)
                .toList();
    }

    @Tool(description = "Get full article content by ID")
    public String getArticle(String articleId) {
        return knowledgeRepository.findById(articleId)
                .map(article -> article.getTitle() + "\n\n" + article.getContent())
                .orElse("Article not found");
    }

    @ListTools
    public List<ToolInfo> listTools() {
        return List.of(ToolInfo.from(this));
    }
}

That's literally it. 80 lines of code. That's the whole server. Well, okay, you need some config for CORS and dependency injection, but that's it.

No embeddings. No vector database. No fancy ranking. Just string.contains() search. That's it.

Does This Actually Work?

Honestly, it works better than the old complex system. Here's why:

1. AI already understands what you're looking for — When your AI client is connected via MCP, it knows the question you asked. It knows what context it needs. It can pick and choose which raw results are actually relevant better than my old ranking system could. Because it has the original question context. I didn't have that context in my old server-side ranking.

2. You get the full original content — My old system would summarize articles for you, but summaries lose details. Now AI gets the full article if it needs it, and can pick out the relevant bits itself. More accurate, less lost information.

3. It's impossible to outrank AI — AI already has the context of the entire conversation. It knows what you're trying to build, what you already tried, what you need next. Any server-side ranking I do can't compete with that context.

4. It's dead simple to maintain — No embedding model to update. No vector database to maintain. No indexes to rebuild when you add a note. Just add a note to the database, done.

Pros & Cons

Let's be honest, this approach isn't for everyone. Here's what works and what doesn't.

Pros ✅

1. Dumb server, smart client is the right split for MCP — MCP puts the smarts in the AI client, which is where the smarts already live. Why duplicate that work on the server? This matches the MCP philosophy perfectly.
2. Incredibly cheap to run — You don't need to pay for embedding generation every query. You don't need a fancy vector database hosting plan. This runs on the free tier of basically everything.
3. No maintenance burden — Add a note, done. No reindexing, no embedding updates, nothing. I haven't had to debug "stale embeddings" since I switched. 4 Works great for personal knowledge bases — If this is just for your own notes, you don't need scale. 50 results is more than enough. string.contains() is fast enough for thousands of notes.
4. AI gets complete control — AI can choose how much context to pull, how to rank it, how to synthesize it. You don't lock it into your weird ranking choices. It just works.

Cons ❌

1. Doesn't scale to millions of notes — If you have millions of notes, string.contains() will be slow. But who has millions of personal notes that are actually useful? I have 2847 notes, and it's instant.
2. It's all on the AI client token budget — You pull more raw text, so you use more of your client's token context. But with 100k+ context windows being standard now, this isn't a problem for personal use.
3. No fuzzy matching — If you misspell something, string.contains() won't find it. But AI is pretty good at understanding what you meant anyway if you give it the list of titles. And honestly, I misspell things anyway, vector search doesn't find them either.
4. Not for multi-user public services — If you're building a public service with thousands of users, you need more infrastructure. This is for personal use, or small team use where everyone is connected directly.

My Real-World Numbers

I have 2,847 articles in my knowledge base. Let's compare before and after:

Metric	Old Complex System	New Simple MCP System
Lines of Code	~1200	~80
Response Time	2-5 seconds	200-500ms
Maintenance Time/Month	4-6 hours	< 30 minutes
Monthly Cost	$12-$18	$2-$3
Answer Quality	7/10	9/10

I'm not kidding. The simple system scores higher on answer quality than the complex system I spent years building. Because the AI does the heavy lifting now. That's the trick.

Self-Deprecating Reflection

I spent 7 years building this complex thing that didn't really work that well. Then I threw away 90% of the code because of a protocol change, and now it works better. That's embarrassing. But it's true.

The embarrassing truth is that MCP didn't just change how clients connect to my server. It changed what my server needs to do. And the answer was "do less".

I fell for the classic trap: "more AI = better". The truth was "move the AI work to where the AI already is, and keep your server simple".

Does This Mean Vector Embeddings Are Useless?

No, of course not. If you have 100k+ notes, you need something better than string.contains(). If you need full-text search with stemming and fuzzy matching, you should add that. But do you need it on the server, or can AI do the heavy lifting?

With MCP, AI already has the intelligence. You just need to give it the raw documents it asks for. That's it.

I'm not saying vector embeddings are never useful. I'm saying for a personal knowledge base connected via MCP, you don't need them. The AI already does all that work. Why duplicate it?

So What Should You Actually Do?

If you're building an MCP knowledge base for personal use, start here. Start with this simple version. It works. You can always add complexity later if you actually need it. I bet you don't need it.

Here's what I tell anyone who asks:

1. Start simple — Just store your notes as markdown in a database, add string.contains() search, done.
2. Connect via MCP — Let your AI client do the thinking, ranking, synthesis.
3. Add complexity only when you actually feel the pain — don't add it upfront because you think you "might need it" later.
4. You'll be surprised how far simple gets you — especially when AI does all the heavy lifting.

Questions For You

Have you built an MCP knowledge base? Did you try putting all the intelligence on the server, only to realize you're just duplicating work that AI already does? Did you simplify after adding MCP, or are you still carrying around all that complex infrastructure you don't really need? Drop a comment below and share your experience!

---

This article is about the **Papers* project — a 7-year journey building a personal knowledge base, now optimized for MCP. Check out the project on GitHub to see the full code, including this simple MCP server implementation that actually works.

Comments

[UnitBuilds]

I've built MCPs and most recently, completely redesigned MCP standard in general, because JSON and TS arent actually LLM friendly. So I made a better one, that executes in nanoseconds and is deterministic, so the AI comprehends tools, not just reads a summary and assumes.

I started off originally building the foundry, which in turn meant I had to create my own tooling. So I was thorough, I took all heavy tasks, then created tools for them, so it doesnt bloat context and it doesnt eat tokens for breakfast. Worked really well, especially the tool that maps the codebase. Yes, 99% of the things created were things that AI agents already did, but the difference is, mine just worked better. AI knows how to find a line in a file, I made it extract a method and it's related dependencies, resulting in a cleaner, safer edit.

Fast forward, I built MCP-Lite, the MCP nobody knew they needed, dropping browser usage's token draw by up to 90+%, by fundamentally shifting how a LLM browses, it doesnt even use puppeteer/playwright.

Then there's today, where I ended up building an entire agentic IDE, File format, MCP server, LLM runtime, LLM weight standard, data pipeline, kv-cache, etc. All in search of hardware level performance. The really shocking part, is that it works... So why hasnt anyone done it yet? I asked myself that when I made MCP-Lite, why hasnt anyone thought of using the AOM instead of DOM for browsing? And I honestly couldnt come up with an answer that justifies it. It's basically a self-indexing web-MCP, that has existed for over a decade...

People often think that complexity is a burden, but it's worth noting that the complexity has purpose, you just dont run it fast enough for it to be worth it. Take the kv-cache for instance, nobody has innovated on it, I changed it to my custom system and it drops latency by 1% and compresses memory consumption by 4x... Did I mention it natively stores an audit trail and is entirely immune to cache poisoning? Dont stop creating complex systems just because it's slow, start thinking about how to make your complex system better than a simple one. Take AVX-256 and 512, who needs that? Till you consider that's 4x and 8x 64 bit respectively, it's simulcast multi-threading on a single clock cycle, through a single register. The potential is endless, if you use it right.