An ingestion pipeline that creates vector embeddings for selected Vaadin docs
A REST API for searching relevant documentation for a given question
An MCP server that allows any supporting client to search relevant Vaadin documentation as part of their workflow
Usage
REST API
POST https://vaadin-docs-search.fly.dev/search
Content-Type: application/json
{
"query": "How should I structure a Vaadin project?",
"max_results": 3
}
I added a new /ask endpoint to the REST server based on @Artur’s suggestion. It will internally query docs and return an AI generated answer that’s suitable for end users.
POST https://vaadin-docs-search.fly.dev/ask
Content-Type: application/json
{
"question": "What's the Hilla route directory structure?"
}
You can now also add an optional "framework": "flow" | "hilla" to the /ask and /search endpoints to restrict the returned values to one framework. Omitting the value returns results for both frameworks.
The latest (0.2.0) version of the MCP server uses the framework parameter and instructs the using agent to figure out a correct value for it based on context.
It should now be up and running, but the results aren’t yet as good as I’d like as it’s using a quite plain RAG implementation. I should find time to improve that.
I have made some significant updates to the Vaadin Documentation services:
Improved search accuracy:
Improved chunking
Hybrid semantic + keyword retrieval with reranking
New tools:
Fetch a full documentation page (useful for agents to get more context around a snippet)
Get latest Vaadin version
Vaadin primer document tool that gives agents up-to-date information about Vaadin in the hopes of keeping agents from writing code for older Vaadin versions.
Breaking change in the REST API: the query parameter was renamed question.
Thanks! The primer doc is an experiment to see if it could help LLMs better grasp modern Vaadin development vs rely on random Vaadin 8-14 stuff it has found online. It seems to have a positive impact, but the actual file content needs some curation - right now it’s quickly put together with an LLM from our docs with minor edits. Not sure how prescriptive it should be either. Interested to hear your experiences trying it.
Yes. It was what I originally wanted but back then anything besides the stdio transport was mostly just a vague idea. Going forward, I’m only focusing on the HTTP one. It’s also much more convenient to hook up to Java apps as you don’t need a node process just to proxy calls to a REST server.