u/Scared-Tip7914

Hey! I built TinySearch because my local/smaller models kept getting wrecked by web search tools that dumped way too much junk into context.

Instead of handing the model full pages or giant search blobs, TinySearch does:

search → crawl → rerank → return only the most relevant source-grounded chunks

It runs as an MCP server, uses DuckDuckGo + Crawl4AI, reranks with dense embeddings + BM25, and returns a structured prompt with URLs attached so the caller model can answer from evidence instead of guessing.

Main use case is local agents / smaller models, but it also helps with cloud models because less context = lower cost.

Just shipped v0.1.2 with Docker support.

GitHub: https://github.com/MarcellM01/TinySearch

Hey everyone,

Been playing around with local agent setups lately, mostly Cline/Roo with smaller models, and web search kept annoying me.

Not because it doesn’t work, but because it usually throws way too much random page text into the context. small models really don’t handle that gracefully lol. they start with a simple search and suddenly half the prompt is scraped garbage.

So I built bad boy, TinySearch.

It’s a small open-source MCP tool that does web search, crawls a few pages, chunks/retrieves/reranks the useful bits, and gives the agent a much smaller context blob instead of dumping full pages.

Repo:
https://github.com/MarcellM01/TinySearch

Uses DuckDuckGo, Crawl4AI, dense + BM25-style retrieval, reranking, MCP, and it can also run as a FastAPI server.

On my setup (M4 Mac and old ahh lenovo thinkpad) it usually takes around 5–12 seconds end to end, depending on the query/machine

Not trying to replace real search infra or anything. it’s more just a little local research layer for people building agents who don’t want to spin up a whole backend just to let the model look stuff up.

Still rough in places, but it’s been useful enough for my own workflows that I figured I’d share it.

Feedback/roasting welcome, especially from people using Cline, Roo, MCP, or smaller local models.

https://github.com/MarcellM01/TinySearch

Hey everyone,

I’ve been building TinySearch, a small open-source research tool for low-resource local LLM agents (for example Cline running Qwen3.5-9B).

I kept running into the issue that most existing tools flood the context window with too much low-signal information, so I built one that very consciously tries to extract the highest-signal information from the web while compressing it into as few tokens as possible.

The idea is pretty simple: give agents a lightweight way to search the web, crawl pages, retrieve relevant chunks, and return useful context without needing to set up a full search backend.

TinySearch can:

• search with DuckDuckGo
• crawl/scrape webpages with Crawl4AI
• fan out across multiple sources in parallel
• dedupe results
• retrieve with dense + BM25-style search
• rerank chunks
• expose everything through MCP
• optionally run as a FastAPI server

Typical end-to-end runs are around 5–12 seconds, depending on the query and machine. That includes searching, crawling multiple pages, processing the content, and returning a compact research context for the agent.

So it’s not just “search one page and summarize it.” It’s more like a small local research pipeline:

search → crawl many pages → chunk/retrieve → rerank → return useful context

I built it because a lot of local agent workflows need external research, but wiring up proper search infrastructure can feel like overkill for smaller projects, prototypes, and RAG experiments.

It’s not meant to replace serious production search infrastructure. It’s more of a small, inspectable tool for people building local agents, MCP workflows, and research-heavy LLM apps.

Would love feedback, especially from people building local agents or MCP-based workflows.

P.S. The repo also includes a global-rules-recommended.md template that’s heavily recommended if you integrate this into agentic coding tools like Cline or Roo Code. With that setup, it works like a charm.

Hey everyone,

I’ve been building TinySearch, a small open-source research tool for low-resource local LLM agents (for example Cline running Qwen3.5-9B).

I kept running into the issue that most existing tools flood the context window with too much low-signal information, so I built one that very consciously tries to extract the highest-signal information from the web while compressing it into as few tokens as possible.

The idea is pretty simple: give agents a lightweight way to search the web, crawl pages, retrieve relevant chunks, and return useful context without needing to set up a full search backend.

TinySearch can:

• search with DuckDuckGo
• crawl/scrape webpages with Crawl4AI
• fan out across multiple sources in parallel
• dedupe results
• retrieve with dense + BM25-style search
• rerank chunks
• expose everything through MCP
• optionally run as a FastAPI server

Typical end-to-end runs are around 5–12 seconds, depending on the query and machine. That includes searching, crawling multiple pages, processing the content, and returning a compact research context for the agent.

So it’s not just “search one page and summarize it.” It’s more like a small local research pipeline:

search → crawl many pages → chunk/retrieve → rerank → return useful context

I built it because a lot of local agent workflows need external research, but wiring up proper search infrastructure can feel like overkill for smaller projects, prototypes, and RAG experiments.

It’s not meant to replace serious production search infrastructure. It’s more of a small, inspectable tool for people building local agents, MCP workflows, and research-heavy LLM apps.

Repo: https://github.com/MarcellM01/TinySearch

Would love feedback, especially from people building local agents or MCP-based workflows.

P.S. The repo also includes a global-rules-recommended.md template that’s heavily recommended if you integrate this into agentic coding tools like Cline or Roo Code. With that setup, it works like a charm.

In most RAG setups, the focus is on chunking, embeddings, retrieval, reranking.

But I don’t see much discussion around what happens before that.. the query itself.

In practice:

• users don’t know what to search
• wording matters a lot for retrieval quality
• latency matters (especially per keystroke)

The usual options seem to be:

• run a search backend (Elasticsearch, etc.)
• use an LLM for suggestions
• or just skip autocomplete entirely

I’ve been experimenting with handling this as a local layer inside the app instead — prefix-based suggestions + lightweight scoring, no extra service.

I ended up packaging the experiment as a small pip-installable library:
https://pypi.org/project/query-autocomplete/

GitHub if anyone wants to dig in:
https://github.com/MarcellM01/query-autocomplete

Idea is just:

• build from your docs
• suggest queries before retrieval
• keep it fast and local

Not saying this is a perfect solution, more trying to figure out if this layer is underused in RAG systems.

Do you guys handle autocomplete at all, or just rely on the retriever/LLM to deal with messy queries?

I’ve been looking into autocomplete/typeahead systems recently, especially in contexts where latency really matters (e.g. search-as-you-type or RAG pipelines).

From what I can tell, the main approaches are:

• Full search backends (Elasticsearch, Meilisearch, etc.)
• LLM-based suggestions (flexible but slow per keystroke)
• Simpler prefix / n-gram systems (fast but sometimes limited)

I’m trying to understand what people actually use in production when you need:

• very low latency
• reasonable suggestion quality
• minimal infra overhead

Are most systems still based on classical methods, or are people moving toward hybrid approaches (retrieval + reranking)?

For context, I’ve been experimenting with a small local implementation here:
https://github.com/MarcellM01/query-autocomplete

Available on pypi:
https://pypi.org/project/query-autocomplete/

Not trying to replace full search systems, more to understand where the practical tradeoff line is between latency and quality.

Would be really interested to hear what setups people are running and what worked/didn’t.