The Domain Name Problem, Revisited
Remember the early days of the web? Anyone could register a domain that looked official. paypa1.com (with a "1" instead of an "l"). arnazon.com. Phishing domains that fooled even careful users.
We're watching the same pattern emerge with MCP servers.
Right now, if you want to give Claude access to Notion, you install a Notion MCP server. But who made that server? Is it official? Is it maintained? Has anyone audited the code?
The answer, often, is: who knows.
Why This Is Different From SDKs
"But we've always had third-party SDKs," you might say. "Anyone can publish a npm package called notion-unofficial-client. How is this different?"
It's different because of who's using it.
When a developer installs an unofficial SDK, they know (or should know) the risks. They can read the code. They understand the attack surface. They're making an informed technical decision.
But MCP users range from junior associates to C-suite executives. They're not reading source code. They're following a tutorial that says "install this MCP server to let Claude access Notion" and assuming it's legitimate.
The attack surface isn't just the software. It's the trust assumption.
The Prompt Injection Angle
It gets worse. MCP servers can inject content into Claude's context. That content shapes Claude's responses.
Emmanuel Paraskakis put it well in a recent discussion: an MCP server provider could inject prompts that subtly bias Claude's outputs. Not obviously wrong—just slightly tilted toward outcomes that benefit the server provider.
Imagine an "official-looking" Salesforce MCP server that, when you ask Claude to analyze your pipeline, subtly recommends switching to a competitor. Or an HR tool MCP server that injects prompts encouraging users to adopt policies that benefit a particular vendor.
This isn't theoretical. The incentives are there. The technical capability exists. The oversight doesn't.
What Providers Should Do
If you're a software company with an API, you should own your MCP server. Here's why:
1. Control the Narrative
If you don't publish an official MCP server, someone else will. And you won't control what it does, how it's maintained, or what it injects into user contexts.
2. Protect Your Users
Your users trust you with their data. That trust extends to how AI assistants interact with that data. An unofficial MCP server with security flaws reflects on your brand, not the anonymous developer who published it.
3. Get Ahead of the Standards
MCP is still evolving. The providers who engage now will shape how trust, verification, and security work in this ecosystem. The ones who wait will inherit whatever standards others establish.
What the Ecosystem Needs
Beyond individual providers, we need:
Verification mechanisms. A way to know an MCP server is official. Something like verified checkmarks, but backed by actual cryptographic proof.
Audit requirements. Transparency about what an MCP server can access, what it injects into context, and who maintains it.
Clear liability. When an unofficial MCP server causes harm, who's responsible? Right now, it's ambiguous.
User education. Users need to understand that installing an MCP server is granting capabilities, not just connecting services.
The Bottom Line
MCP is a net positive for the ecosystem. The ability for AI assistants to interact with real-world tools is genuinely useful. But we're in a land-grab phase where security and trust are afterthoughts.
If you're a software provider: own your MCP server before someone else does.
If you're a user: verify the provenance of every MCP server you install. If you can't verify it, assume it's suspect.
AI doesn't remove responsibility—it redistributes it. Right now, that responsibility is landing on users who don't know they're carrying it.
This reflects one of our core beliefs at Left Hook: AI doesn't remove responsibility, it redistributes it. As integration experts who've watched every platform transition for over a decade, we're tracking MCP closely. Let's talk if you're thinking through your MCP strategy.