Elasticsearch vs Qdrant API + MCP

Elasticsearch

Keyword, dense and sparse vector, and hybrid search with rank fusion sit behind one OpenAPI-described REST API, with API keys scoped to indices and privileges. The status page lists more than 20 incidents marked major since July 2026, and Elasticsearch 9.5.0 returned incorrect results for some queries without raising an error.

Qdrant API + MCP

Database keys can be read-only, limited to chosen collections and expire after 90 days by default. The MCP server has 2 tools, can't manage collections or run filtered queries, and last released on 10 December 2025.

Elasticsearch

1. Send Authorization: ApiKey <key> to the project's Elasticsearch URL. The MCP server is on the Kibana URL at /api/agent_builder/mcp
2. Create the MCP key with feature_agentBuilder.read and only the index patterns needed, or the endpoint answers 403
3. On 429, wait and retry with exponential backoff. Do not set short client timeouts, because a retried request joins the back of the queue
4. Page past 10,000 hits with search_after, not from and size
5. Tool calls made directly through the Tools API skip Agent Builder's confirmation prompts, so restrict the key instead

Qdrant API + MCP

1. Create payload indexes on the fields you filter on, or filtered search slows on large collections
2. Use /points/query with prefetch to fuse dense and BM25 results
3. Pass wait=true on upserts when the next step reads its own writes
4. On 429, wait for the Retry-After seconds before retrying
5. Set with_vector=false unless the task needs vectors, since they dominate response size