We’ve been working closely with teams building AI systems for the software engineering stack - autocomplete bots, PR review agents, and code assistants. One common pain point we see: these systems hallucinate about dependencies.

While most companies index the primary codebase with grep, semantic search, and AST-based tools, dependencies are often overlooked. Even though they typically make up the bulk of running code. Maintaining source ingestion into agents is often difficult: fetching tarballs, caching, and avoiding latency spikes.

So we built Package Search MCP. It ingests and indexes public dependencies from NPM, PyPI, Go, and Crates.io at distinct versions. We:

1. Use Tree-sitter to parse and chunk the code

2. Embed the data with Qwen3-Embedding

3. Index each version into its own fork on Chroma Cloud

4. Expose grep + semantic search tools for agents via MCP

Just add this MCP server to your coding agent or AI SDK (Cursor, Claude, Codex, OpenAI etc.), and your agent immediately gets smarter about dependencies. Prompt it with “Use package search” and it’ll know where to look.

We’re excited to see what people build with it - try it out and let me know what you think!

Comments URL: https://news.ycombinator.com/item?id=45202664

Points: 12

# Comments: 1

I understand your point. Chroma Cloud has been quietly live in production for a year, and we have been discussing this architecture publicly for almost two years now. You can see this talk I gave at the CMU databases group - https://youtu.be/E4ot5d79jdA?si=i64ouoyFMevEgm3U. Some details have changed since then. But the core ideas remain the same.

The business model similarities mostly fall out of our architecture being similar, which mostly falls out of our constraints with respect to the workload being the same. There are only so many ways you can deliver a usage based billing model that is fair, understandable, and predictable. We aimed for a billing model that was all three, and this is what we arrived at.

On aesthetics, that’s always been our aesthetic, I think a lot of developer tools are leaning into the nostalgia of the early PC boom during this AI boom (fun fact, all the icons on our homepage are done by hand!).

On differences, we support optimized regexes vs full-scans, lending better performance. We also support trigram based full-text search which can often be useful for scenarios which need substring matches. We also support forking, which allows for cheap copy-on-write clones of your data, great for dataset versioning and tracking git repos with minimal cost. We've been building with support for generic sparse vectors (in beta) which enables techniques like SPLADE to be used, rather than just BM25. You can also run Chroma locally, enabling low-latency local workflows. This is great for AI apps where you need to iterate on a dataset until it passes evals, and then push it up to the cloud.

Chroma is Apache 2.0 open source - https://github.com/chroma-core/chroma and has a massive developer community behind it. Customers can run embedded, single-node and distributed Chroma themselves. We've suffered from depending on closed-source database startups and wanted to give developers using Chroma confidence in the longevity of their choice.

Lastly, we are building with AI workloads front and center and this changes what you build, how you build it and who you build for in the long term. We think search is changing and that the primary consumer of the search API for AI applications is shifting from human engineers, to language models. We are building some exciting things in this direction, more on that soon.

Comments URL: https://news.ycombinator.com/item?id=44540403

Points: 4

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=44119782

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=43981082

Points: 2

# Comments: 0

This binary is an utter waste of time.

Instead focus on the gradient of intelligence - the set of cognitive skills any given system has and to what degree it has them.

This engineering approach is more likely to lead to practical utility and progress.

The view of intelligence as binary is incredibly corrosive to this field.

Comments URL: https://news.ycombinator.com/item?id=41779925

Points: 24

# Comments: 3

Comments URL: https://news.ycombinator.com/item?id=40529139

Points: 2

# Comments: 0

To be more correct it’s O(N/C log C) where C is the capacity of a segment. In this case you can ignore 1/C and log C as constant. So now sure, you actually just have O(N). But this is not super useful as it says that a segmented hnsw approach and brute force approach are the same - when this is really not the case in practice.

Also O(N log N) > O(N) so I’m not sure why we would ever do anything with segmentation according to that analysis if it were correct.

How is a log N search over S segments O(N)?