Conformance witness · observation, not accusation · recomputable

Tool-surface change observed — x402-bazaar-rank.x402-bazaar-rank-worker.workers.dev

Endpoint: https://x402-bazaar-rank.x402-bazaar-rank-worker.workers.dev/mcp

Version string served, unchanged across both observations: 0.2.0

Change first observed: 2026-10-18T19:40:08.560Z

Finding: CLASS_SUSPENDED_CRITICAL

Surface expanded without a version change, and at least one new tool takes an action (writes, sends, moves money, or deletes).

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 later enumeration but not the earlier (23):

• best_service_for_task
• buy_brandwatch ← takes an action
• buy_brandwatch_monthly ← takes an action
• buy_dao_report ← takes an action
• buy_dao_report_yearly ← takes an action
• buy_discovery_listing ← takes an action
• buy_lead_list ← takes an action
• buy_lead_list_500 ← takes an action
• buy_market_report ← takes an action
• check_email_address
• check_email_batch
• domain_report
• domain_report_batch
• sanctions_screening
• sanctions_screening_batch
• sec_filings
• sec_filings_batch
• token_risk
• url_uptime_ping
• url_uptime_ping_batch
• wallet_balance
• wallet_balance_batch
• wallet_risk

Why this may matter to your users

A client that pinned 0.2.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.

In this case 8 of the new tools take an action rather than returning data (buy_brandwatch, buy_brandwatch_monthly, buy_dao_report, buy_dao_report_yearly, buy_discovery_listing, buy_lead_list, buy_lead_list_500, buy_market_report),

so the difference between the approved set and the served set is not only informational.

Verify this yourself

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

curl -s -X POST 'https://x402-bazaar-rank.x402-bazaar-rank-worker.workers.dev/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://x402-bazaar-rank.x402-bazaar-rank-worker.workers.dev/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:

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

What this report does NOT say

• It does not allege a breach, compromise, or wrongdoing. An intentional untracked

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

• It does not assert the new tools are insecure. It asserts only that they appeared

under an unchanged version string.

• We enumerate anonymously, so tools behind authentication are invisible to us.

Absence from our view is not absence from your server.

• Two observations bound when the change was visible, not when it shipped.

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.266Z from observations dated 2026-10-18T19:40:08.560Z.*