Re-running the @hasmcp/mcp-spec-test MCP conformance suite against this server (launched with uvx mcp-server-qdrant and either QDRANT_LOCAL_PATH or QDRANT_URL=:memory:) still turns up a real, reproducible protocol issue: when a client sends an initialize request that omits the protocolVersion field, or offers an unsupported version, the server never responds at all — the connection just hangs until the client's 10-second timeout fires, rather than the server defaulting to a supported version or replying with an error. This was confirmed consistently across two separate re-runs with different (valid) Qdrant backend configs, so it doesn't look like a one-off timing fluke. Both spec revisions the server negotiates (2026-07-28 and 2025-11-25) were tested and show the same root cause (a hanging response to a version-less/unsupported-version handshake), so this single issue covers both — see the report below for the 2026-07-28 run; the 2025-11-25 run showed the identical two version-negotiation failures (plus fewer "not verified" cases, since that revision doesn't define the server/discover probe this suite also exercises).
Conformance report
MCP 2026-07-28 conformance report
Verdict: not conformant — 7 requirements violated.
|
|
| Target |
uvx mcp-server-qdrant |
| Transport |
stdio |
| Revision tested |
2026-07-28 |
| Revisions supported |
2026-07-28, 2025-11-25 |
| Passed |
7 |
| Failed |
7 |
| Not verified |
22 |
| Cases applied |
36 |
| Tool |
@hasmcp/mcp-spec-test 0.1.1 |
Failed (7)
the server deviates from the spec here
server/discover
- server/discover is answered without a session or handshake
expected 200, got 0: {"_raw":"no response within 10000ms"}
- server/discover advertises the versions the server can serve
Cannot read properties of undefined (reading 'supportedVersions')
- server/discover is a CacheableResult with usable cache hints
Cannot read properties of undefined (reading 'ttlMs')
- server/discover reports server identity and capabilities
Cannot read properties of undefined (reading 'capabilities')
- server/discover is stable across calls within its own TTL
Cannot read properties of undefined (reading 'supportedVersions')
- server/discover advertises a revision this suite supports
Cannot read properties of undefined (reading 'supportedVersions')
Version negotiation
- a request with no version at all is served on the default
a version-less request must be served, got 0: {"_raw":"no response within 10000ms"}
Passed (7)
checked and conformant
- server/discover: the suite is reading a schema that matches the features it selected
- Result envelope: schema sanity: the envelope fields match the features selected
- Official SDK interop: the official SDK does not yet implement the newest revision
- Official SDK interop: a stock official-SDK client completes the handshake
- Official SDK interop: the handshake settles on a revision inside the supported window
- Official SDK interop: a stock official-SDK client can list tools
- subscriptions/listen: schema sanity: SubscriptionsListenResult requires _meta and resultType
(22 further cases came back "not verified" — skipped, not passed — because they depend on a working server/discover/handshake response; full detail available on request.)
How to reproduce
With Docker:
docker pull hasmcp/mcp-spec-test:latest
docker run --rm -e QDRANT_LOCAL_PATH=/tmp/qdrant-db -e COLLECTION_NAME=test-collection hasmcp/mcp-spec-test -c "uvx mcp-server-qdrant"
(on Apple Silicon/arm64 hosts, add --platform linux/amd64 to both commands — the published image is amd64-only but runs fine under emulation)
Without Docker (npx):
npx @hasmcp/mcp-spec-test@latest -c "uvx mcp-server-qdrant"
(set QDRANT_LOCAL_PATH=/tmp/qdrant-db and COLLECTION_NAME=test-collection in the environment first)
This issue was filed by an automated MCP spec-conformance sweep. If this turns out to be a false positive (e.g. specific to how the test harness drives the handshake), please feel free to close it — no offense intended, just flagging what the suite found in case it's useful.
Re-running the
@hasmcp/mcp-spec-testMCP conformance suite against this server (launched withuvx mcp-server-qdrantand eitherQDRANT_LOCAL_PATHorQDRANT_URL=:memory:) still turns up a real, reproducible protocol issue: when a client sends aninitializerequest that omits theprotocolVersionfield, or offers an unsupported version, the server never responds at all — the connection just hangs until the client's 10-second timeout fires, rather than the server defaulting to a supported version or replying with an error. This was confirmed consistently across two separate re-runs with different (valid) Qdrant backend configs, so it doesn't look like a one-off timing fluke. Both spec revisions the server negotiates (2026-07-28and2025-11-25) were tested and show the same root cause (a hanging response to a version-less/unsupported-version handshake), so this single issue covers both — see the report below for the2026-07-28run; the2025-11-25run showed the identical two version-negotiation failures (plus fewer "not verified" cases, since that revision doesn't define theserver/discoverprobe this suite also exercises).Conformance report
MCP 2026-07-28 conformance report
Verdict: not conformant — 7 requirements violated.
uvx mcp-server-qdrantFailed (7)
the server deviates from the spec here
server/discover
expected 200, got 0: {"_raw":"no response within 10000ms"}
Cannot read properties of undefined (reading 'supportedVersions')
Cannot read properties of undefined (reading 'ttlMs')
Cannot read properties of undefined (reading 'capabilities')
Cannot read properties of undefined (reading 'supportedVersions')
Cannot read properties of undefined (reading 'supportedVersions')
Version negotiation
a version-less request must be served, got 0: {"_raw":"no response within 10000ms"}
Passed (7)
checked and conformant
(22 further cases came back "not verified" — skipped, not passed — because they depend on a working
server/discover/handshake response; full detail available on request.)How to reproduce
With Docker:
(on Apple Silicon/arm64 hosts, add
--platform linux/amd64to both commands — the published image is amd64-only but runs fine under emulation)Without Docker (npx):
(set
QDRANT_LOCAL_PATH=/tmp/qdrant-dbandCOLLECTION_NAME=test-collectionin the environment first)This issue was filed by an automated MCP spec-conformance sweep. If this turns out to be a false positive (e.g. specific to how the test harness drives the handshake), please feel free to close it — no offense intended, just flagging what the suite found in case it's useful.