With two newer tools entering the mix, I wanted to share how I see them stacking up and hear your thoughts.

Tidewave launched, but its Elixir docs search still leans on the standard keyword lookup HexDocs already exposes. In my experience, an embedding plus RAG approach gives tighter answers when you only half-remember a function name or want a plain-language explanation. If you have tried both, do you notice a quality gap?

Context7 also uses embeddings and supports many ecosystems. The flip side is that every query goes to their servers and their chunking strategy is generic rather than Hex-specific. I’d love to hear whether Context7 feels more or less accurate for you and how important the local-versus-remote question is.

I plan to keep HexDocs MCP around until the Hex core team adds native embeddings; if that happens I will happily archive the repo. In the meantime, any feedback on search quality or workflow fit is very welcome!

@bradley, this is sweet, thanks for building this!

A few misc comments:

• Bumblebee really only makes sense to use if you’re willing to port the server to Elixir. Note that @thmsmlr has a (STDIO transport) MCP server implementation as part of Livebook Tools: livebook_tools/lib/livebook_tools/mcp_server.ex at master · thmsmlr/livebook_tools · GitHub

• This is a bigger discussion, and I’m not going to do it justice in this quick comment, but something to consider: using RAG for search, but not for context. RAG picks out relevant chunks and thus identifies relevant modules/docs, but separate LLM call(s) are made (with the entire contents of that module’s documentation, and a summary of the user’s ask), returning new LLM-summarized text that can then be passed off to the coding agent. See ReAG: Reasoning-Augmented Generation for a better explanation (although that’s not exactly what I’m proposing, but it’s along the same lines).

My preferred tools don’t yet support MCP, so I haven’t played around too much, but the above is an approach I’ve been planning on playing around with.

I was thinking specifically about what documentation should be written to maximise the chances of a developer getting a relevant and useful result from MCP-based searches.

For example, most of my libs have reasonable API documentation. But they definitely lack in tutorial type documentation. If the trend is towards more AI-assisted help then perhaps I need to be paying more immediate attention to different types of documentation.