io.github.avaazquezz/mcp-qdrant

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.1.1
Disambiguation5/5
Each tool targets a distinct resource and action: collection lifecycle, point operations, health, and query. Tools like collection_exists, collection_info, and collection_list are clearly differentiated by what they return and when they fail.
Naming Consistency4/5
The qdrant_ prefix and snake_case naming are consistent, with clear collection_ and points_ grouping. qdrant_health_check and qdrant_query deviate slightly from the verb_noun resource pattern but remain predictable.
Tool Count5/5
13 tools is a well-scoped set for a Qdrant server: collection CRUD plus point upsert/get/delete/scroll/count/query. Each tool earns its place and nothing feels redundant.
Completeness3/5
Core collection and point lifecycles are covered, including create, read, update, delete, and query. However, qdrant_collection_update explicitly references a qdrant_collection_vector_create tool that is not present, which is a notable gap and a dead end for adding named vectors to existing collections.
Average 4.2/5 across 13 of 13 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 58 commits in the last 12 weeks
- Last stable release on August 31, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint true, idempotentHint true, and destructiveHint false, covering the safety profile. The description adds that the filter is optional and gives a minimal example, but it does not disclose behavior around the 'exact' parameter, performance cost, or what happens when the collection does not exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one compact sentence plus a minimal example, with no filler or redundant explanation. The action and resource are front-loaded, and every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only point-counting tool with a complex filter schema and an output schema, the description is minimally adequate. It captures the core operation and filter optionality, but it omits the meaning of 'exact' and any collection-existence or performance caveats, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only notes that a filter is optional and shows a collection_name example. The non-obvious 'exact' boolean parameter is left completely unexplained, which is a significant gap for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action and resource: 'Count points in a collection, optionally matching a filter.' This distinguishes it from retrieval siblings such as points_get, points_scroll, and query, though it never names an alternative, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives like qdrant_points_scroll, qdrant_query, or qdrant_collection_info. 'Optionally matching a filter' implies a use case, but there are no explicit conditions, exclusions, or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds valuable behavioral context beyond annotations: unknown IDs are silently omitted rather than raising errors, and the only failure mode is a missing collection. This is useful for an agent predicting edge-case outcomes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the main action and key behavioral caveat appear in the first line, followed by a failure condition and a concrete example. Every sentence adds information without filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich annotations and existing output schema, the description covers the key behaviors an agent needs: retrieval semantics, missing-ID handling, and failure mode. The only gap is the under-documented optional parameters, but those are simple booleans with clear names and defaults, so the overall picture is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The example documents collection_name and ids, but with_payload and with_vectors are never mentioned, leaving their semantics entirely to their titles and defaults. The required parameters are illustrated, but optional parameters are neglected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves points by ID, which distinguishes it from query/scroll/list siblings. The behavior note ('unknown ids are simply omitted') further clarifies the operation's scope. It does not explicitly name sibling alternatives, so it falls just short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for fetching specific points by ID but provides no guidance on when to choose this over qdrant_query, qdrant_points_scroll, or other siblings. There is no comparison, exclusion, or alternative mention.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds only a minor detail—that it lists names specifically—which is slightly beyond the annotation title 'List Qdrant collections' but does not disclose anything about return format, pagination, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that states the action and scope without any wasted words. It is appropriately sized for a simple listing operation, and the core action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter listing tool with an existing output schema (which presumably describes the returned list of names), the description is complete enough. It clearly states what is returned (collection names) and the context (configured instance). No additional caveats are necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain any parameter semantics. According to the calibration, a baseline of 4 is appropriate for 0-parameter tools; the description adds no negative value here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (List) and the resource (collection names) in the configured Qdrant instance. It distinguishes itself from siblings like qdrant_collection_info (which likely provides details) and qdrant_collection_exists (which checks existence) by focusing on listing names only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that this tool is appropriate for getting an overview of collections by name, nor does it indicate that qdrant_collection_info or qdrant_collection_exists should be used for more specific needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety characteristics such as readOnlyHint, idempotentHint, and destructiveHint=false. The description adds the key behavioral contract around pagination, including the meaning of `next_page_offset` and the null termination condition, which goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: purpose, pagination rule, then a concrete example. There is no filler, and the example earns its place by showing a minimal valid invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter tool with a rich filter schema, the description covers the core scrolling mechanism and optional filtering, and an output schema exists to clarify return values. Still, it omits guidance on payload/vector inclusion parameters and does not address ordering or scan behavior, leaving noticeable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to compensate. It partially does by explaining `offset`, showing `collection_name` and `limit` in an example, and noting the `scroll_filter` via 'optionally filtered.' However, `with_payload`, `with_vectors`, and the full filter construction are left undocumented by the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action and resource: 'Page through all points in a collection, optionally filtered.' This clearly distinguishes the tool from sibling operations like point lookup, counting, or vector search, since it emphasizes bulk scanning and pagination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear pagination loop: pass the returned `next_page_offset` as `offset`, and treat `null` as the end of pages. This implies when the tool should be used, but it does not explicitly name alternatives or state when not to use, e.g., versus `qdrant_points_get` or `qdrant_query`.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds value beyond those by stating that the tool fails with a clear error when the collection does not exist, which is useful behavioral context an agent cannot infer from annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and well-structured: main purpose first, then failure behavior, then a concrete example. Every sentence contributes useful information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only info tool with an output schema and comprehensive annotations, the description covers the necessary invocation details. The failure case is explicitly disclosed, and the example makes the parameter usage clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but there is only one parameter and the example {'collection_name': 'docs'} demonstrates its shape. The description partially compensates for the missing schema documentation, though it does not explain allowed values, naming constraints, or format expectations beyond the parameter title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and a specific resource ('full config and status of one collection'), clearly distinguishing it from siblings like qdrant_collection_exists and qdrant_collection_list. The singular 'one collection' removes ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving details about a single existing collection, but it does not explicitly state when to prefer it over qdrant_collection_exists, qdrant_collection_list, or qdrant_health_check. The failure case is mentioned, which helps set expectations, but no alternatives or exclusion conditions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotation's destructive/idempotent hints, the description adds valuable behavior: deleting a nonexistent id is a no-op and the only failure modes are a missing collection or zero/both selectors. It does not spell out that a filter deletes all matching points, but annotations already cover the destructive profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, and every subsequent sentence adds meaningful constraint or failure-mode detail. The two examples are compact and directly illustrate both supported selector modes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive delete tool with a complex filter schema and an output schema present, the description covers the essential selector exclusivity, example payloads, and failure cases. A minor gap is not explicitly stating that a filter selection deletes all matching points, though that is strongly implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for the parameters, the description compensates by explaining the two selectors, requiring exactly one, and providing concrete JSON examples for both ids and points_filter. collection_name is shown in examples but not independently described; the rich Filter schema fills in the remaining structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description leads with a specific verb and resource: 'Delete points by id list or by payload filter'. It also scopes the operation with 'exactly one of the two', which clearly distinguishes the two deletion modes and separates it from sibling read/upsert tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear operational context and constraints (exactly one selector, needs an existing collection) but never names alternatives or says when not to use this tool, such as preferring qdrant_collection_delete for whole-collection deletion. Usage is therefore implied rather than explicitly contrasted with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses key behavioral traits: the "exactly one of the two" vector definition requirement, collection-wide application of quantization/strict-mode configs, and failure on duplicate collection names. This adds meaningful operational context that the annotations alone do not provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-organized: it front-loads the core creation modes, clarifies important constraints, and provides two practical examples. Every sentence contributes useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is largely complete for a complex creation tool with a rich schema and annotations: it covers the two vector modes, sparse vectors, quantization, strict mode, and failure behavior. The only notable omission is the `metadata` parameter, but overall an agent has enough guidance to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description takes on the burden of explaining parameters, and it does so well for the central ones: vector_size/distance, vectors, sparse_vectors, quantization_config, and strict_mode_config. It does not mention `metadata` or explicitly describe `collection_name`, but its examples and structural explanation cover the most decision-critical parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action and object: "Create a collection" and then precisely distinguishes the two supported vector configurations. It differentiates itself from read/update/delete sibling tools by focusing on creation semantics and even notes the failure condition of recreating an existing collection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when to use this tool and how to choose between unnamed and named vector configurations. It does not explicitly contrast with sibling tools like qdrant_collection_update when a collection already exists, but the "Fails with a clear error if a collection with this name already exists" note effectively implies that precondition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the description's 'replace' aligns. The description adds the failure mode if collection is missing. The nested PointInput schema description further clarifies that embedding inference variants are not accepted, which is useful beyond annotations. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a brief opening sentence, a one-line error note, and a compact example. Every sentence earns its place. The front-loaded purpose makes it easy to scan. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present (per context) and annotations covering idempotency and destructiveness, the description doesn't need to explain return values. It covers the core action, error behavior, and provides an example. Minor omissions like vector dimension validation are not critical for a typical upsert call. Overall quite complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The main description doesn't detail each parameter, but the example shows the expected structure for collection_name and points. The nested schema description explains that id is a plain integer/string, vector is an array, and payload is optional. This adds meaning beyond the raw types, though it doesn't fully cover all edge cases (e.g., vector dimension requirements).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Insert or replace') and resource ('points') with specific components (id, vector, payload). It includes a concrete example that distinguishes it from sibling tools like qdrant_points_get or qdrant_points_delete. The purpose is immediately obvious and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for writing/updating points. It mentions an error if the collection doesn't exist, which implicitly guides the agent to ensure the collection exists (e.g., via qdrant_collection_exists or create). However, it doesn't explicitly state alternatives or when not to use this tool. Clear context but no explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false. The description adds value by specifying that it deletes not only the collection but also all its points, and that it is a no-op if the collection does not exist. This goes beyond the annotation flags by detailing the scope and idempotent outcome, which helps the agent predict the effect. No contradiction is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a code example, with zero fluff. It front-loads the core behavior (delete and scope), states idempotency, and gives a concrete example. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter destructive tool, this description is complete. It covers the action, scope, idempotency, and an example. Given that an output schema exists, the return format does not need to be explained in the description. The annotations cover safety, and the tool's purpose is unmistakable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description must compensate, and it does so with a clear example: {'collection_name': 'docs'}. The parameter name itself (collection_name) and its title (Collection Name) are already self-explanatory, and the example demonstrates the expected string format. This adds meaning beyond the schema's basic type and title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and the resource 'a collection and all its points', which is specific and unambiguous. It also distinguishes itself from sibling tools like qdrant_collection_create or qdrant_collection_update by its destructive nature. The idempotency note ('no-op if it doesn't exist') further clarifies the exact behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly mention alternatives or when-not-to-use, but it conveys that the operation is safe to call regardless of existence (no-op if absent). This provides enough context to decide when to invoke it, and the clear verb 'delete' leaves little ambiguity about its purpose. However, it could explicitly state that this is the tool to permanently remove collections, versus other tools like update or list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds a meaningful behavioral guarantee beyond annotations: it will not raise when the collection is absent. This is useful for an agent deciding how to handle negative results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with an embedded example; every line earns its place. The core behavior is front-loaded and no filler is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, read-only existence check, the combination of annotations, output schema, and description fully covers what an agent needs to call it correctly. The non-raising behavior and example fill the important gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description's example {'collection_name': 'docs'} compensates by demonstrating the expected parameter format. The single parameter is self-explanatory from its name, and the example confirms usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Check whether a collection exists') and adds a distinctive behavioral detail ('without raising if it doesn't'). This makes it clearly distinguishable from siblings like qdrant_collection_info and qdrant_collection_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly scopes use to existence checks, and the non-raising behavior clarifies the typical use case. It does not explicitly name alternatives or exclusion criteria, but the context is unambiguous for a simple boolean existence check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/ idempotent annotations, the description explicitly discloses a key behavioral trait: it never raises to the caller and instead reports connection failures in ok/error fields. This is valuable, non-obvious information that materially affects how an agent interprets results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence states the core purpose, and the second explains the crucial error-handling behavior. Every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only health check with an output schema, the description fully covers what an agent needs: purpose, safety profile via annotations, and the non-raising error behavior. Nothing important is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully covers parameter semantics. The baseline of 4 applies; no parameter documentation is needed, and the description instead focuses on behavior, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Confirm the configured Qdrant instance is reachable and responding.' It clearly distinguishes this tool from the collection and point operation siblings, which address different concerns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes clear that the tool is for confirming connectivity and responsiveness of the Qdrant instance, which provides strong usage context. It does not explicitly discuss when to avoid it or name alternatives, but none of the sibling tools serve this health-check role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only/idempotent/non-destructive behavior. The description adds substantial behavioral detail beyond that: the exactly-one requirement, the 'one level only' prefetch restriction, lookup_from cross-collection resolution, and error-on-missing-collection behavior. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured: a summary sentence, parameter semantics, an error note, then two concrete examples. Every sentence adds value, and the examples make complex hybrid usage concrete. Appropriate length for a tool with this many parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description is remarkably complete: both invocation modes, fusion options, prefetch semantics, the exactly-one constraint, and failure behavior are all covered. The output schema and annotations fill the remaining gaps. Only the lack of sibling-tool comparison is a minor omission, and that is a usage-guideline nuance rather than a completeness failure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With top-level schema description coverage at 0%, the description carries a heavy burden and does much of the work: it explains query_vector (literal or point id), fusion algorithms, prefetch stages, using, and lookup_from. It doesn't explicitly define limit, with_payload, with_vectors, query_filter, or collection_name, though several are self-evident or documented in the schema's $defs. A solid but not total compensation for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb and resource: 'Vector similarity search, with optional hybrid search over multiple prefetch stages.' This leaves no doubt about the tool's function and immediately distinguishes it from sibling collection-management and point-scroll tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context for when to use plain query_vector mode vs hybrid fusion+prefetch mode, including the 'exactly one of query_vector/fusion is required' rule and two full examples. However, it never explicitly names alternative sibling tools (e.g., qdrant_points_scroll) or states when not to use this tool, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses important behavioral traits: partial-update semantics ('Only the fields you pass are changed; omitted ones keep their current value'), the special 'disabled' value for quantization_config, and the constraint that vectors_config/sparse_vectors_config can only adjust existing vectors. It also discloses failure modes for both missing collections and non-existent vector names. This is rich, actionable behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then adds only high-value semantic context, failure modes, and an example. There is no filler, repetition of schema, or unnecessary prose. Every sentence earns its place, and the example is compact and illustrative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's high complexity, the description covers the essential operational semantics, the key constraint about vector names, the special quantization value, the error condition for missing collections, and a realistic example. The output schema exists, so not describing return values is acceptable. An agent has enough information to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries real weight here. It adds crucial meaning: partial updates, quantization_config='disabled', and the difference between adjusting and adding vectors. It also provides a concrete example using collection_name and optimizers_config. However, it does not explicitly call out strict_mode_config or enumerate every top-level parameter, leaning on the nested schema definitions for those details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Update optimizer/HNSW/collection/vector params on an existing collection.' It clearly differentiates this update tool from creation/read/delete tools by emphasizing 'existing collection' and explicitly noting it cannot add new vectors. This is far beyond a tautology and gives an agent a precise mental model.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use context: update parameters on an existing collection. It also gives a clear when-not-to-use and alternative: vectors_config/sparse_vectors_config cannot add new vectors; use qdrant_collection_vector_create instead. It additionally warns that the tool fails if the collection does not exist, which helps the agent decide whether a create tool is needed first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![Qdrant-MCP MCP server](https://glama.ai/mcp/servers/avaazquezz/Qdrant-MCP/badges/card.svg)](https://glama.ai/mcp/servers/avaazquezz/Qdrant-MCP)

Score Badge

Copy to your README.md:

[![Qdrant-MCP MCP server](https://glama.ai/mcp/servers/avaazquezz/Qdrant-MCP/badges/score.svg)](https://glama.ai/mcp/servers/avaazquezz/Qdrant-MCP)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/avaazquezz/Qdrant-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server