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  - Superagent 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.

Off hand these are my thoughts but I’m curious if anyone else agrees/disagrees.

Order of importance:

1. Force runtime errors/warnings at compile time wherever possible
2. Minimize ambiguity via types, be it via behaviours, specs, etc.
3. If none of this is possible, provide an examples via documentation/doctests
4. Add an llms.txt as mentioned above so devs could use mcpdoc or similar

Hey all! I’ve put out v0.2.0-rc.1 but am waiting to release it until I’m more confident in how well it works. Is anyone willing to try it out/give me feedback? I would be eternally grateful!

The main updates are:

• Added a fetch command to allow the mcp server to auto fetch docs
• You no longer need to add hexdocs_mcp to your mix.exs. Reasons for this were:
  1. To reduce toil and having to keep dependencies up-to-date for a non-critical tool
  2. I like to switch between various projects and having to remember/install in every project isn’t ideal for my workflow to run mix hex.docs.mcp fetch ...
  3. To make installation as easy as possible for folks. Theoretically you don’t even need to have elixir installed to use the mcp server, though I haven’t tested this.

You can see all of the details and a migration guide in the release notes.

I will admit, it feels odd that the primary entrypoint to this project is a node app, but I think it’s right for now. Once the MCP ecosystem evolves and is more stable, migrating to an elixir MCP server would make a lot of sense I think. I’m open to ideas here if you have any!