I’ve built an MCP server that lets AI agents use Hackage. The MCP server is entirely written in Haskell.
It lets LLMs:
perform Hoogle searches.
List package modules
Scrape module documentation in LLM-friendly Markdown.
Why this tool?
I’ve often seen premium coding agents using outdated functions or not being aware of the latest packages. This MCP lets LLMs access the latest Haskell documentation.
I don’t get why you’d query upstream hoogle anyway, for a local package dev you get a lot better result just using local dependencies. You’d also get access to private dependencies.
Although you’d have to built the index, which takes time.
I didn’t do haddocks, that’s a different problem.
Hmm, I wasn’t aware this existed otherwise I’d probably just repair this project.
idk if @tusharad is interested in using a local hoogle instead, I’d be happy to archive my version and submit local support to their version?
My opinion is that the right thing is to start an ecosystem project that uses LLMs sustainably and responsibly:
keep blocking all the scrapers and bots
train our own open weight model on haskell and hackage
make sure it isn’t optimized for “engagement” (optimally, an LLM for search would be able to recognize when you’re in “mindless prompting” mode and tell you to go read the docs of package XY)
optimize it for search and small code snippets (“how do I do XY?”)
give LICENSE warnings/summaries on non-trivial codesnippets
It’s kinda hard to use LLMs in a way that actually enables learning, but maybe someone has to try.
A local-only package index wouldn’t be able to suggest functions from packages you don’t currently have installed, right? That seems significantly limiting.
hoogle only indexes stackage though, most commercial projects have much more dependencies then what’s just in stackage.
besides dependencies don’t change all that much (usually).
This isn’t a particular new idea, I think the standard hpkgs nix shell environment already provides a withHoogle option