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

[hasmcp-dev]

An automated MCP protocol conformance sweep using @hasmcp/mcp-spec-test found that android-mcp rejects requests sent before the client completes the MCP handshake, including the server/discover capability-discovery request and a version-less tools/list. The spec expects server/discover (and a couple of other pre-handshake checks) to be answerable without an initialized session; this server instead returns -32602 Invalid request parameters (or times out entirely for the very first, session-less call) for all of them, which cascades into 22 additional checks being skipped because the suite can no longer determine what the server supports. This was tested against spec revision 2026-07-28. Note: the same server negotiates an older revision, 2025-11-25, and when pinned to that revision every checkable case passes (0 failures) — so this looks like a revision-specific gap rather than a systemic bug, and no separate issue is being filed for 2025-11-25.

Conformance report

MCP 2026-07-28 conformance report
target uvx --python 3.13 android-mcp
transport stdio
supported 2026-07-28, 2025-11-25

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"} 0 !== 200
✗ 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
– tools/call on an unknown tool is an error, not a crash
– tools/call returns a schema-conformant CallToolResult
– prompts/list returns schema-conformant prompts
– prompts/get returns messages with a role and content
– resources/list returns schema-conformant resources
– resources/templates/list returns schema-conformant templates
– resources/read returns contents for every sampled resource
– resources/read on an unknown uri is an error
– following nextCursor terminates and does not repeat a page
– 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
– an unsupported version is rejected with the supported list
– 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
– cacheable list results carry the schema-required cache hints
– results identify the server in _meta
– 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
– the acknowledgment carries the subscription id for correlation
– a listen requesting no notification types is not a subscription to everything
– 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)

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

Summary
7 passed 7 failed 22 not verified
36 cases applied, in 25259ms

Verdict: not conformant — 7 requirements violated.

How to reproduce

With Docker:

docker pull hasmcp/mcp-spec-test:latest
docker run --rm hasmcp/mcp-spec-test --spec-version 2026-07-28 -c "uvx --python 3.13 android-mcp"

(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 --spec-version 2026-07-28 -c "uvx --python 3.13 android-mcp")

Without Docker (npx):

npx @hasmcp/mcp-spec-test@latest --spec-version 2026-07-28 -c "uvx --python 3.13 android-mcp"

---

This issue was generated by an automated MCP conformance sweep. Please feel free to close it if it doesn't apply to your setup or turns out to be an environment-specific artifact (e.g. no connected Android device — the failures here occur before any device-dependent tool is invoked, but it's worth double-checking on your end).