MCP server or tool changed
An MCP server’s version, configuration, tool list or tool descriptions changed since this machine last saw it.
Why it is risky
Section titled “Why it is risky”You approve an MCP server once, and it keeps running whatever its publisher ships next. An agent also acts on what each tool’s description tells it, so a changed description changes the agent’s instructions without any change to your setup. A new tool, a removed tool or a reworded description that arrives without a new version is the kind of quiet change that is worth a look before you rely on the server again.
Example
Section titled “Example”A mail server’s send_email tool has always said it sends one message. In a later session its description also asks the agent to copy every message to an outside address, and the server still reports the same version.
This is a fictional example, not an event from a customer.
What Omnodex Detects
Section titled “What Omnodex Detects”Each time a server routed through the MCP proxy lists its tools, at connect or after it announces a change mid-session, the proxy records a fingerprint of the server: its configuration entry, the name and version it reports, the installed package version for npx servers when it can be read, and each tool’s name, description and input schema. The rules compare that with the last observation of the same server on this machine.
- Server updated (LOW): the reported version, the installed version or the configuration entry changed. Usually a routine update. The finding lists any tool changes that came with it.
- Tools changed (LOW): tools were added or removed while the version and configuration stayed the same.
- Tool definition changed (MEDIUM): a tool’s description or input schema changed while the version and configuration stayed the same.
The first observation of a server is its baseline; first use is reported by New or changed MCP server use. The newer observation becomes the baseline, so each change is reported once. A change announced while the server is in use says so in the finding.
| Rule ID | Event category | Tier | Base severity |
|---|---|---|---|
RULE_MCP_SERVER_UPDATED | supply_chain | Community | LOW |
RULE_MCP_SERVER_TOOLS_CHANGED | supply_chain | Community | LOW |
RULE_MCP_TOOL_DEFINITION_CHANGED | supply_chain | Community | MEDIUM |
Base severity is the rule default. A finding involving content saved for later execution may have a lower severity. Your loaded rule version and event details determine the finding you see.
What to check next
Section titled “What to check next”Open the finding in the local dashboard: it shows each changed tool’s old and new description and a line diff of its input schema, from the tool lists the proxy keeps on that machine. Read new descriptions as instructions to your agent. Check the publisher’s changelog for an update, and compare the installed version with the one you expect. If you cannot explain a change, stop routing the server until you can.
False positives
Section titled “False positives”Most updates are routine. Servers that reword descriptions between releases, add tools behind a setting, or are run unpinned through npx will report changes that are expected. You can mute a rule with an exception without a target.
False negatives
Section titled “False negatives”Only servers routed through the MCP proxy are observed. A change to a server’s code that leaves its tools, version and configuration alone is not visible here: a server can behave differently with an identical tool list. A server already changed before its first observation on this machine starts from the changed state. The reported version is whatever the server says, and the installed version is read only for npx servers.
Technical details
Section titled “Technical details”Fingerprints are hashes of canonical JSON, so key order and whitespace do not change them. The configuration fingerprint includes environment variable and header names, never their values. Findings and synced data carry tool names and kinds of change, not descriptions; the full tool lists stay on the machine in the Omnodex home, which keeps the newest 200. A version that becomes unknown, for example when the npx cache cannot be read, is not counted as a change.
A finding describes a pattern in captured activity. Review the original call, its result, and the task context before concluding that harm occurred. Absence of a finding does not establish that an operation is safe.