摆摊卖爱情最近在整理手头的AI工具链时，我发现后台问得最多的不是某个模型多强，而是“MCP到底是什么”“该装哪些MCP Server”。这其实是个好现象，说明大家已经从“玩聊天”进入“让AI真正干活”的阶段。我花了两周时间，把日常开发、设计协作、文档处理相关的MCP工具全部过了一遍，筛出一份个人认为值得装、也经得起实测的精选清单。这篇文章先把原理讲透，再给出具体的配置过程和踩坑记录。
这篇内容适合三类人看：一是刚听说MCP、想搞清楚它和插件、Agent有什么区别的入门者；二是已经在用Claude Code、Trae或各类IDE，想给AI接上“手和眼睛”的开发者；三是做设计、文档、剪辑等非纯编码工作，想让AI直接操作专业软件的人。你会看到MCP的完整概念、十几个精选Server的选型理由、从零到一的配置步骤，以及我实际使用中遇到的坑和解决办法。
1. MCP到底是个什么东西——先搞清楚原理再挑工具
1.1 从API、插件到MCP：为什么需要一个新的连接标准
先聊一个很现实的问题：过去的AI助手为什么显得“笨”？因为它只能基于训练数据回答，无法访问你电脑里的文件、数据库里的实时数据，更不可能替你去点网页按钮。想让AI调用外部能力，传统做法是给每个工具写一套定制适配代码，再通过Function Calling把函数暴露给大模型。
这带来一个尴尬局面：每接一个新工具就要重新写一遍集成逻辑，今天接Figma要写一套，明天接数据库要再写一套，后天换个AI客户端又得重来。整个生态被割裂成一个个烟囱，效率极低。
MCP（Model Context Protocol，模型上下文协议）就是来解决这个问题的。它由Anthropic在2024年底提出并开源，核心思路是给“AI应用”和“外部工具/数据源”之间定义一个统一标准。你可以把它理解成AI世界的USB-C接口：不管你是手机、显示器还是键盘，只要支持USB-C，插上就能用；同样，不管你是Claude、Cursor还是某个IDE，只要实现MCP协议，就能通过统一方式调用所有MCP Server暴露的能力。
这个设计解决了三件事：一是AI应用不用为每个工具写定制代码；二是工具提供方只需实现一次MCP Server，就能被所有兼容MCP的客户端复用；三是能力边界清晰，数据源、工具逻辑和AI模型彻底解耦。
1.2 三个核心角色：Host、Client、Server一次说清
理解MCP的架构并不难，记住三个角色就够了。
Host是宿主程序，也就是你正在使用的AI应用，比如Claude Desktop、Claude Code、Trae、JetBrains的AI插件等。Host负责管理对话、维护上下文，并决定何时调用外部工具。
Client是Host内部与Server建立通信的通道。一个Host可以同时挂多个Client，每个Client对应一个MCP Server的连接。这个区分很多人会忽略，但在排查问题时很关键——你装的Server不生效，往往是Client侧连接失败。
Server是能力提供方，它把某个工具或数据源包装成标准化的MCP服务，暴露三类能力：Tools（可执行的函数，比如查询天气、操作浏览器）、Resources（可读取的数据，比如文件内容、数据库记录）、Prompts（可复用的提示模板）。Server通过stdin/stdout标准输入输出或HTTP/SSE与Client通信，传输内容统一用JSON-RPC 2.0格式封装。
一次完整调用是这样发生的：你在对话框里说“帮我查一下订单表里的异常数据”，Host理解意图后，把请求交给订单数据库对应的Client，Client按MCP协议转发给Server，Server执行SQL并返回结果，Host把结果拼进上下文，最终生成自然语言回复。整个链路中，AI只认协议，不关心数据源具体是MySQL还是PostgreSQL。
1.3 MCP 与 Tool、Skill、Agent 到底有什么区别
这个问题的出现频率极高，我直接用一张表说清楚：
| 概念 | 本质 | 类比 | 粒度 |
|---|---|---|---|
| Tool | 单个可执行函数 | 一件电器 | 细 |
| Skill | 一组操作流程/提示词模板 | 使用说明书 | 中 |
| Agent | 能自主决策的任务执行体 | 管家 | 粗 |
| MCP | 连接工具与AI的统一协议 | 插座标准 | 基础设施 |
很多人把Tool和MCP混为一谈，其实MCP不替代Tool，而是承载Tool的标准管道。你可以在一个MCP Server里暴露多个Tool，比如一个GitHub MCP Server可以提供创建仓库、提PR、列Issue等多个工具。Skill更像是一套预设的工作流或提示词，告诉AI“遇到这个任务时按这个步骤