Nothing stops anyone from publishing an MCP server called “Notion” or “Slack” that has no relationship with either company. There’s no app store review, no name registry, no verified-publisher badge built into the protocol itself — a server’s name is just a string someone typed into a config file. Here’s how to tell a real integration from one that only looks like it, before you hand it an OAuth grant.
Why this works as an attack in MCP specifically
In a normal app store, a listing goes through some review, and the name is at least loosely tied to a verified developer account. MCP has none of that by default. A client config is just a URL and a label you choose yourself, and public registries generally accept submissions without confirming the submitter actually works for the company the server claims to represent. OWASP’s MCP Top 10 groups this under supply chain attacks and dependency tampering — a typo-squatted or impersonating server is a compromised dependency you installed on purpose, thinking it was the real thing.
The payoff for an attacker is bigger than with a fake browser extension, too. An MCP server doesn’t just run in a sandboxed tab — once connected, its tools run with whatever your AI client is willing to call, on your behalf, often with a real OAuth token behind them.
Signals a server isn’t what it claims to be
- The URL doesn’t match the vendor’s own domain. A legitimate remote server for a SaaS product is almost always hosted on that company’s domain (
mcp.sentry.dev, not a random subdomain or a third-party host). If the vendor’s own docs don’t list the URL you’re about to connect, that’s the single strongest red flag. - The vendor’s official docs don’t mention an MCP server at all. If a company hasn’t announced or documented a remote MCP server anywhere on its own site, a listing elsewhere claiming to be “the official X MCP server” is a claim you can’t verify — treat it as unverified until the vendor says otherwise.
- No maintainer, no history, no way to contact anyone. A brand-new listing with an anonymous maintainer and no track record is a different risk profile from a server with a public repository and a response history on issues.
- The tool list doesn’t match the stated purpose. A server claiming to be a read-only integration that also exposes write, delete, or arbitrary-execution tools is worth stopping on — see the tool-matching step in vetting a server before you connect it.
- The OAuth consent screen doesn’t redirect to the real vendor. If you click “Connect” expecting to authenticate against a company’s own login page and land somewhere else instead, stop the flow. A real integration’s OAuth step happens on the vendor’s own domain, not a look-alike.
The name is the easiest thing to fake — check the domain instead
Every signal above reduces to one habit: don’t trust the label a server gives itself, trust what you can independently verify. A display name is free to set. A domain that resolves to infrastructure the real company controls is not. Before connecting any server tied to an account you care about — billing, source code, customer data — go find the vendor’s own documentation and confirm the URL matches, the same way you’d check a link before entering a password on it.
Where a directory or gateway helps — and where it doesn’t
This is one of the reasons a curated directory of MCP servers is worth using over copying a URL from a random blog post or forum thread: every entry in gate’s catalog is one we’ve actually connected to and probed ourselves, not just linked to on trust. gate’s free MCP security scanner also checks provenance — whether a server you paste in is on that verified list — alongside its checks for prompt injection and hidden instructions in tool descriptions, which is a separate but related risk covered in how tool poisoning works.
None of that replaces checking the vendor’s own site yourself for anything you haven’t seen listed anywhere trustworthy before. A directory can tell you a server is on its verified list; it can’t make a server real that isn’t. Provenance is a signal, not a guarantee — use it alongside the checklist above, not instead of it.
The bottom line
A server’s name tells you nothing on its own — anyone can type “Notion MCP Server” into a config file. What actually tells you a server is real is the domain it runs on, whether the vendor documents it themselves, and whether its OAuth screen takes you to the vendor’s own login. Check those three things before you connect anything to an account that matters, the same way you’d check a link before you typed a password into it.