10,000 ‘MCP servers’ later, your company still thinks AI connects to apps like Zapier — the silent standard war that will decide who gets breached (and who gets bought)
AI-to-app integration is quietly shifting from connector catalogs to protocol-based tool invocation via MCP. That change rewires where tools run, how data gets approved, and who absorbs security liability when things go wrong.
Key Points
- 1Recognize the shift: AI-to-app connectivity is moving from connector catalogs to protocol-based tool invocation via MCP servers and registries.
- 2Interrogate execution: stdio local MCP servers change the threat model—running near files and credentials—while remote servers enable stronger controls.
- 3Govern distribution: registries accelerate adoption but don’t validate safety; approvals, logging, and segmented policies decide breach risk and liability.
For two years, “AI automation” has meant something comfortably familiar inside companies: a language model on one side, business apps on the other, and a connector hub—Zapier, Make, n8n—standing in the middle like an air-traffic controller. That mental model still runs many real workflows. It also increasingly misdescribes where the market is heading.
A quieter shift is underway in 2025 and 2026: “AI-to-app connectivity” is being reframed as tool invocation through a protocol layer, not a catalog of bespoke connectors. The most prominent example is the Model Context Protocol (MCP)—an open protocol for how assistants discover and invoke tools, and how “MCP servers” expose tools, resources, and prompts.
OpenAI now documents “Connectors and MCP servers” as first-class options for models calling external tools via the Responses API, explicitly placing MCP alongside connector-style integrations. Developer environments that shape day-to-day AI work—such as Cursor and Windsurf—ship MCP client support as well. Standards transitions rarely announce themselves with fanfare. They show up first as a new menu item.
“The connector catalog is giving way to a protocol layer—and the security responsibilities are moving with it.”
— — TheMurrow Editorial
The stakes aren’t theoretical. Protocol details determine whether an integration runs as remote network calls or local processes, whether approvals are automatic or mandatory, and whether distribution happens through a curated marketplace or a sprawling registry. If MCP becomes the default path between models and tools, the industry is about to repeat a familiar story: browser extensions, package registries, mobile app stores—only this time, the “apps” can read your files, query your systems, and take actions on your behalf.
The old model: “AI + connector hub + SaaS apps”
The 2023–2024 model looked like this:
- A model produces an intent (“Create a ticket,” “Send the email,” “Update Salesforce”).
- A vendor-specific action layer translates that intent into an API call.
- Prebuilt connectors handle app-specific details.
Connector platforms bring real strengths. Centralized governance often means consistent auth patterns and predictable reliability. When something breaks, there’s a vendor with a support queue and an on-call schedule. Connector ecosystems also bias toward remote actions—less “run arbitrary code,” more “call a well-defined endpoint.”
That model’s weakness is subtle: it treats “tools” as products you subscribe to, not interfaces you can standardize. Catalogs don’t scale gracefully across every internal system, niche database, or bespoke workflow. When teams want the model to use internal tools, they either wait for the connector vendor or build a custom integration that lives off to the side.
“Connector catalogs are great at standardizing the common case. Protocols are how the uncommon case becomes normal.”
— — TheMurrow Editorial
MCP, plainly: what it is—and what it is not
MCP is not a single vendor’s connector marketplace. It is also not “agents” by itself. MCP doesn’t decide whether your system should take an action; it defines how the system asks for capabilities and how those capabilities are invoked.
A governance shift matters here. Anthropic announced it was donating MCP to the Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation, positioning MCP as a neutral standard rather than a proprietary moat. That move echoes earlier tech history: standards gain power not only through technical merit but through institutional trust.
Where MCP is already “real” for developers
Meanwhile, OpenAI’s platform documentation explicitly elevates MCP as part of the tool ecosystem: “Connectors and MCP servers” are described as ways to connect models to external capabilities via the Responses API. That’s not a side quest. That’s a platform-level signal.
Why the protocol framing changes the conversation
The transport detail that changes the risk profile
Transport choices have consequences:
- Remote HTTP endpoints broaden network exposure but keep execution on a server you can isolate and monitor.
- Local stdio servers can feel safer because they don’t expose a network service, but they often run on the developer machine or inside an IDE context—close to credentials, source code, and local files.
Local execution is convenient—until it isn’t
The transport evolution isn’t a headline, but it’s a security footnote worth treating like a headline. The execution model determines what your approvals mean, what your logging captures, and what your incident response can realistically reconstruct.
“Transport isn’t plumbing. Transport is policy.”
— — TheMurrow Editorial
From connector catalogs to registries: the new distribution layer
An official MCP Registry now exists and lists “production” servers. Third-party directories track and rank servers as well—FindMCP, BestMCP, and “awesome” lists on GitHub. These directories do what every distribution layer does: they reduce friction. A tool that once required a bespoke integration suddenly looks like a link you can paste.
Windsurf’s documentation even highlights sharing and adding MCP servers through registry pages, reinforcing the “one-click install” behavior that made browser extensions and package managers explode.
A big number—and why you should treat it carefully
Even as indicative signals, they support a broader observation: the ecosystem is scaling fast enough to attract the same problems every open distribution channel attracts—malicious uploads, sloppy security defaults, and dependency chains nobody fully audits.
The marketplace effect cuts both ways
- Winners: tool builders who can ship once and be usable across many clients.
- Winners: AI clients that can claim broad tool access without building connectors.
- Losers: teams that assume “listing” implies “vetted.”
- Losers: organizations that can’t govern what employees install locally.
Connector catalogs solved distribution with curation. Registries solve distribution with reach. Reach demands stronger trust signals than “it’s popular.”
Three integration primitives—and why they don’t fail in the same way
1) Traditional connectors (Zapier-like)
Risks still exist. Broad OAuth grants and mis-scoped access can lead to data exposure. Yet the default posture rarely involves running unknown code on your laptop.
2) Remote MCP servers (HTTP endpoints)
The crucial addition is an explicit approval mechanism: OpenAI notes that by default, approvals are required before data is shared with connectors or remote MCP servers. That is a strong design choice. Approvals create a human checkpoint that connector flows sometimes bury under a single OAuth grant.
Remote MCP servers can also be managed like any other service: network controls, authentication, logging, and dedicated runtime environments.
Key Insight
3) Local MCP servers via stdio (often inside IDE context)
Practical implication: security teams should not lump “MCP” into one bucket. Remote servers, local servers, and connector hubs need different governance.
Security and governance: who holds the bag now?
OpenAI’s default approval requirement for sharing data with connectors or remote MCP servers is one of the more concrete safety signals in the current tool ecosystem. It suggests a design direction: make data sharing explicit at the moment it happens, not implicit via a permission granted weeks ago.
Still, approvals are only as good as the surrounding system:
- Are approvals readable and specific, or vague and habituating?
- Are they enforced consistently across tool types?
- Are there logs that capture what was shared, with whom, and why?
The trust problem looks like every trust problem
A balanced view matters. Open protocols enable competition and reduce lock-in. They also multiply the number of parties who can ship integrations, which increases the number of parties who can make mistakes—or behave badly.
What this looks like in real life: two case studies
Case study 1: The developer in an IDE
The payoff is obvious: fewer manual steps, less glue code, faster iteration.
The risk is equally obvious: local servers sit close to secrets and source. The MCP spec’s emphasis on stdio transport (replacing earlier HTTP+SSE approaches) is a reminder that many integrations may run as local processes rather than remote services. That changes the threat model from “API misuse” to “local execution trust.”
Case study 2: The enterprise integrating internal systems
Remote MCP servers—called through something like OpenAI’s Responses API workflow—can provide a controlled boundary. Add approvals before data sharing. Add logging. Add network policies.
The difficult part is procurement and governance. Connector hubs provide a single vendor to evaluate. A protocol ecosystem often means many small servers, published in multiple directories, maintained by different parties, updated at different cadences.
Practical takeaway: enterprises should treat “MCP server” like “software dependency,” not like “app integration.” The lifecycle is closer to code than to SaaS.
How to choose wisely: practical takeaways for 2026
Here are practical steps that follow directly from the current ecosystem signals:
- Segment tool types in policy. Write separate rules for connector hubs, remote MCP servers, and local stdio MCP servers. Each has different risk and audit needs.
- Treat registries as distribution, not validation. The presence of official and third-party directories (including the official MCP Registry and sites like FindMCP) signals scale—but not safety.
- Make approvals meaningful. If your platform supports default approvals before data sharing (as OpenAI documents for connectors and remote MCP servers), configure prompts and policies so approvals are specific, not routine.
- Prefer managed runtime for high-impact tools. When a tool can move money, alter production systems, or access sensitive customer data, remote servers in controlled environments are easier to monitor than ad hoc local processes.
- Ask “where does it run?” before “what does it do?” The transport and execution model—stdio local vs remote HTTP—will often predict your worst-case outcome more accurately than the tool’s marketing description.
The connector catalog era trained teams to think in terms of “apps.” The protocol era will force teams to think in terms of capabilities—and the trust boundary around those capabilities.
2026 governance checklist
- ✓Segment tool types in policy (connectors vs remote MCP vs local stdio)
- ✓Treat registries as distribution, not validation
- ✓Make approvals meaningful and specific
- ✓Prefer managed runtimes for high-impact tools
- ✓Ask “where does it run?” before “what does it do?”
The shift in one line
The question for 2026 isn’t whether MCP becomes popular. The question is whether organizations build the governance to match the speed of distribution.
Frequently Asked Questions
What is the Model Context Protocol (MCP), in plain English?
MCP is an open protocol that standardizes how AI assistants discover and invoke tools, and how “MCP servers” expose tools, resources, and prompts. Instead of relying only on vendor-specific connector catalogs, MCP aims to make tool access interoperable across different AI clients and platforms. The protocol is documented publicly in the MCP project repository and specification.
Is MCP replacing Zapier-style connectors?
Not outright. Connector hubs still solve common integration problems well: consistent auth patterns, reliability, and centralized governance. MCP changes the default assumption that “integration equals connector catalog.” OpenAI’s documentation treats connectors and MCP servers as parallel options for tool access through the Responses API, signaling coexistence rather than immediate replacement.
What’s the difference between a remote MCP server and a local MCP server?
A remote MCP server runs as a network service (often over HTTP) and can be invoked by a model platform as a tool—OpenAI documents this as part of its tool workflow. A local MCP server often runs on a developer machine and communicates via stdio transport, which the MCP spec documents as the current approach (replacing earlier HTTP+SSE). Local servers are convenient but can increase risk because they run close to local files and credentials.
Why does the transport change (stdio vs HTTP+SSE) matter?
Transport determines the execution and exposure model. stdio commonly implies a local process, which may reduce network exposure but increases the need to trust the local runtime and installation source. Earlier MCP versions used HTTP+SSE, and the spec’s shift indicates a meaningful evolution. Security teams should treat transport as a first-order design choice because it reshapes auditing, sandboxing, and incident response.
Are MCP registries safe to use?
Registries are useful distribution channels, not guarantees of safety. An official MCP Registry lists production servers, and third-party directories (like FindMCP) make discovery even easier. That convenience creates a marketplace effect similar to package registries or browser extension stores: adoption accelerates, but so can the spread of sloppy or malicious servers. Organizations should apply their own vetting and governance.
How big is the MCP ecosystem right now?
An academic preprint reports over 10,000 active MCP servers and 97 million monthly SDK downloads as of early 2026. Those figures are attention-grabbing but should be treated as indicative unless corroborated by vendor telemetry. Even without perfect measurement, the growth of official and third-party directories suggests a rapidly expanding ecosystem.
