A blog post by Akshay Chugh surfaced on Hacker News this week documenting something uncomfortable: the official Vercel plugin for Claude Code was sending prompt data to Vercel’s telemetry infrastructure. The post has 267 points and 109 comments, which tells you the reaction was more than the usual background noise about privacy.
The story matters, but not primarily because of what Vercel did. It matters because the incident exposes a structural gap that the entire MCP ecosystem shares, and one that Anthropic has not yet solved.
What MCP Plugins Actually Receive
Claude Code’s plugin system is built on the Model Context Protocol, an open specification Anthropic published in late 2024. MCP lets third-party services expose capabilities to Claude through three primitives: tools (callable functions), resources (readable data), and prompt templates. When you install an MCP server and use it within a session, Claude can invoke that server’s tools as part of answering you.
The critical detail is how a tool invocation works at the protocol level. When Claude calls an MCP tool, it sends a JSON-RPC request with a params object containing the tool name and an arguments map. Those arguments are whatever Claude decides to pass based on the tool’s declared schema. A tool that declares an argument called description will receive natural language from Claude, drawn from the user’s intent. A tool with a query argument gets a query. A tool that accepts context may get excerpts from files Claude has read during the session.
Here is a simplified example of what an MCP tool call looks like over the wire:
{
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"name": "create_deployment",
"arguments": {
"projectName": "my-app",
"description": "Deploy the latest build with the new auth changes I just made"
}
}
}That description field contains the user’s words. Once the MCP server process receives that payload, it can do anything with it. Log it, forward it, send it to an analytics endpoint. There is no filtering layer in the Claude Code client, no sanitization, no differential privacy. The MCP specification itself places no constraints on what a server does with the arguments it receives.
This is the architectural fact that the Vercel situation makes concrete. The plugin received tool call arguments containing user-written text, and it apparently forwarded that data to Vercel’s telemetry system without making that obvious to the user.
The Trust Model That Was Never Designed
When you install a browser extension, Chrome’s permission model forces the extension to declare what it can access. When you install a VSCode extension, it operates in a sandboxed process with constrained filesystem access. These models are imperfect, but they at least force a moment of explicit disclosure.
MCP has no equivalent. Installing a plugin via claude mcp add vercel-mcp generates no permission prompt describing what data the server will receive or transmit. The MCP specification defines transport security and capability negotiation, but nothing about data handling policies, telemetry disclosure requirements, or what a server is permitted to do with arguments it receives.
Anthropix’s Claude Code documentation describes how to configure MCP servers but is silent on the privacy implications of doing so. The implicit assumption seems to be that installed MCP servers are trusted, roughly analogous to running any local process on your machine. That framing made some sense when MCP servers were simple local tools. It makes less sense when the servers are commercial products operated by companies with their own data collection interests.
Vercel is not unusual in this respect. Most developer tools collect telemetry by default. Vercel’s own CLI has had a VERCEL_TELEMETRY_DISABLED environment variable for years, and they have generally been transparent about what that telemetry includes. The problem with the MCP plugin is that the same telemetry posture from the CLI carried over into a context where it collects something qualitatively different: the text of what users are saying to their AI assistant, not just which commands they ran.
Why This Is Different From Normal CLI Telemetry
There is a meaningful difference between telemetry that records user ran deployment command and telemetry that records user said: "deploy this with the new payment flow changes before the demo tomorrow". The first is behavioral analytics. The second captures intent, context, and potentially sensitive business information.
Developers using Claude Code for work are often working on proprietary codebases. They ask Claude things they would not post publicly: questions about architecture decisions, requests to explain security-sensitive code, instructions that reference internal project names, deadlines, or team dynamics. Those fragments end up in tool call arguments because Claude is trying to be helpful, not because the user consciously chose to share them with a third party.
The security research community has been flagging this class of risk since MCP became widespread. Trail of Bits published findings on prompt injection via MCP resources, where a malicious server could return content that hijacks Claude’s behavior. Data exfiltration via tool schemas is a related but distinct threat: a server that declares a free-text argument will reliably receive natural language from Claude, and that language will reflect what the user is working on.
The ToolPoisoning research from Invariant Labs documented this pattern formally: MCP tool schemas are a surface for extracting context from the model that the user never intended to transmit.
What the Ecosystem Needs to Do
Anthropix should add a telemetry disclosure requirement to MCP server manifests. Before a server is listed in any official directory, it should be required to declare whether it transmits tool arguments or conversation fragments to external systems, under what conditions, and how to opt out. This is analogous to what the Chrome Web Store requires from extensions that handle user data.
Claude Code itself should surface this information. When a tool call is about to be dispatched to a remote server, the client could show which arguments will be sent and remind the user that the server is a third-party process. This would not need to happen for every call, but it should happen the first time a new server receives data.
Users can take some steps now. You can review which MCP servers are installed with claude mcp list and audit each one’s source code if it is open. For commercial plugins, checking whether VERCEL_TELEMETRY_DISABLED=1 or an equivalent environment variable affects the MCP server behavior is worth doing. Running MCP servers that make outbound connections through a proxy or firewall rule lets you observe exactly what they transmit.
For teams using Claude Code in professional contexts, the practical answer right now is to treat every installed MCP server as a process with network access and the ability to receive fragments of your conversation. That is already true at the technical level; the Vercel situation just made it visible.
The Broader Pattern
The MCP ecosystem is growing quickly. Anthropic publishes a directory of servers, major developer platforms are building integrations, and the tooling is becoming a standard part of how people use Claude Code. That growth is happening faster than the trust infrastructure can keep up.
This is not an unusual situation in platform evolution. Browser extensions went through the same cycle: rapid adoption, a series of incidents involving malicious or careless data handling, and then a more mature permission model imposed by the platform. VSCode extensions have had similar growing pains. MCP is earlier in that cycle, which means the incidents are happening before the guardrails exist.
Vercel’s plugin collecting prompt fragments as telemetry is probably not malicious. It is probably the result of a telemetry system designed for a CLI being reused in a context where it collects richer data than intended. That distinction matters for assigning blame, but it does not change what got transmitted or what the disclosure failure means for users.
The right response is not to avoid MCP plugins entirely. The ecosystem has genuine value, and most servers are written by people who are not trying to collect your prompts. The right response is to build the infrastructure, disclosure requirements, and user-facing transparency that lets people make informed choices about what they install. That work belongs to Anthropic, and the Vercel incident is a reasonable prompt to get started on it.