MCP from Zero to One: How AI Safely Integrates with Existing Service Ecosystems

The Starting Point: Understanding MCP Through Function Calling

To understand MCP (Model Context Protocol), you first need to look at its predecessor — Function Calling. In the early days of AI, models primarily handled text and conversation, far from the industrialized systems we see today. Developers were already accustomed to the deterministic service interfaces of the Web2 ecosystem: WeChat Pay exposed refund and payment capabilities via HTTP APIs, GitHub provided repository listing via HTTP APIs. These HTTP-based CRUD operations are collectively known as API calls.

A natural question followed: if humans can call APIs, shouldn't AI be able to as well? The ability to connect AI with various service ecosystems is precisely what Function Calling is about. But large language models interact through a Completion/chat interface, while services like WeChat only speak HTTP. An "adapter module" had to bridge the gap — converting the AI's conversational intent into actual HTTP calls.

Fragmentation: Every AI Vendor Building Its Own Wheel

Once the adapter concept emerged, every AI vendor rushed to define their own integration spec — and nobody wanted to follow anyone else's. Two classic examples stand out: OpenAI went with a Plugin + Actions approach, requiring developers to provide massive configuration files; Anthropic's Claude used a self-built agent model that required you to write your own if-else logic. With Google and others entering the space, the landscape became a patchwork of incompatible standards.

Developers bore the brunt of this chaos. Imagine you're an official WeChat Pay developer who wants to expose payment capabilities to AI — you'd need to write one set of Action adapters for OpenAI, another for Claude, and so on. The more upstream vendors there are, the more adapter code you have to write. Dozens of codebases, all for the same refund capability.

Function Calling is fundamentally a "structured output" mechanism: instead of generating only natural language, the model outputs a formatted "invocation intent" (typically JSON) describing which function to call and with what parameters. The host application parses this JSON, executes the actual function, returns the result to the model, and the model generates a final response. Since each vendor had their own opinions on field naming, nesting structures, and error handling within that JSON, the same "refund" intent looked like two completely different data formats to OpenAI versus Claude. Developers had to write separate parsing and transformation logic for each vendor.

A Unified Standard Emerges: Anthropic Leads the MCP Draft

Faced with this chaos, Anthropic spearheaded a unified Function Calling specification in late 2024, with other vendors agreeing to adopt it. The spec covers a lot of ground, but its two most critical requirements — both aimed at adapters — are:

• Tools List API: Adapters must implement this to tell the AI app what capabilities they offer (e.g., "refund capability").
• Tools Call API: Adapters must implement this so the model can trigger specific capabilities at the right moment.

With this standard in place, the chain became clear: when a model connects, it first calls Tools List to discover available capabilities; when a user initiates a refund, the AI calls Tools Call to execute it; the adapter receives the call and makes the actual HTTP request to the underlying refund API.

For developers, this was liberating. You no longer needed to care whether the upstream model was DeepSeek^Ad, Google, Kimi, Claude, or OpenAI — you just declared your Tools List and implemented your Tools Call. One adapter could connect to hundreds of upstream vendors. That adapter is what we now call an MCP server, and this specification is the earliest version of MCP — think of it as MCP in its previous life.

The Quiet Period: When "MCP Is Dead" Was Trending

Interestingly, MCP didn't take off immediately after its introduction. As large model capabilities grew stronger, models became powerful enough to infer on their own how to call WeChat's HTTP APIs to complete a refund — no MCP required. For a time, "MCP is dead" was all over the internet, with many dismissing it as a flash in the pan.

Yet MCP has since become a cornerstone of the AI ecosystem. The turning point: the more powerful the models became, the more new problems they exposed.

The idea of "letting the model directly infer how to call APIs" is often referred to in the industry as ReAct (Reasoning + Acting) or Zero-shot Tool Use: give the model an API documentation description and let it assemble HTTP requests entirely through reasoning. This works in simple scenarios but has clear limitations — models may hallucinate non-existent parameters, miss authentication details, or mishandle pagination and retry logic. More critically, it requires stuffing complete API documentation into the context window. As the number of connected services grows, context length balloons, driving up inference costs and reducing accuracy. This is precisely where MCP's structured Tools List provides value — replacing unstructured documentation with structured capability declarations, allowing models to accurately understand available tools with minimal context overhead.

The Comeback: API Key Security as the Key Driver

Consider a real-world scenario. Suppose query performance on a production database degrades and you turn to AI for help. But the AI has no direct database access — it will ask you to provide credentials. A company with a dedicated DBA team might be able to create a read-only account, but many small and mid-sized companies can't, and the result is handing over the root password directly to the AI.

What does that amount to? It's not unlike giving your bank card PIN to an AI. Would you do that? In fact, both Claude and Cursor explicitly warn users in their official documentation against sharing sensitive data and API keys with AI.

The problem compounds as keys spread across tools. You give your database password, Docker secrets, and SSH credentials to Claude. A colleague starts using Trae — they need a copy too. Someone else uses Cursor — another copy. It's the equivalent of announcing your credentials through a megaphone on a public street. There was also a recent controversy worth noting: a publicly listed AI code editor was reported to not only store API keys but also package users' GitHub commit history and upload it to their own public cloud servers — sensitive information security faces unprecedented challenges. (The details of this incident are as reported by the original author; please refer to official sources for specifics.)

MCP's Solution: Keep Credentials Inside Your Network

Why wasn't there a leakage risk before AI? Because credentials always stayed on your own servers — held by backend programs that communicated with MySQL, Docker, and SSH. The frontend only called backend interfaces. In the AI era, that backend app disappeared, and sensitive keys landed directly in the AI's hands.

The solution is intuitive: since MCP is inherently a bridge between AI and existing services, just stand up an MCP server and move sensitive credentials there. AI only calls MCP via Tools Call; MCP handles adapting to the underlying MySQL, Docker, and Shell. The keys are back inside your own internal network.

The three factors behind MCP's return to prominence:

1. Control over sensitive credentials — Keys are no longer directly exposed to AI vendors.
2. Mitigating context explosion — Reducing context window burden to a meaningful degree (covered in detail in a follow-up).
3. Permission control — For example, an MCP server can intercept database requests containing the DELETE keyword and reject them outright. Without MCP, if the AI decides to run a DELETE, nothing stops it.

Both permission control and context explosion fall under the upstream problem space addressed by MCP Gateway.

MCP Gateway adds an enterprise-grade control plane on top of MCP servers. While a single MCP server solves "adapting a specific category of tools," enterprises typically run dozens of MCP servers simultaneously (databases, code repositories, monitoring systems...). The Gateway serves as a unified entry point, handling authentication, request routing, audit logging, rate limiting and circuit breaking, and cross-service permission policies. To draw a Web ecosystem analogy: MCP servers are like individual microservices, and MCP Gateway is like an API Gateway (such as Kong or Nginx). With a Gateway, enterprises can uniformly enforce policies like "prohibit DELETE operations" or "only allow specific teams to access the production database MCP" — without modifying any individual MCP server code — achieving centralized security governance.

Clarifying the Concepts: MCP vs. MCP Server

Finally, it's worth distinguishing two easily confused terms:

• MCP: A specification. It defines how AI vendors and existing services interact — the Tools List and Tools Call contract.
• MCP Server: A concrete adapter program that implements the integration logic.

From the chaos of Function Calling, to a unified standard, to being declared dead, and finally returning to center stage because of API key security, context management, and permission control — MCP has completed a full arc. And MCP Gateway has naturally emerged as the enterprise best practice for deploying MCP at scale.

One final note: MCP has only been around since late 2024 — roughly a year and a half — and its documentation and knowledge ecosystem are still maturing. This article simplifies certain details for accessibility. The next area worth exploring is how the Tools List and Tools Call message formats and transport mechanisms actually work under the hood.