Skip to main content
Glama

qdrant_list_collections

Lists all available Qdrant collections to inspect the vector database's current collection setup and identify collections for semantic search.

Instructions

List all collections in Qdrant.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "qdrant_list_collections"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.3

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are supplied, so the description carries the whole burden. "List" implies a non-mutating read and the absence of parameters signals a low-risk call, but the description says nothing about auth requirements, pagination, or whether the output is names only versus full collection metadata — an output schema exists, so return shape is partly covered elsewhere.

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?

A single short sentence with the verb and resource front-loaded and no wasted wording. The trailing "in Qdrant" is mildly redundant given the tool name prefix but harmless.

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 enumeration tool with an output schema and no annotations, the description covers what is needed to call it. The only gap is behavioral context the missing annotations would normally supply, such as confirmation that the call is read-only and any cost or connection prerequisites.

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 takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The description correctly implies the call is unfiltered and takes no arguments.

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?

"List all collections in Qdrant" states a specific verb (list) and resource (collections) with explicit scope (all). It does not differentiate from siblings like qdrant_get_collection_info or qdrant_list_indexed_files, so an agent must infer that this returns collection names rather than per-collection details.

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?

No explicit when-to-use or when-not-to-use guidance is given. The use case (discovery/enumeration of collections prior to other operations) is implied by "List all collections" and the zero-parameter signature, but the description never names an alternative or a precondition.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.