Why Is Everyone Suddenly Talking About MCP?
In late 2024, Anthropic released something called the Model Context Protocol, or MCP for short. Half a year later, Cursor, VS Code, Claude Desktop, and ChatGPT have all integrated it; thousands of MCP servers have popped up on GitHub; and related projects appear on HN’s trending list every now and then. It’s not common for a protocol to be adopted so quickly by the entire developer community.
The reason is actually simple. Large language models are very powerful, but they have one major flaw: they don’t have access to your actual data. Your code repositories, databases, file systems, calendars, and APIs—the model can’t see any of them. In the past, integrating these required writing separate adapters for each tool, which was not only a massive amount of work but also prone to bugs. What MCP does is establish a unified standard, allowing any AI application to connect to external systems through a single set of protocols.
There’s an analogy from the official sources that I think hits the nail on the head: MCP is like the USB-C port for AI applications. You don’t need to worry about whether you’re connecting a hard drive or a monitor—just plug it in.
What problem does MCP actually solve?
Let’s start with a real-world scenario. Suppose you ask Claude Code to help you fix a bug in a project; it needs to read the code repository, check the database schema, and review the Git history. Without MCP, you’d have to manually copy and paste all this information into the model. If the project is even slightly large, just the back-and-forth copying and pasting alone could keep you busy for half an hour.
With MCP, all you need to do is add a few lines of JSON to your Claude Desktop profile, and it can directly access your local file system, search Git logs, and connect to PostgreSQL to read table structures. The model decides on its own when to call which tools; all you need to do is provide a description of your requirements.
This isn’t a new concept—function calling and tool use have been around for a long time. The difference lies in standardization. Function calling formats vary by vendor: OpenAI uses one syntax, Anthropic uses another, and Google uses yet another. If you write a tool compatible with OpenAI, you’ll have to rewrite it entirely to work with Claude. MCP abstracts this layer away, allowing you to write it once and run it anywhere.
Breakdown of Core Concepts
The MCP architecture consists of two components: the Client and the Server. The Client runs within your AI application (such as Claude Desktop or Cursor) and is responsible for initiating requests. The Server is an external tool that you configure, and it is responsible for responding. Communication occurs via JSON-RPC and supports both local stdio and remote HTTP transmission methods.
A server can provide three capabilities:
Tools: Allows the model to perform actions, such as querying a database, calling an API, or manipulating files. This is the most common type—it’s like giving the model a pair of hands.
Resources: Provide the model with read-only data. For example, a configuration file, a document, or an API response. The model will not modify this data; it will simply read it as context.
Prompts (Prompt Templates): Predefined prompts allow users to trigger specific tasks with a single click. For example, ”Review the security of this code”—the underlying prompt template is defined by the server.
It is not necessary to have all three. For most servers, implementing just "Tools" is sufficient. "Resources" and "Prompts" are just icing on the cake.
Hands-On: Set Up an MCP Server in Five Minutes
The official SDK is available in 10 languages, with Python and TypeScript being the most widely used. Here, we’ll use Python to demonstrate the simplest example.
First, install the dependencies:
pip install mcp
Next, write a minimal server that exposes a weather lookup tool:
from mcp.server import Server
import mcp.server.stdio
from mcp.types import Tool, TextContent
import asyncio
server = Server("weather-server")
@server.list_tools()
async def list_tools():
return [Tool(
name="get_weather",
description="Check the weather for a specific city",
inputSchema={
"type": "object",
"properties": {
"city": {"type": "string", "description": "City name"}
},
"required": ["city"]
}
)]
@server.call_tool()
async def call_tool(name, arguments):
if name == "get_weather":
city = arguments.get("city", "")
# Replace this with an actual weather API call
return [TextContent(type="text", text=f"{city} is sunny today, 25°C")]
async def main():
async with mcp.server.stdio.stdio_server() as (r, w):
await server.run(r, w)
asyncio.run(main())
Then, in the Claude Desktop configuration file (~/Library/Application Support/Claude/claude_desktop_config.json, The Windows path is %APPDATA%\Claude\claude_desktop_config.json) Add:
{
"mcpServers": {
"weather": {
"command": "python",
"args": ["/path/to/your/weather_server.py"]
}
}
}
Restart Claude Desktop, and it will be able to answer questions about the weather. The model will automatically determine when to use this tool.
The entire process is seamless: from writing code to deploying the model—there’s no complex network configuration, no API Gateway, and no authentication framework involved. This is what makes MCP so appealing.
Which servers in the official reference can be used directly?
If you don't want to write your own, there are already quite a few out-of-the-box servers available in the official repository:
Filesystem: Allow the model to read and write local files. Specify the directories to be accessed during configuration; the model can only operate within that scope.
Git: Reads the commit history, branch information, and diffs from a Git repository. When used in conjunction with Claude Code, the model can understand the project's version control context.
Memory: Knowledge Graph-Based Long-Term Memory. Preserves information across conversations, solving the long-standing problem of ”the model not remembering what was said last time.”
Fetch: Extract the content from a web page and convert it into a format suitable for the model to read. This is much more reliable than simply pasting a URL.
Sequential Thinking: Have the model reason through complex problems step by step. To some extent, this involves engineering a chain of thought at the prompt level.
These servers can all be launched directly using npx or uvx, without the need for a global installation. For example, Filesystem:
npx -y @modelcontextprotocol/server-filesystem /path/to/allowed/dir
The Current State of the Ecosystem and My Assessment
As of mid-2026, the MCP Registry has already listed a large number of community servers. The leading use cases are concentrated in several areas: database queries (PostgreSQL, MySQL, SQLite), code hosting platforms (GitHub, GitLab), project management (Linear, Jira), document collaboration (Notion, Google Drive), and messaging platforms (Slack, Discord).
A few trends worth watching.
Remote servers have become a new area of focus. In the early days, MCP servers were typically run locally and communicated via stdio. Now that Streamable’s HTTP transmission method has matured, servers can be deployed in the cloud and shared among multiple clients. This is significant for enterprise scenarios—IT teams can centrally deploy MCP servers, and employees can connect to them individually.
Since the launch of the MCP Registry, the experience of discovering and installing servers has improved significantly. Previously, you had to search for them manually on GitHub, but now, similar to the npm model, you can install them with a single command. Of course, the registry’s review and security management processes are still being refined.
There are also potential risks. Security is the biggest concern. Granting model tools access permissions means the model can perform file operations, database queries, and API calls. If the server’s access controls are not properly configured, a single hallucination could cause real-world damage. The official documentation repeatedly emphasizes the principle of least privilege, but it’s hard to say how many users actually take the time to carefully configure permission boundaries in practice.
Another issue is performance. Multiple rounds of tool calls can cause the conversation token count to balloon rapidly, especially when a large number of files or database results are returned. This problem becomes even more pronounced when the context window of a local model is limited.
Should I invest my time in learning MCP right now?
If you're an independent developer or part of a small team, my advice is: Get started right away.
The reasons are quite practical. First, tools you’re already using—such as Claude Code, Cursor, and VS Code Copilot—all support MCP, so the setup effort is minimal. Second, the official server has broad enough coverage; even if you don’t build your own server, connecting to an existing one is sufficient. Third, for those developing AI applications, understanding the MCP architecture has become a fundamental skill—just like understanding REST APIs.
If you are an enterprise IT manager, you may want to monitor the maturity of security frameworks and registries. Support for OAuth 2.1 is already underway, and standards for enterprise-level access management are currently under discussion.
But one thing is certain: the standardization of tool invocation protocols is already underway, and MCP is currently the only candidate standard. There are no competitors. This means that even if the protocol changes in the future, the experience gained in the early stages will not be wasted.
Tips for Getting Started
Don't be intimidated by the size of the documentation. The MCP actually boils down to three key steps: writing Tool definitions, writing Tool handler functions, and configuring the Client connection. Once you understand these three steps, the rest is just details.
Here’s the recommended step-by-step approach: First, set up a Filesystem Server, run it in Claude Desktop, and get a feel for how the model automatically invokes tools. Next, try the Git Server to see how the model interprets your code repository. Finally, try writing your own server and integrate one of your frequently used APIs into it. The entire process should take about an afternoon.
The official documentation is available at modelcontextprotocol.io and is very clear. The modelcontextprotocol/servers repository on GitHub contains a complete reference implementation. If you encounter any issues, head to the community discussion forum—both the Anthropic team and community contributors respond quite quickly.
English 
Chinese