Customers discover MCPs through company and product names. But a familiar name does not prove the publisher, endorsement, or security quality of the code they install.
A company can secure its official MCP repositories and still have customers install unrelated packages named after its products. Those servers may request the company’s API token, access customer workstations, or expose tools that act on the company’s services. A resulting incident can be attributed to the brand even when the company never published the code.
Our catalog resolves 71,584 active listings into 71,565 deduplicated implementations, then joins name and product associations with repository owner, package publisher, exact version, observed tools, and runtime findings. That combination exposes the difference between brand-associated and brand-owned.
In the Microsoft-associated surface, our production evidence has already identified third-party MCPs using Microsoft product terms—including Planner, VS Code, and Windows—with reproduced findings on exact source revisions. The evidence does not claim Microsoft authored those projects; it shows why Microsoft’s customer-protection team needs visibility into them.
This is not a one-time brand search. It is a continuously updated external MCP attack-surface monitor: discovery, attribution, exact-version verification, capability intelligence, and defensible response evidence in one workflow.