Conformance witness · observation, not accusation · recomputable

Tool-surface change observed — mcp.grabbitapp.com

Endpoint: https://mcp.grabbitapp.com/api/mcp

Version string served, unchanged across both observations: 2.1.0

Change first observed: 2026-10-03T18:56:02.202Z

Finding: VARIATION_NOTICE

Variation notice — the served surface changed without a version change, but the set of things the server can do did not grow.

What we observed

Two anonymous tools/list enumerations of the endpoint above, at different times.

The serverInfo.version string was byte-identical in both. The tool set was not.

Tools present in the earlier enumeration but not the later (1):

Why this may matter to your users

A client that pinned 2.1.0 and reviewed the tool list at

pin time is, today, being served a different list under the same version string. Gateways

and MCP hosts that cache an approved tool set per version will not re-request approval,

because from their side nothing announced a change.

Verify this yourself

This is a plain MCP handshake. No credentials, nothing of ours required:

curl -s -X POST 'https://mcp.grabbitapp.com/api/mcp' \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -H 'MCP-Protocol-Version: 2025-06-18' \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"check","version":"1"}}}'
# then, with the returned Mcp-Session-Id:
curl -s -X POST 'https://mcp.grabbitapp.com/api/mcp' \
  -H 'Content-Type: application/json' -H 'Accept: application/json, text/event-stream' \
  -H 'MCP-Protocol-Version: 2025-06-18' -H 'Mcp-Session-Id: <id>' \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}'

Our surface hashes over the sorted tool names plus sorted input-schema property names:

observationsurface hash
earlier1d19164adc6d50f98615064f4309767b54ac0906a2dda624056ac85ab3e2c0b3
later54c0d1b7cc59757d6d013a9134e16f828ed412a95f83aa9d1cac40c0eebf674a

If your own enumeration disagrees with the later hash, we are wrong and we want to hear it.

What this report does NOT say

deploy produces exactly this signal, and that is the most likely explanation.

under an unchanged version string.

Absence from our view is not absence from your server.

Method

Unannounced periodic re-enumeration of a live MCP population — we ask the endpoint

directly on a schedule rather than waiting to be notified. Relevant because only

6.4% of live MCP servers have a working channel to announce a change at all

(69.1% never declare tools.listChanged; of those that do, most expose no

server-initiated stream to send it on). A change like the one above cannot reach a

notification-based monitor, which is why it is normally invisible.


*StillOS Digital Holdings — continuous conformance witness for MCP servers.*

*Report generated 2026-10-30T17:18:50.212Z from observations dated 2026-10-03T18:56:02.202Z.*

Is this your server?

If anything here is wrong — a change you did not make, a hash that does not match, a host that was reassigned to you — tell us and we will correct or remove this page. No proof required to request removal; the record is whatever we observed, and your word about your own host outranks it.

Free. Goes to a human. Or email stillmarcus24@gmail.com.