MCP spec conformance: 10 requirement(s) violated (via @hasmcp/mcp-spec-test) — spec 2026-07-28

[hasmcp-dev]

Running @hasmcp/mcp-spec-test against this repo's Part 2 server (server_part_2.py, launched via uv run) against MCP spec revision 2026-07-28, the server never responds to the initial handshake at all — every request (including a plain initialize from a stock official MCP SDK client) times out with no response within 10 seconds, so the suite can't verify anything downstream of the handshake either.

Conformance report

MCP 2026-07-28 conformance report

Verdict: not conformant — 10 requirements violated.

Target	sh -c '[ -d /tmp/llm ] || git clone --depth 1 https://github.com/microsoft/lets-learn-mcp-python /tmp/llm; cd /tmp/llm && uv run server_part_2.py'
Transport	stdio
Revision tested	2026-07-28
Revisions supported	2026-07-28, 2025-11-25
Passed	4
Failed	10
Not verified	22
Cases applied	36
Duration	123062ms
Generated	2026-08-24T15:40:04.313Z
Tool	@hasmcp/mcp-spec-test 0.1.1

Failed (10)

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"}

0 !== 200

• 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"}

0 !== 200

Official SDK interop

• a stock official-SDK client completes the handshake
  MCP error -32001: Request timed out
• the handshake settles on a revision inside the supported window
  initialize must return a protocolVersion, got undefined
• a stock official-SDK client can list tools
  MCP error -32000: Connection closed

Not verified (22)

skipped; a skip is not a pass

Capability methods

• tools/list returns schema-conformant tools
  cannot determine what the target supports — server/discover returned no result (status 0)
• tools/call on an unknown tool is an error, not a crash
  cannot determine what the target supports — server/discover returned no result (status 0)
• tools/call returns a schema-conformant CallToolResult
  cannot determine what the target supports — server/discover returned no result (status 0)
• prompts/list returns schema-conformant prompts
  cannot determine what the target supports — server/discover returned no result (status 0)
• prompts/get returns messages with a role and content
  cannot determine what the target supports — server/discover returned no result (status 0)
• resources/list returns schema-conformant resources
  cannot determine what the target supports — server/discover returned no result (status 0)
• resources/templates/list returns schema-conformant templates
  cannot determine what the target supports — server/discover returned no result (status 0)
• resources/read returns contents for every sampled resource
  cannot determine what the target supports — server/discover returned no result (status 0)
• resources/read on an unknown uri is an error
  cannot determine what the target supports — server/discover returned no result (status 0)
• following nextCursor terminates and does not repeat a page
  cannot determine what the target supports — server/discover returned no result (status 0)
• an invalid pagination cursor is rejected (SHOULD)
  cannot determine what the target supports — server/discover returned no result (status 0)

Version negotiation

• a version declared in _meta is accepted
  cannot determine what the target supports — server/discover returned no result (status 0)
• an unsupported version is rejected with the supported list
  cannot determine what the target supports — server/discover returned no result (status 0)
• clientInfo is optional (SHOULD, not MUST)
  cannot determine what the target supports — server/discover returned no result (status 0)

Result envelope

• every result carries the required resultType
  cannot determine what the target supports — server/discover returned no result (status 0)
• cacheable list results carry the schema-required cache hints
  cannot determine what the target supports — server/discover returned no result (status 0)
• results identify the server in _meta
  cannot determine what the target supports — server/discover returned no result (status 0)
• a client on an older version receives no newer-revision fields
  cannot determine what the target supports — server/discover returned no result (status 0)

subscriptions/listen

• subscriptions/listen acknowledges only the opted-in notification types
  cannot determine what the target supports — server/discover returned no result (status 0)
• the acknowledgment carries the subscription id for correlation
  cannot determine what the target supports — server/discover returned no result (status 0)
• a listen requesting no notification types is not a subscription to everything
  cannot determine what the target supports — server/discover returned no result (status 0)
• a cancelled subscription ends with a conformant teardown result, if it sends one
  cannot determine what the target supports — server/discover returned no result (status 0)

Passed (4)

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

subscriptions/listen

• schema sanity: SubscriptionsListenResult requires _meta and resultType

How to reproduce

With Docker:

docker pull hasmcp/mcp-spec-test:latest
docker run --rm hasmcp/mcp-spec-test -c "sh -c '[ -d /tmp/llm ] || git clone --depth 1 https://github.com/microsoft/lets-learn-mcp-python /tmp/llm; cd /tmp/llm && uv run server_part_2.py'"

(or, if that image can't run on your platform: git clone https://github.com/hasmcp/mcp-spec-test && cd mcp-spec-test && docker build -t mcp-spec-test . && docker run --rm mcp-spec-test -c "sh -c '[ -d /tmp/llm ] || git clone --depth 1 https://github.com/microsoft/lets-learn-mcp-python /tmp/llm; cd /tmp/llm && uv run server_part_2.py'")

Without Docker (npx):

npx @hasmcp/mcp-spec-test@latest -c "sh -c '[ -d /tmp/llm ] || git clone --depth 1 https://github.com/microsoft/lets-learn-mcp-python /tmp/llm; cd /tmp/llm && uv run server_part_2.py'"

This was generated by an automated conformance sweep. The maintainer is welcome to close this if it doesn't apply (e.g. an environment-specific false positive) — the server took over 2 minutes to reach this point even with dependencies pre-cached, so it's also possible the harness's 10s per-request timeout is simply too tight for this particular sample's startup profile rather than a protocol bug.