Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
The qdrant-mcp server registers 30 tools with basic schemas and descriptions, but suffers from systematic gaps in parameter documentation, missing output schema definitions, and lack of error handling guidance. All tools have names starting with action verbs (qdrant_db_*) and descriptions are present but often generic. Input schemas exist but are minimally documented, most parameters lack descriptions, violating the core requirement that every parameter must explain what it controls. No tools declare output schemas, making it impossible for LLMs to plan downstream operations or understand what data will be returned. Error handling is absent, there are no recovery guides, categorization, or actionable error messages. Security considerations around API key injection and rate limiting are not visible in tool definitions. The codebase shows competent implementation (proper async handlers, registration pattern), but the tool interface is underspecified for LLM use.
No parameter descriptions across all 30 tools. Core parameters like 'collection_name', 'field_name', 'points', 'vector', 'payload', 'filter', 'limit', 'offset' lack documentation explaining what they control, their format, expected range, or how they influence behavior.
No output schema documentation for any tool. LLMs cannot understand what fields, types, or structure will be returned. This prevents agents from planning downstream tool calls or extracting the correct data for subsequent operations.
Incomplete input schemas for many tools. For example, qdrant_db_collections_create accepts 'vectors' as {'type':'object'} with no properties defined, making it unclear what structure or nested fields are required. Similarly, 'filter', 'operations', and 'searches' parameters in multiple tools lack type details.
Add detailed descriptions for every parameter across all tools. For example, 'collection_name' should be: 'The unique identifier of the Qdrant collection to query. Collection names are case-sensitive and must exist before use (call qdrant_db_collections_list to discover available collections).'
Document output schemas for all tools. Specify the structure of returned data, including field names, types, and what each field represents. For example, qdrant_db_collections_get should document it returns {name: string, points_count: int, config: {vector_size: int, ...}}.
Expand tool descriptions to 50-200 characters, including: what the tool does, when to use it instead of similar tools, and any prerequisites. Example: 'Delete a collection and all its points permanently. Irreversible. Use with caution. Requires the collection to exist (call qdrant_db_collections_exists first if uncertain).'
Add explicit type definitions to nested object parameters. For qdrant_db_collections_create, expand 'vectors' to show: {"type": "object", "properties": {"size": {"type": "integer", "description": "Vector dimension..."}, "distance": {"type": "string", "enum": ["Cosine", "Euclid", "Dot"]}}, "required": ["size", "distance"]}.
Destructive and write operations lack confirmation or dry-run patterns. Tools like qdrant_db_collections_delete, qdrant_db_points_delete, qdrant_db_vectors_delete can permanently destroy data without agent confirmation or rollback paths.
No error handling guidance in tool definitions. No recovery hints, categorization of errors (retryable vs user-fixable vs fatal), or actionable error messages. Agents have no way to know what to do when a call fails.
Tool annotations missing. No tool declares whether it is read-only, has destructive effects, or is idempotent. LLMs cannot distinguish safe tools from risky ones without explicit hints in the tool definition.
Vague and generic descriptions. Tools like 'qdrant_db_collections_update' and 'qdrant_db_points_batch' have descriptions of 40-55 characters that do not explain what they modify, when to use them, or what side effects occur. LLMs cannot reliably select the right tool.
Array parameters lack item schema details. Parameters like 'points' (array), 'keys' (array of string), 'ids' (array), 'operations' (array of object), and 'searches' (array of object) do not specify what each array element should contain, what fields are required, or what types nested properties have.
No pagination documentation despite accepting 'limit' and 'offset' parameters. Tools like qdrant_db_points_scroll do not document the maximum result size, when pagination is required, what the next_cursor format is, or how total counts are returned.
Default values create silent bugs. Parameters like 'limit' have defaults (10) but no description explaining why that default was chosen or what happens if the user needs more results. Parameters like 'with_payload' and 'with_vector' default to true/false with no guidance on the performance or data size implications.
Implement tool annotations: add 'readOnlyHint' for all health, list, get, count, scroll, search, recommend tools; add 'destructiveHint' for delete, clear tools; add 'idempotentHint' for upsert, set, overwrite tools. Example: Tool(..., readOnlyHint=True) for qdrant_db_points_scroll.
Add recovery guidance to tool descriptions for operations that can fail. For delete operations: 'If deletion fails with a 'collection not found' error, verify the collection name with qdrant_db_collections_list. If it fails with a 'points not found' error, some or all points may have already been deleted; this is safe to retry.'
Implement pagination documentation for list/scroll/search tools. Document: (1) maximum results per call (e.g., 100), (2) how to get the next batch (offset/cursor), (3) whether total count is returned, (4) example: 'Limit defaults to 10. Max is 1000. Use offset=<value> to fetch next batch. Returns {points: [...], total: 1234}.'
Add constraints and format hints. For parameters like 'limit', specify range (1-1000). For 'collection_name', specify allowed characters (alphanumeric, underscore, hyphen). For vector arrays, specify element count must match collection's vector size.
Consider adding a 'dry_run' parameter to destructive operations (delete, clear, overwrite). This allows agents to preview what would be deleted without permanent consequences.
Document default value rationale. For 'limit'=10, explain: 'Default of 10 results balances response time and completeness. Increase for larger result sets; be aware high limits may slow responses.' For 'with_payload'=true, explain: 'Payload is included by default; set to false to reduce response size if only vector IDs are needed.'
For tools accepting complex filters (e.g., qdrant_db_points_count, qdrant_db_points_scroll), document filter syntax. Provide examples: '{"must": [{"key": "field", "match": {"value": true}}]}' or reference Qdrant's filter documentation.
Add 'idempotency_key' parameter to write operations (upsert, set, overwrite, batch). This prevents duplicate side effects if an agent retries: 'Optional unique identifier for the operation. If provided, identical payloads with the same key are idempotent.'
Audit response sizes. For qdrant_db_points_scroll, limit results to 50 by default (not 10) to match production baselines, and document this: 'Returns up to 50 points per call to balance efficiency and context window usage.'
For tools returning multiple point/vector results, include chaining IDs in responses. E.g., qdrant_db_points_scroll should return not just points but also next_offset so agents can immediately call scroll again without an extra lookup.