新手必读一文读懂MCP从入门到精通完整指南

深入了解MCP，掌握AI应用集成的新机遇。

核心内容：

1. MCP核心概念与认证价值解析
2. AI模型发展现状与MCP的突破性应用
3. 如何规划MCP学习和考试路径，提升职业竞争力

这篇指南来全面拆解MCP（Model Context Protocol Professional）的核心概念、认证价值，以及如何从零开始规划学习和考试路径。无论是刚踏入IT行业的新人，还是想提升技能的资深从业者，MCP认证都能为职业发展提供更扎实的技术支撑和更广阔的机遇。下面，我们从MCP的定义和重要性开始，逐步揭开这一认证体系的全貌。

为什么 MCP 是一个突破

过去一年，AI模型的进化速度有目共睹。从GPT-4到Claude Sonnet 3.5，再到Deepseek R1，推理能力越来越强，幻觉问题也在逐步改善。

新的AI应用层出不穷，但一个普遍感受到的瓶颈是：这些应用大多是“全新服务”，跟我们日常使用的系统和工具几乎没有打通。换句话说，AI模型与既有系统的深度融合，进展相当缓慢。

举一个具体的例子：我们目前还无法通过同一个AI应用同时完成联网搜索、发送邮件、发布博客等操作。单个功能实现起来并不难，但要全部集成到一个系统里，就变得遥不可及。

换个场景，想象一下日常开发工作。在IDE里，我们希望AI能帮我们完成以下事情：

• 查询本地数据库的数据来辅助开发；
• 搜索GitHub Issue，判断某个问题是不是已知bug；
• 把某个PR的评审意见自动发送到同事的即时通讯工具（比如Slack）里进行Code Review；
• 甚至直接查询或修改当前AWS、Azure的配置来完成部署。

这些听起来像科幻场景的功能，通过MCP正在变成现实。可以关注一下Cursor MCP和Windsurf MCP，体验在Cursor中自动获取Chrome dev tools console log的能力。

为什么AI集成已有服务的进展如此缓慢？原因不少。一方面，企业数据非常敏感，大多数公司需要很长时间和流程去推动。另一方面，技术层面缺少一个开放、通用、有共识的协议标准。

MCP正是由Claude（Anthropic）主导发布的一个开放、通用、有共识的协议标准。如果你对AI模型比较熟悉，应该对Anthropic不陌生——他们发布的Claude 3.5 Sonnet，到目前为止依然是最强的编程AI模型之一。

这里需要提一句：这个协议发布的最佳时机本该属于OpenAI。如果OpenAI刚发布GPT时就推动这样的标准协议，相信大家都会积极响应。但OpenAI选择了封闭路线，推出的是封闭的GPTs。而这类需要主导和共识的标准协议，通常很难由社区自发形成，往往需要行业巨头来推动。

Claude发布MCP后，官方的Claude Desktop立即开放了MCP功能，并推动了开源组织Model Context Protocol，吸引不同公司和社区参与。下面列举了一些由不同组织发布的MCP服务器示例。

MCP 官方集成教学：

• Git - Git读取、操作、搜索。
• GitHub - Repo管理、文件操作和GitHub API集成。
• Google Maps - 集成Google Map获取位置信息。
• PostgreSQL - 只读数据库查询。
• Slack - Slack消息发送和查询。

第三方平台官方支持 MCP 的例子

由第三方平台构建的MCP服务器：

• Grafana - 在Grafana中搜索查询数据。
• JetBrains – JetBrains IDEs。
• Stripe - 与Stripe API交互。

社区 MCP 服务器

由开源社区开发和维护的MCP服务器：

• AWS - 用LLM操作AWS资源。
• Atlassian - 与Confluence和Jira交互，包括搜索/查询Confluence空间/页面，访问Jira Issue和项目。
• Google Calendar - 与Google日历集成，日程安排，查找时间，添加/删除事件。
• Kubernetes - 连接到Kubernetes集群并管理pods、deployments和services。
• X (Twitter) - 与Twitter API交互，发布推文并搜索推文。
• YouTube - 与YouTube API集成，视频管理、短视频创作等。

为什么是 MCP？

看到这里可能会有一个疑问：2023年OpenAI发布GPT function calling的时候，不是也能实现类似功能吗？之前很多文章介绍的AI Agent，不正是用来集成不同服务的吗？为什么又冒出个MCP。

function calling、AI Agent、MCP这三者之间到底有什么区别？

Function Calling

• Function Calling指的是AI模型根据上下文自动执行函数的机制。
• 它充当了AI模型与外部系统之间的桥梁。不同模型有不同的Function Calling实现，代码集成方式也不一样，由各AI模型平台定义和实现。

Model Context Protocol (MCP)

• MCP是一个标准协议，好比电子设备的Type-C接口——能充电也能传输数据。它让AI模型能与不同的API和数据源无缝交互。
• MCP的目标是替代碎片化的Agent代码集成，使AI系统更可靠、更高效。通过建立通用标准，服务商可以基于协议推出自己服务的AI能力，开发者能更快地构建更强大的AI应用，而无需重复造轮子，依托开源项目就能建立强大的AI Agent生态。
• MCP还能在不同应用/服务之间保持上下文，增强整体自主执行任务的能力。

AI Agent

• AI Agent是一个智能系统，能自主运行以实现特定目标。传统的AI聊天仅提供建议或需要手动执行任务，而AI Agent可以分析具体情况、做出决策、自行采取行动。
• AI Agent可以利用MCP提供的功能描述来理解更多上下文，并在各种平台/服务上自动执行任务。

区别

简单来说：MCP将不同服务和平台的能力列表告诉AI Agent；AI Agent根据上下文和模型推理，判断是否需要调用某个服务；接着使用Function Calling执行函数，而函数是通过MCP告诉Function Calling的；最后通过MCP协议提供的具体代码完成整个过程。

MCP对社区生态的好处主要体现在两点：

• 开放标准给服务商，服务商可以针对MCP开放自己的API和部分能力。
• 开发者不需要重复造轮子，可以用已有的开源MCP服务来增强自己的Agent。

思考

为什么Claude推出MCP后能被广泛接受？过去一年参与过几个AI项目开发，过程中确实感受到将AI模型集成到现有系统或第三方系统相当麻烦。

市面上虽然有一些框架支持Agent开发，例如LangChain Tools、LlamaIndex或Vercel AI SDK。

LangChain和LlamaIndex虽然是开源项目，但整体发展有点混乱。代码抽象层次太高，推广的重点是让开发者几行代码就完成某某AI功能。这在Demo阶段很好用，但实际开发中一旦业务复杂起来，糟糕的代码设计就会带来非常糟糕的编程体验。而且这两个项目太急于商业化，忽略了整体生态建设。

至于Vercel AI SDK，代码抽象确实做得不错，但主要只是对前端UI结合和部分AI功能的封装做得比较好，最大的问题是与Nextjs绑定太深，对其他框架和语言的支持不够。

所以Claude推动MCP的时机恰到好处。Claude Sonnet 3.5在开发者心中有较高地位，而MCP又是一个开放标准，很多公司和社区愿意参与进来。希望Claude能一直保持一个良好的开放生态。

MCP 如何工作

接下来介绍一下MCP的工作原理。先看官方的MCP架构图。

总共分为五个部分：

• MCP Hosts: 指LLM启动连接的应用程序，比如Cursor、Claude Desktop、Cline这类应用。
• MCP Clients: 在Hosts应用内维护与Server之间1:1连接的客户端。
• MCP Servers: 通过标准化协议为Client端提供上下文、工具和提示。
• Local Data Sources: 本地的文件、数据库和API。
• Remote Services: 外部的文件、数据库和API。

整个MCP协议的核心在于Server。Host和Client的概念对熟悉计算机网络的人来说很好理解，但Server该怎么理解呢？

回顾Cursor的AI Agent发展过程，可以看出AI自动化的演进路径：从Chat到Composer，再到完整的AI Agent。

• AI Chat只提供建议，如何将AI的response转化为行为和最终结果，全靠人类手动操作，比如复制粘贴或修改。
• AI Composer可以自动修改代码，但需要人类参与和确认，且无法完成除修改代码之外的其他操作。
• AI Agent是完全自动化的程序，未来完全可以做到自动读取Figma图片、自动生成代码、自动读取日志、自动调试代码、自动push代码到GitHub。

而MCP Server就是为了实现AI Agent的自动化而存在的。它是一个中间层，告诉AI Agent目前有哪些服务、哪些API、哪些数据源。AI Agent根据Server提供的信息决定是否调用某个服务，然后通过Function Calling执行函数。

MCP Server 的工作原理

先看一个简单的例子：假设想让AI Agent自动搜索GitHub Repository，然后搜索Issue，判断是不是已知bug，最后决定是否提交一个新Issue。

那么就需要创建一个Github MCP Server，这个Server需要提供查找Repository、搜索Issues和创建Issue三种能力。

直接看代码：

const server = new Server(
  {
    name: "github-mcp-server",
    version: VERSION,
  },
  {
    capabilities: {
      tools: {},
    },
  }
);

server.setRequestHandler(ListToolsRequestSchema, async () => {
  return {
    tools: [
      {
        name: "search_repositories",
        description: "Search for GitHub repositories",
        inputSchema: zodToJsonSchema(repository.SearchRepositoriesSchema),
      },
      {
        name: "create_issue",
        description: "Create a new issue in a GitHub repository",
        inputSchema: zodToJsonSchema(issues.CreateIssueSchema),
      },
      {
        name: "search_issues",
        description: "Search for issues and pull requests across GitHub repositories",
        inputSchema: zodToJsonSchema(search.SearchIssuesSchema),
      }
    ],
  };
});

server.setRequestHandler(CallToolRequestSchema, async (request) => {
  try {
    if (!request.params.arguments) {
      throw new Error("Arguments are required");
    }

    switch (request.params.name) {
      case "search_repositories": {
        const args = repository.SearchRepositoriesSchema.parse(request.params.arguments);
        const results = await repository.searchRepositories(
          args.query,
          args.page,
          args.perPage
        );
        return {
          content: [{ type: "text", text: JSON.stringify(results, null, 2) }],
        };
      }

      case "create_issue": {
        const args = issues.CreateIssueSchema.parse(request.params.arguments);
        const { owner, repo, ...options } = args;
        const issue = await issues.createIssue(owner, repo, options);
        return {
          content: [{ type: "text", text: JSON.stringify(issue, null, 2) }],
        };
      }

      case "search_issues": {
        const args = search.SearchIssuesSchema.parse(request.params.arguments);
        const results = await search.searchIssues(args);
        return {
          content: [{ type: "text", text: JSON.stringify(results, null, 2) }],
        };
      }

      default:
        throw new Error(`Unknown tool: ${request.params.name}`);
    }
  } catch (error) {}
});

async function runServer() {
  const transport = new StdioServerTransport();
  await server.connect(transport);
  console.error("GitHub MCP Server running on stdio");
}

runServer().catch((error) => {
  console.error("Fatal error in main():", error);
  process.exit(1);
});

上面的代码中，通过server.setRequestHandler告诉Client端提供了哪些能力，通过description字段描述能力的作用，通过inputSchema描述完成能力需要的输入参数。

再来看看具体的实现代码：

export const SearchOptions = z.object({
  q: z.string(),
  order: z.enum(["asc", "desc"]).optional(),
  page: z.number().min(1).optional(),
  per_page: z.number().min(1).max(100).optional(),
});

export const SearchIssuesOptions = SearchOptions.extend({
  sort: z.enum([
    "comments",
    ...
  ]).optional(),
});

export async function searchUsers(params: z.infer) {
  return githubRequest(buildUrl("https://api.github.com/search/users", params));
}

export const SearchRepositoriesSchema = z.object({
  query: z.string().describe("Search query (see GitHub search syntax)"),
  page: z.number().optional().describe("Page number for pagination (default: 1)"),
  perPage: z.number().optional().describe("Number of results per page (default: 30, max: 100)"),
});

export async function searchRepositories(
  query: string,
  page: number = 1,
  perPage: number = 30
) {
  const url = new URL("https://api.github.com/search/repositories");
  url.searchParams.append("q", query);
  url.searchParams.append("page", page.toString());
  url.searchParams.append("per_page", perPage.toString());

  const response = await githubRequest(url.toString());
  return GitHubSearchResponseSchema.parse(response);
}

可以看得很清楚，最终是通过https://api.github.com的API来实现与Github交互的，通过githubRequest函数调用GitHub的API，最后返回结果。

换句话说，在调用Github官方API之前，MCP的主要工作是描述Server提供了哪些能力（给LLM提供）、需要哪些参数（以及参数的具体功能是什么），最后返回的结果是什么。

所以MCP Server并不是什么新颖、高深的东西，它只是一个具有共识的协议。

如果想实现一个更强大的AI Agent，比如让AI Agent根据本地错误日志，自动搜索相关的GitHub Repository，然后搜索Issue，最后将结果发送到Slack。

那么可能需要创建三个不同的MCP Server：一个是Local Log Server，用来查询本地日志；一个是GitHub Server，用来搜索Issue；还有一个是Slack Server，用来发送消息。

AI Agent在用户输入“我需要查询本地错误日志，将相关的Issue发送到Slack”指令后，自行判断需要调用哪些MCP Server、决定调用顺序，并根据不同MCP Server的返回结果来决定是否需要调用下一个Server，最终完成整个任务。

如何使用 MCP

如果没有尝试过如何使用MCP，可以考虑用Cursor（以Cursor为例）、Claude Desktop或Cline来体验。

不需要自己开发MCP Servers——MCP的好处就是通用、标准，开发者不必重复造轮子（但学习时重复造轮子是有益的）。

首先推荐官方组织的一些Server：官方的MCP Server列表。

目前社区的MCP Server仍然比较混乱，很多缺少教程和文档，不少代码功能也有问题。可以自行尝试Cursor Directory中的一些例子。具体的配置和实战就不细讲了，可以参考官方文档。

MCP 的一些资源

以下推荐一些MCP资源，供参考。

MCP 官方资源

• 官方的开源组织 Model Context Protocol
• 官方的文档 modelcontextprotocol
• 官方的 MCP Server 列表
• Claude Blog

社区的 MCP Server 列表

• Cursor Directory
• Pulsemcp
• Glama MCP Servers

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：新手必读一文读懂MCP从入门到精通完整指南要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题