What's the security concern with dynamically changing tool descriptions after installation?
Quick Answer
If a server can change a tool's description, schema, or behavior after a user has already approved it — without triggering any re-approval — that's the mechanism behind the "rug pull" attack covered earlier: trust granted once, under one set of conditions, silently carried forward to a different (potentially malicious) set of conditions later. This is a particular concern for servers that fetch their tool definitions from a remote source at runtime (rather than shipping a fixed, versioned definition), since the operator of that remote source could push a change at any time, to any installed instance, without the end user taking any new action or seeing any new prompt. Mitigation requires hosts to track what was actually approved (ideally by hashing or diffing the tool definition, not just its name) and re-prompt on meaningful changes, and requires users/organizations to prefer servers whose tool definitions are pinned to an auditable, versioned release rather than mutable at the server operator's discretion.
Detailed Answer
This question is really about the lifecycle risk of trust decisions, not the point-in-time risk. The same tool you correctly evaluated and approved on day one isn't guaranteed to be the same tool a month later.
Why this is worse than a first-time-malicious tool
A tool that's malicious from the start at least has a chance of being caught during initial review, by the user or an automated scanner. A tool that's initially benign and changes later exploits the fact that the review already happened and trust was already granted. There's no natural moment prompting anyone to look again, unless the host specifically builds one in.
Where the risk concentrates
- Servers with remotely-fetched, mutable tool catalogs. If
tools/listisn't backed by a fixed, versioned artifact but by a live database the server operator controls, that operator — or anyone who compromises their infrastructure — can change behavior for every installed user simultaneously, with no code review, no new install step, no new approval prompt by default. - Package registries without integrity pinning. If a host launches a server via
npx package-namewithout pinning an exact version, the nextnpxinvocation can silently pull a newer, and possibly compromised, release.
Mitigations
Consent in MCP shouldn't be a one-time gate a server passes through once and is trusted forever after. It should be revalidated whenever what's being trusted actually changes:
Host-side:
- Hash/fingerprint each tool's full definition (name + description + schema)
at approval time
- On every connection, compare the current definition's hash against
what was approved
- If it changed, re-prompt for consent rather than silently proceeding
Server/package distribution:
- Pin exact versions in host configs (npx package@1.4.2, not npx package)
- Publish through a registry with integrity checks (lockfiles, checksums)
- Keep an auditable changelog for tool behavior changes