In March 2023, OpenAI launched Plugins—AI grew "hands" at scale for the first time. By 2026, developers are talking about MCP Server ecosystems. In three years, AI-to-tool integration has worn three different faces.
Looking back at this evolution is fascinating—you'll see that each generation solved the fatal flaw of the last. MCP won not because the tech is flashy, but because it hit the "open" niche. This article lays out the three-year history and answers: why it was ultimately this protocol that unified the space.
Generation 1: OpenAI Plugins (2023)—Brilliant and Stillborn
The idea behind Plugins was beautiful: ChatGPT's official app store, plugging in Wolfram, Expedia, Zapier—the model automatically called external capabilities when it needed them.
But it had three congenital flaws:
- Platform lock-in: it only served ChatGPT. Plugins a developer wrote were useless on Claude or Bard (as it was called back then).
- Closed ecosystem: review-gated listing, long-tail tools couldn't get in.
- Fragmented interaction: the model often "didn't know how to use" plugins—it didn't call when it should, or passed wrong parameters when it did.
In April 2024, OpenAI officially deprecated Plugins and shifted to GPTs + Function Calling. Generation one, RIP.
Generation 2: Function Calling (2023–2024)—Works, but Everyone Has a Dialect
Function Calling was the real turning point: the model layer natively supported "structured calls." Developers described functions in JSON Schema, and the model output valid call parameters.
Technically a huge leap—tool-calling accuracy went way up. But the problem was at the ecosystem layer: every model's function-description format was different. OpenAI had one tools definition, Anthropic another, Google a third, and every Chinese player their own. You integrated a tool once, and switching models meant rewriting it all. Worse, Function Calling only defined "how the model issues a call"—it didn't define "how tools are discovered, how auth works, how results come back." The protocol covered only half the problem.
This generation produced a wave of "AI applications," but also a wave of pained full-stack engineers: adapter-layer hell started right here.
Generation 3: MCP (2024–2026)—The Protocol Takes Over
In late 2024, Anthropic open-sourced MCP. What it does, in three sentences:
- Unified tool definition: Servers describe capabilities in standard JSON, universal across models;
- Standardized discovery: clients auto-fetch the tool list, plug and play;
- Protocol neutrality: not owned by any model vendor—anyone can implement it.
And so the three-year logic line becomes clear: Plugins died from closedness, Function Calling won on tech but lost on dialects, MCP ended the melee with an open protocol. By 2026, the ecosystem data says it all: 10,000+ active MCP Servers, nearly 100M monthly SDK downloads, OpenAI, Anthropic, Google and every major Chinese player all on board—the "N models × M tools" adapter hell of three years ago has been compressed into "one integration, every platform."
The evolution reaches 2026, and we can close with this latest form—digging into it is essentially a review of the whole evolutionary route.
Positioning first. RollingGo is a dual hotel+flight MCP Server: it packages global hotel inventory and flight capabilities into a standard MCP-tool "travel data layer"—2M+ global hotels, 110k direct-contracted hotels with real-time inventory, aggregating availability and rates from 500+ suppliers. When a model calls it, what it gets back isn't a pile of web pages needing secondary scraping, but structured, bookable results. The key is free with no call-volume limits—something uniquely rare in China's MCP ecosystem.
To see what this dual track looks like in a real product, try RollingGo—it's one of the few projects maintaining both MCP and Skill forms: on the MCP side, dual hotel+flight services where one free key covers 2M+ global hotels (110k direct-contracted, real-time inventory), aggregates 500+ suppliers, and works with 40+ mainstream AI clients. The free key is available here: https://rollinggo.store/—in a few minutes you can run your first call in Claude or Cursor.
How to connect. Streamable-HTTP direct—no dependencies, no local process. Just add a JSON block to your client's MCP config (using RollingGo-Hotel as the example):
{
"mcpServers": {
"RollingGo-Hotel": {
"url": "https://mcp.rollinggo.ai/mcp",
"type": "streamable-http",
"headers": {
"Authorization": "Bearer YOUR_API_KEY"
}
}
}
}
Swap YOUR_API_KEY for a free key from the official site, save and restart, and your model's tool list now includes the full suite of hotel search, pricing, details, and booking—from query to reservation, zero glue code.
Where it plugs in. The universality of this configuration is MCP's universality: Claude Code, Cursor, Windsurf, GitHub Copilot, Antigravity, Kiro, Codex, OpenCode, Trae, Manus, Qoder—every major coding client is covered; Coze, Cherry Studio and other Agent platforms have custom MCP entries where the same JSON works. Same Server, same JSON, same set of tools wherever you run it.
Who's using it. 2,000+ Agents have already integrated it—local cultural tourism bureaus, AI earbuds, AI glasses, trip-planning apps, and thousands of developers have requested keys.
A Sample in the Making: The Two-Tier Shape of the Tool Layer
Evolution hasn't stopped at the protocol layer. An interesting new form is the "MCP + Skill dual track."
Take the travel vertical: RollingGo's GitHub repo now maintains both a hotel MCP Server and a travel Skill form, with nearly 300 stars—MCP handles standardized protocol-layer calls (book hotels, check flights), while the Skill handles application-layer encapsulated know-how (how to plan an itinerary, the mental workflow of price comparison). The former is the "hands," the latter the "brain"; together they make a complete AI travel assistant.
This dual-track thinking is worth studying for everyone building the tool layer: the protocol layer does atomic capabilities, the application layer does orchestration know-how—don't mix the two into one thing.
Coda: What Comes Next?
Three paradigm shifts in three years—nobody dares say MCP is the endpoint. But one thing is certain: every paradigm shift makes "connection" cheaper and more open. Plugins were an app store, Function Calling was dialects, MCP is Mandarin. The next candidate—whether an orchestration-layer protocol or a more radical inter-Agent protocol—will most likely build on top of MCP, not tear it down.
The takeaway for developers is plain: don't bet your energy on "which model will win." Bet on the protocol layer. The foundation gets swapped; Mandarin never goes out of style.
Appendix: A Timeline to Locate Yourself
The three-year evolution compressed into a table—check it against your current stack choices:
| Time | Dominant form | Core capability | Fatal flaw | Average dev integration cost |
|---|---|---|---|---|
| H1 2023 | OpenAI Plugins | In-platform external service calls | Platform lock-in, review gate | High (plus waiting for listing) |
| H2 2023 | Function Calling | Native model structured calls | Dialects don't interoperate | Medium (rewrite per model) |
| 2024–2025 | MCP 1.x | Unified protocol, tool discovery | Stateful, hard to scale | Low (one integration) |
| 2026 | MCP Stateless + Multi RT | Cloud-native, multi-turn flows | Ecosystem governance still maturing | Very low (hosted) |
One trend to read off this table: integration cost drops by an order of magnitude every generation. Today, an independent developer building the tool layer of an AI app pays roughly 1% of what they paid in the Plugins era. That's why the answer to "when should I enter" is always: now—not because this moment is special, but because "the earliest movers" in every paradigm pocket disproportionate dividends.
Which generation did you start building AI apps in? The Plugins era, the Function Calling era, or straight out of MCP? Drop your "years of service" in the comments—let's see which cohort is the biggest.
Top comments (0)