Qdrant MCP. Run vector searches and manage collections from chat.

Qdrant hooks your AI client directly into a vector database cluster. You can query embeddings, run nearest neighbor similarity searches, and manage every collection without having to write any complex scripts or boilerplate code. It gives your agent the raw power it needs to interact with structured data.

To start mapping out what's in the system, you use list_collections. This tool runs instantly and shows you a full list of every single collection stored on your Qdrant instance; it’s like getting an index map of all your indexes. Once you know which collections exist, you can dive deeper into any specific one by calling get_collection.

You pass the name of the collection, and the agent spits out detailed metadata about it—you'll get metrics like its configured distance metric (e.g., Cosine or Euclidean) and the expected vector size for all payloads.

When you need to know how big a collection is, use count. You pass a specific collection name, and it returns one single number: the total count of points housed in that index. This gives you an immediate grasp of your dataset's scale without having to pull records. If you suspect something’s wrong or if you need to prune old data, you use delete.

You specify which data points you want gone from a collection; remember, this action is permanent, so double-check what you send.

For finding specific records by their unique ID, the agent uses get_points. If you know the exact identifier (ID) of a payload, you feed that ID to this tool, and it pulls the full data—the actual payload—immediately. This is crucial for debugging or validating specific pieces of information.

When you need to read through massive amounts of data page by page, scroll handles it. You use this tool when your dataset is too big to load into memory all at once. It returns batches of points and their payloads sequentially, allowing your agent to iterate through thousands of records without hitting any memory limits.

This lets you inspect IDs and contents one chunk after the other.

The core function—the search itself—is done with search. You pass a JSON array of floats; that’s your query vector. The tool then performs a nearest neighbor search within a specified collection, returning the data points that match your semantic query best. This is how you find data that means the same thing as your input, even if the words don't match exactly.

To put it all together: If your goal is to analyze data quality or debug embeddings, you combine scroll with get_points. To build a knowledge graph and link related concepts, you rely on search. You can check the overall structure of your environment by running list_collections, then validate that structure using get_collection before querying.

If you need to know how many records are available across all indexes without actually pulling them, use count. The entire workflow—from mapping out what exists with list_collections to reading specific payloads with get_points, and finally performing the heavy lifting of finding semantic matches using search—runs entirely through your agent's ability to invoke these tools, giving you full control over your vector data.