Building an MCP-Optimized Knowledge System: How Model Context Protocol Changed My 1,800-Hour Knowledge Management Project

Honestly, I never thought I'd be writing the 68th article about my "advanced" knowledge management system. If you've been following along, you know the drill: I've spent 1,847 hours building something I barely use (0.05% efficiency rate, if you're counting), lost $112,090 on it, and somehow turned complete failure into a weird form of performance art.

But here's the thing — something changed recently. The Model Context Protocol (MCP) dropped into my life, and suddenly that 50-line string.contains() search I ended up with after six refactorings doesn't look so bad anymore. Actually, it looks optimized.

Let me explain.

What Even Is MCP, and Why Should You Care?

If you've been living under a rock like me (building knowledge systems nobody uses), MCP is the Model Context Protocol — it's how AI models talk to tools and external data sources in a standardized way. Before MCP, every AI platform had its own way of doing function calling, tool use, context fetching — you had to rewrite your integration for OpenAI, Anthropic, Claude, everyone.

With MCP? It's one protocol. One way to expose your data. Any MCP-compatible client can connect to your MCP server and get your context.

I know what you're thinking: "Kevin, you spent 1,800 hours building a personal knowledge system that you use 15 minutes a day. Why on earth would you add another layer of complexity?"

Honestly? I asked myself the same question. But then I realized something: I've been thinking about knowledge management wrong this entire time.

The Old Way: I Store It, I Retrieve It (Maybe)

For those new to the disaster that is my knowledge project, let me catch you up on the three-act tragedy:

1. Act I: The AI Utopia (months 1-6) — I thought I'd build an AI that reads everything I save, automatically tags it, summarizes it, and recommends the right article when I need it. Sounds great, right? It was garbage. 0.2% click-through rate on recommendations. Complete waste of time.

2. Act II: The Database Dream (months 6-12) — Okay, AI was too hard. Let's just build a proper structured database with full-text search, indexes, the works. I spent months on this. It worked... sort of. But I still never used it. Because organizing everything perfectly is way more work than just dropping a markdown file in a folder.

3. Act III: The Simple Enlightenment (year 2 onwards) — I deleted 1,950 lines of code and ended up with this:
   

@Service
public class SimpleKnowledgeService implements KnowledgeService {

    @Override
    public List<KnowledgeItem> search(String query) {
        // Yes, this is actually what I ended up with
        return allItems.stream()
            .filter(item -> item.getContent().contains(query.toLowerCase()))
            .limit(20)
            .collect(Collectors.toList());
    }
}

That's it. 20 lines of code. No indexes. No fancy algorithms. Just check if the content contains the query words. And you know what? It's fast enough for 170+ articles. 50ms response time. Done.

But here was the problem: my knowledge system was still just me searching it. What if I want my AI assistant to search it? What if I want Claude to answer questions based on my notes? What if I want GPT-4 to brainstorm with my existing knowledge?

Before MCP, that meant building a custom API, writing custom tool definitions for each platform, maintaining it all... which is exactly how I ended up with 1,800 hours of work in the first place.

Enter MCP: Suddenly My Simple System Is Interoperable

I learned this the hard way: the problem wasn't my 20-line search. The problem was that my knowledge was locked in my little database, walled off from all the AI tools I actually use every day.

MCP changes that. With MCP, I can expose my entire knowledge system as a set of tools that any MCP-compatible AI can use. And it's surprisingly simple.

Here's what that looks like in code. I added an MCP server to my existing Spring Boot app in about an hour:

// MCP Server for Knowledge Base - about 100 lines of code total
@RestController
@RequestMapping("/mcp")
public class MCPServerController {

    private final SimpleKnowledgeService knowledgeService;

    public MCPServerController(SimpleKnowledgeService knowledgeService) {
        this.knowledgeService = knowledgeService;
    }

    // List available tools - MCP requires this
    @PostMapping("/tools/list")
    public McpResponse listTools() {
        return McpResponse.tools(List.of(
            Tool.builder()
                .name("search_knowledge")
                .description("Search my personal knowledge base for articles matching the query")
                .inputSchema(JsonSchema.object()
                    .property("query", JsonSchema.string()
                        .description("Search query keywords"))
                    .required("query")
                    .build())
                .build(),
            Tool.builder()
                .name("get_knowledge_item")
                .description("Get the full content of a specific knowledge item by ID")
                .inputSchema(JsonSchema.object()
                    .property("itemId", JsonSchema.string()
                        .description("The unique ID of the knowledge item"))
                    .required("itemId")
                    .build())
                .build()
        ));
    }

    // Execute a tool call - this is where the magic happens
    @PostMapping("/tools/call")
    public McpResponse callTool(@RequestBody McpCallRequest request) {
        String toolName = request.getName();
        Map<String, Object> args = request.getArguments();

        return switch (toolName) {
            case "search_knowledge" -> {
                String query = (String) args.get("query");
                List<KnowledgeItem> results = knowledgeService.search(query);
                // MCP returns the results in a standardized format
                yield McpResponse.content(results.stream()
                    .map(item -> new TextContent(item.getTitle() + 
                        "\nID: " + item.getId() + 
                        "\nPreview: " + item.getPreview()))
                    .collect(Collectors.toList()));
            }
            case "get_knowledge_item" -> {
                String itemId = (String) args.get("itemId");
                KnowledgeItem item = knowledgeService.findById(itemId);
                yield McpResponse.content(List.of(new TextContent(item.getContent())));
            }
            default -> McpResponse.error("Unknown tool: " + toolName);
        };
    }
}

That's basically it. Add some CORS configuration, deploy it somewhere, and boom — my knowledge base is now an MCP server that any AI can connect to.

The Beauty Is in the Simplicity (Honest Truths)

Okay, let's be real here. I'm not selling you anything. This isn't some "AI changed my life" hype piece. MCP didn't suddenly make my knowledge system useful overnight. But it changed how I use it.

Here's what actually happened:

Before MCP

• I have a question → I need to remember to go search my knowledge base myself → I forget or get lazy → I just ask the AI from scratch → AI doesn't have my personal notes → answers are generic.

After MCP

• I have a question → I'm already talking to my AI assistant (which is MCP-compatible) → AI automatically searches my knowledge base → AI pulls in the relevant notes I wrote years ago → answers are my knowledge, not generic internet stuff.

It's subtle. But it's game-changing.

Let me give you a concrete example. Last week I was working on a BFF project and I couldn't remember the exact performance numbers I measured with Capa-BFF six months ago.

Before MCP:

Me: "Hey Claude, what's a good response time target for a BFF layer?"
Claude: "Typically, under 100ms is considered good..." (generic answer)

After MCP:

Me: "Hey Claude, what kind of response times should I expect with an annotation-driven BFF approach like I used before?"
Claude: [automatically calls search_knowledge("capa-bff response time") via MCP]
Claude: "Based on your measurements with Capa-BFF, you were seeing 50-100ms response times on a single instance, handling 5000+ QPS. You noted that for most business applications this is more than sufficient, but you ran into issues with asynchronous composition adding latency when aggregating many backend services."

That's my data. My experience. Not generic advice from the internet. That's worth everything.

Pros and Cons: Let's Be Honest, As Usual

I've been doing this MCP integration for about a month now. Let me break down what's working and what's not:

✅ Pros

1. Standardization = Less Work

   • Once you implement MCP once, it works with every MCP-compatible client. No more custom integrations for each AI platform. I implemented it once, and now it works with Claude, OpenAI, OpenClaw, everything that speaks MCP.

2. Your Knowledge Stays Yours

   • You don't have to upload all your private notes to some third-party AI service. Your data stays on your server, the AI only gets what it needs for the current query. Privacy by design.

3. Simple Systems Actually Win Here

   • Remember my 20-line search? MCP doesn't care how you implement the tools internally. It just defines the interface. My janky string.contains() search works perfectly well because it's serving the right content to the AI. The AI handles the heavy lifting of understanding and synthesizing.

4. Composition Over Monoliths

   • MCP lets you compose different tools from different sources. Your AI can search your knowledge base, call a weather API, pull from GitHub, all through the same protocol. My knowledge system is just another tool in the toolbox now.

5. It's Surprisingly Easy to Add to Existing Projects

   • I added MCP support to my existing Spring Boot app in an afternoon. You don't need to rewrite everything. Just add a few endpoints, follow the protocol, done.

❌ Cons

1. MCP Is Still Young

   • The protocol is still evolving. Not every AI client supports it yet. You're an early adopter if you jump in now. Expect some rough edges.

2. You Still Need to Host It

   • Your MCP server needs to be accessible from the AI client. If you're running this locally, you need something like ngrok. If you want it everywhere, you need to host it somewhere. That's extra work.

3. Context Window Limits Still Apply

   • MCP lets you fetch context, but you still can't fit your entire knowledge base into the context window. You still need good search to get just the relevant bits. MCP doesn't solve that problem for you.

4. Debugging Tool Calls Can Be Frustrating

   • When the AI calls the wrong tool or misinterprets the results, it can be hard to figure out what went wrong. You don't see the MCP traffic unless your client exposes it.

5. Security Considerations

   • If you expose your MCP server publicly, you need to think about authentication. You don't want just anyone searching your personal knowledge base. That's extra code to write.

My Surprising Takeaway

Here's what I didn't expect: after all these years of building the perfect knowledge system, MCP made me realize that I had it backwards.

I was trying to build an intelligent knowledge system. But intelligence doesn't need to live in your knowledge system. The intelligence lives in the AI you're already talking to. Your knowledge system just needs to expose your knowledge through a standard interface.

That's it. That's the whole insight.

My 20-line string.contains() search is actually the perfect architecture for an MCP-optimized knowledge system:

• It's simple → easy to maintain
• It's flexible → returns whatever matches, the AI figures out what's relevant
• It's fast enough → for 170+ articles, 50ms is nothing
• It's cheap → no expensive vector embeddings to update all the time

Wait, did I mention vector embeddings? Oh right, I deleted those too. Because with MCP, the AI can do the embedding if it really needs it. Or not. It doesn't matter to me anymore. My job is just to expose the data.

What Would I Do Differently?

If I was starting over today with what I know now about MCP, here's what I'd do differently:

1. Start with MCP from day one — Design your knowledge system as an MCP server from the beginning, not as an afterthought.

2. Keep the business logic extremely simple — Let the AI handle the "intelligence" part. You just store and retrieve. That's it.

3. Don't over-engineer search — Start with string.contains(). You'll be surprised how far that gets you when the AI is doing the heavy lifting. Add better search later if you actually need it.

4. Version control your content — Keep your knowledge as markdown files in git. MCP can serve them straight from there. No need for a fancy database until you really need it.

5. Start small — You don't need to import everything right away. Add your notes one by one as you go.

Is This Worth Doing in 2026?

Honestly? It depends.

If you're like me — you have a bunch of personal notes, you use AI assistants every day, you want your AI to actually use your knowledge when answering questions — yes, absolutely. It's worth the afternoon it takes to set up.

If you're happy with just putting all your notes in Notion or Obsidian and they already have AI integration that works for you — probably not needed. But it's still a fun experiment.

If you're building a product or service that needs to expose tools to AI models — definitely. MCP is the future here. Standardization wins.

For me personally? It's the first time in 1,800 hours that my knowledge system actually feels integrated into my daily workflow. Instead of being this thing I built and never use, it's now this background resource that my AI automatically taps into when I need it.

The irony? After all that time chasing the perfect AI-powered knowledge system, the solution was to take my simple dumb search, expose it via a standard protocol, and let other AIs do the AI part.

I told you this was a performance art piece at this point.

Your Turn

What about you — have you tried MCP yet? Are you struggling with getting your personal knowledge integrated with your AI assistants? Or have you also found that simpler is better when you let the AI handle the heavy lifting?

Drop a comment below — I'm curious to hear what approaches are working for other people. I've definitely learned most of what I know from reading other people's failure stories, so I'd love to hear yours.

All code from this project is available on GitHub if you want to poke around. Yes, it still has the 20-line search. No, I'm not apologizing for it.