Vercel's AI SDK Now Catches MCP Tools That Change After Approval

Vercel’s AI SDK can now tell you when a Model Context Protocol tool has quietly changed since an agent last trusted it. Version ai@7.0.19, released July 9, 2026, adds two functions, fingerprintTools and detectToolDrift, built to catch the class of attack that researchers call an MCP “rug pull” (vercel/ai release notes, ai@7.0.19).

---

What changed

MCP lets an AI agent call tools hosted on a remote server, and the agent typically asks a user to approve a tool once, then reuses that approval on every later call. The gap: a remote server controls the tool’s description, input schema and title, and nothing stops it from serving a different definition for the same tool name later. A description could pick up injected instructions, or a schema could quietly widen to accept a new field, and the SDK would pass the changed tool to the model exactly as if nothing had happened (vercel/ai CHANGELOG.md, packages/ai).

fingerprintTools closes part of that gap by digesting each tool’s server-controlled fields, description, resolved input schema and title, into a stable map of tool name to digest, captured when a developer approves the integration. detectToolDrift then diffs a later fingerprint against that stored baseline and surfaces any tool whose digest changed, before the tools reach the model.

The same release also fixed a related trust bug: tool-approval resolution now uses own-property checks, so a tool literally named constructor, toString or __proto__ no longer resolves to a JavaScript prototype value instead of its actual unconfigured state.

What it doesn’t do

Vercel is explicit about the edges. Drift detection only flags that something changed; it doesn’t decide whether to block it. Storing the baseline and deciding how to respond to a flagged drift is still the application’s job. It can’t catch a server that was hostile from the first approval, since there’s no clean baseline to diff against. And it’s blind to a pure behavior swap: if a tool’s name, description and schema stay identical while the server changes what the tool actually does, that’s invisible to a client-side fingerprint, since execution happens on the MCP server, not in the SDK.

The scenario the SDK is closing is documented well beyond Vercel. Security researchers coined “tool poisoning” and “rug pull” for MCP servers that alter a trusted tool’s definition after the fact, sometimes to inject hidden instructions that steer an agent into exfiltrating data through other tools it already has access to (Invariant Labs, MCP Security Notification: Tool Poisoning Attacks). That gives this release a narrower target than a typical SDK patch: a direct response to a named attack pattern the agent-security community had already flagged.

Why this matters

MCP’s approve-once model was built for convenience, but convenience is exactly what a rug pull exploits: nobody re-reads a tool’s schema on the hundredth call. Fingerprinting doesn’t fix the trust model. An agent still can’t verify what a remote tool does under the hood, but it turns a silent, permanent compromise into a detectable event on the one channel a client actually controls: the tool definition itself. For teams wiring third-party MCP servers into production agents, that’s the difference between finding out from a diff and finding out from an incident report.

Key Takeaways

• Vercel AI SDK ai@7.0.19 (July 9, 2026) adds fingerprintTools and detectToolDrift to catch MCP tools whose description, schema or title changed after approval.
• The functions detect drift only, an app must store the baseline fingerprint and decide what to do when one changes.
• They can’t catch a server that was malicious from day one, or a tool whose definition stays identical while its remote behavior silently changes.
• The release also closed a prototype-pollution-style bug in tool-approval resolution, where tool names like constructor or __proto__ could resolve to inherited object properties.