Conformance witness · observation, not accusation · recomputable

Tool-surface change observed — agent-control.net

Endpoint: https://agent-control.net/api/v1/mcp

Version string served, unchanged across both observations: 1.0.0

Change first observed: 2026-10-02T01:40:04.630Z

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 (3):

• crm.write ← takes an action
• email.send ← takes an action
• slack.post ← takes an action

Why this may matter to your users

A client that pinned 1.0.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 3 of the new tools take an action rather than returning data (crm.write, email.send, slack.post),

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://agent-control.net/api/v1/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://agent-control.net/api/v1/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.152Z from observations dated 2026-10-02T01:40:04.630Z.*