What if you could ask Redis's own history "why"

Redis has been around since 2009, and its design is full of decisions that look strange until you know the backstory. Single-threaded core in a multi-core world. A separate "Redis Cluster" mode instead of transparent sharding from day one. RDB snapshots living alongside AOF logs as two different persistence strategies instead of just one. None of these are arbitrary. Every one of them is the resolved output of a tradeoff discussion, a bug that shaped a default, or a use case that got prioritized over another.

If you go looking for that reasoning today, here's what you actually have to do: dig through mailing list archives, old GitHub issues, conference talks, and a changelog that tells you what changed but rarely why. It's all technically public. None of it is connected. You can find the commit that added Cluster mode. You have to work a lot harder to find the discussion explaining why sharding wasn't done the way, say, a distributed database would do it.

This is exactly the gap a docs-MCP approach is built to close, just applied to a different kind of team: an open source project's own accumulated knowledge, instead of a company's internal docs.

Picture this instead. Someone pulls Redis's design docs, RFCs, key GitHub issue threads, and changelog entries into a connected workspace, where each document links to what it supersedes and what it was a response to. Then that workspace is exposed to an AI over MCP. Now you can ask:

• "Why is Redis single-threaded at its core, and what would break if that changed?"
• "What was persistence like before AOF existed, and what problem did AOF solve that RDB didn't?"
• "Has anyone proposed transparent resharding, and why did that not happen?"

A plain README or docs-search MCP answers the first part of each question at best ("Redis is single-threaded") and stops there, because that fact lives in one place but the reasoning lives across several. A docs-MCP that actually models the relationships between documents can answer the second half too, the part that starts with "why," because it's walking a graph instead of matching keywords in a single file.

This isn't specific to Redis. Any project old enough to have real design history, Postgres, Kubernetes, whatever, has the same problem: the "what" is documented, the "why" is scattered across years of issues, mailing lists, and tribal knowledge that newer contributors have no way to reconstruct. The reasoning doesn't disappear. It just stops being attached to anything a search bar can find.

That's the actual promise of a docs-and-context MCP server: not "search these files faster," but "let the model trace the decision history the same way a longtime maintainer would, by following what led to what." Rootr does this for team docs today, connected over rootr.io/mcp. Point it at a project's own decision trail, and the questions that used to require a maintainer's memory become questions you can just ask.

rootr.io