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

[hasmcp-dev]

Re-testing turned up a different picture from the originally reported issue: the "no index found" stdout-corruption theory doesn't actually hold up — that warning is written to stderr, not stdout, and a manually-sent initialize request gets a clean, well-formed JSON-RPC response even with a stale/missing index. (The original 10-violation "server exited" result in our first pass looks like it was an artifact of our own launch-command quoting, not a real server bug — apologies for the false alarm there.) With a corrected launch and pinned to spec revision 2026-07-28, the real, reproducible finding is that the new pre-handshake server/discover method either times out or returns a JSON-RPC -32602 Invalid request parameters error, and a version-less tools/list/handshake request is likewise rejected with -32602 instead of being served on a default version — 7 requirements violated. The plain official-SDK handshake and tools/list still work fine (see "Official SDK interop" passes below), so this looks like a gap in support for the newer revision's server/discover capability specifically, not a broader server problem.

Conformance report

MCP 2026-07-28 conformance report

Verdict: not conformant — 7 requirements violated.

Target	sh -c "pip install --break-system-packages 'roam-code[mcp]' && roam mcp"
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
Duration	25679ms
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
  server/discover unexpected JSON-RPC error: {"code":-32602,"message":"Invalid request parameters","data":""}
• server/discover is a CacheableResult with usable cache hints
  server/discover unexpected JSON-RPC error: {"code":-32602,"message":"Invalid request parameters","data":""}
• server/discover reports server identity and capabilities
  server/discover unexpected JSON-RPC error: {"code":-32602,"message":"Invalid request parameters","data":""}
• server/discover is stable across calls within its own TTL
  server/discover unexpected JSON-RPC error: {"code":-32602,"message":"Invalid request parameters","data":""}
• server/discover advertises a revision this suite supports
  server/discover unexpected JSON-RPC error: {"code":-32602,"message":"Invalid request parameters","data":""}

Version negotiation

• a request with no version at all is served on the default
  a version-less tools/list must be served, not refused: {"code":-32602,"message":"Invalid request parameters","data":""}

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 (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
• a stock official-SDK client completes the handshake
• the handshake settles on a revision inside the supported window
• a stock official-SDK client can list tools

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 \"pip install --break-system-packages 'roam-code[mcp]' && roam mcp\"" --spec-version 2026-07-28

(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 \"pip install --break-system-packages 'roam-code[mcp]' && roam mcp\"" --spec-version 2026-07-28)

Without Docker (npx):

npx @hasmcp/mcp-spec-test@latest -c "sh -c \"pip install 'roam-code[mcp]' && roam mcp\"" --spec-version 2026-07-28

---

This issue was generated by an automated MCP conformance sweep across public MCP server repos. If server/discover/the 2026-07-28 revision isn't a support target yet, feel free to close it — it's meant as a heads-up, not a demand.

[Cranot]

Thanks for the detailed checks and the follow-up clarification. This exposed an important distinction we hadn't made clear enough: Roam's tested MCP stack currently supports the handshake used through the November 2025 revision, not the newer July 2026 lifecycle.

I'm adding a way to see the installed protocol support in roam mcp --compat-profile all, along with a compatibility guide and real connection tests. A fresh-install check also caught a separate problem: our open-ended dependency ranges could pull in the newly released MCP 2 / FastMCP 4 stack before Roam's integration had been migrated. That is being corrected in the release currently under test.

I'm leaving this open as a clear record of the newer-protocol gap. I don't want to call the July checks fixed just because the older handshake passes. The ordinary connection working in your follow-up is consistent with what I'm seeing locally. Appreciate you helping make the support boundary clearer.

[Cranot]

A quick follow-up: your report prompted us to check actual tool calls too,
not just whether the server starts and lists its tools.

We've repaired cases where a search could hang, where a project's own
roam.py could be picked up instead of Roam, and where Windows could misread a
supplied patch with non-English filenames. The new checks use real client
connections on Windows and Linux, including an empty search and a second request
on the same connection. Roam also reports its own version during startup now.

These are landed source fixes, not a claim that the newer July 2026
discovery/lifecycle is supported. That part remains open; our
compatibility notes
spell out the current boundary. Thanks for pushing us to make the distinction
clearer.