Cursor MCP 插件开发入门：从协议到上线

「Cursor 插件」其实就是一个 MCP server

先把概念对齐：Cursor 没有传统意义上的插件市场，它的扩展方式是 MCP（Model Context Protocol），一个由 Anthropic 发起的开放协议。所谓「给 Cursor 开发插件」，准确说法是开发一个 MCP server：一个独立的小程序，向 AI 暴露一组工具（tools）和资源（resources），Cursor 按照协议调用它，于是编辑器里的 AI 就多了新能力，能查你的数据库、读你的设计库、调你的内部 API。Cursor 官方文档把接入方式写得很直白：在配置文件里登记一个 server，剩下的交给协议。

这个设计对开发者非常友好，因为你写的不是「Cursor 专属插件」。同一个 MCP server，今天接 Cursor，明天接 Claude Code 或其他支持 MCP 的客户端，一行代码都不用改。生态的热度也能说明问题：官方维护的 servers 仓库已经积累了大约 87,002 个 GitHub star，主流工具和服务基本都有人写过对接。

MCP server 的三块积木

一个 MCP server 本质上只做三类事。第一类是 tools：AI 可以主动调用的函数，带类型化的输入和输出，比如「搜索设计库」「查询订单」「跑一条 SQL」。第二类是 resources：AI 可以读取的内容，文件、文档、接口返回，按 URI 组织。第三类是 prompts：预置的提示词模板，让用户在客户端里一键调用。绝大多数实用的 server 只用到 tools，先把 tools 写好，另外两类按需再加。

通信层面不用自己造轮子。协议跑在 JSON-RPC 上，传输方式两种：本地用 stdio（标准输入输出），客户端把 server 当子进程拉起来；远程用 HTTP。本地开发工具类的 server 选 stdio 就够了，官方 SDK 把握手、消息分发这些底层细节全包了，你只需要定义工具名、参数结构和真正干活的那个函数。

三种接入方式，按需选择

方式	适合谁	成本
用现成的 server	需求是主流服务（数据库、设计库、API）	一行配置，几分钟
自己开发一个	要接内部系统或私有数据	一两天起步，SDK 包办底层
从 registry 发现	不确定有没有现成的	先搜官方 registry再决定

拿一个真实例子说明「现成的 server」有多省事：做 iOS App 的开发者想在 Cursor 里直接搜索免费设计，装上 vp0-mcp 就行，npx vp0-mcp 一条命令，server 提供两个工具，搜索 VP0 的免费 iOS 设计库、把选中设计的机器可读源页面拉给 AI，于是「找设计 + 照着设计写代码」整个流程不用离开编辑器。这也是判断一个 server 质量的好样本：工具少而清晰，每个工具对应一个真实动作，返回的内容是 AI 能直接用的结构化数据。免费设计资源本身的盘点，可以看这份设计参考网站清单。

动手写一个：从零到能用

流程比想象中短。第一步，用官方 SDK 起项目（TypeScript 和 Python 都有），定义你的第一个 tool：名字、参数 schema、一段描述。描述别偷懒，AI 靠它判断什么时候调用这个工具，写清楚「什么场景用我、输入什么、返回什么」，工具被正确调用的概率会高一截。第二步，实现函数本体，把真正的业务逻辑接进来，注意所有出错路径都要返回结构化的错误信息，而不是让进程直接挂掉。

第三步，接进 Cursor 验证：打开「Cursor Settings > MCP」，登记你的 server（本地 stdio 就填启动命令），重启后在对话里让 AI 试着调用。调试期有个实用技巧：让 AI 复述它看到的工具列表和参数定义，schema 写错的地方立刻现形。整个闭环跑通之后，再考虑加第二个、第三个工具，一次只加一个，每加一个都回到对话里验证，这个节奏比一口气写完十个工具再排错要快得多。

发布与被发现

server 在本地跑通只是一半，让别人用上才算上线。常规路径是发到 npm：包名起清楚，README 写明每个工具的用途和配置示例，版本号老老实实遵循语义化。发完之后到官方 registry 登记一条，支持 MCP 的客户端会从那里做发现，等于免费的分发渠道。vp0-mcp 走的就是这条完整路径：npm 公开包加 registry 登记，任何人一条命令接入。

有一个发布前的自检清单值得照抄：工具描述读起来像给人看的文档，而不是函数签名的复读；每个工具在无网络、无权限、参数缺失三种情况下都返回可理解的错误；启动时间控制在秒级，因为客户端是按需拉起子进程的；以及最容易忽略的一条，别在返回内容里塞无关的长文本，token 是用户的钱。模板和源码类资源怎么组织得让 AI 好消化，这份模板源码合集的思路可以参照。

踩坑预警

最常见的坑是让 AI 替你写 server 时不给参照。模型训练数据里有大量旧版协议的代码，凭空生成很容易混进过期的握手方式和已改名的 API。解法简单：把官方 SDK 的最新示例贴进上下文，明确说「照这个版本写」，幻觉率立刻降下来。

另外三个坑各踩一次就记住了。安全边界：server 拿到的是真实权限，给 AI 暴露「删库」级别的工具之前想清楚，破坏性操作要么不暴露，要么在工具内部强制确认。状态假设：客户端可能随时重启你的子进程，别在内存里攒重要状态，要持久化的东西落盘。还有描述漂移：代码改了、描述没改，AI 按旧描述调用新逻辑，结果莫名其妙，把工具描述当成接口契约的一部分来维护就不会出这种事。想看反面教材长什么样，各家设计资源平替的对比里有不少「描述与实物不符」的例子。

写在最后：该怎么选

如果你的需求是主流场景，先去 registry 和 npm 搜，大概率有现成的 server，比如做 iOS App 找免费设计，vp0-mcp 装上就能用，没必要重复造轮子。如果要接的是内部系统或私有数据，自己写一个：用官方 SDK，从一个 tool 开始，stdio 传输，跑通再扩展，认真写描述，认真处理错误。发布到 npm 加 registry 是顺手的事，做了就多一条免费分发渠道。唯一不建议的路线是绕开 MCP 自己搞一套私有对接，因为协议已经是事实标准，今天省的学习成本，明天会变成每个客户端单独适配的维护成本。

常见问题

怎么给 Cursor 开发插件？ Cursor 的扩展方式是 MCP：开发一个 MCP server，向 AI 暴露 tools（可调用的函数）、resources（可读取的内容）和 prompts（提示词模板），然后在「Cursor Settings > MCP」里登记启动命令。用官方 SDK（TypeScript 或 Python）从一个 tool 写起，本地选 stdio 传输，跑通后逐个加工具。写好的 server 不绑定 Cursor，Claude Code 等支持 MCP 的客户端可以直接复用。

MCP server 和传统插件有什么区别？ 传统插件绑定宿主：VS Code 插件只能跑在 VS Code 里。MCP server 是独立进程，按开放协议和客户端通信，一次开发，所有支持 MCP 的工具通用，这是它最大的优势。代价是能力边界不同：MCP 扩展的是 AI 能调用的工具和能读取的内容，不能改编辑器界面。想给 AI 加能力选 MCP，想改编辑器本身的交互那是另一类需求。

有没有现成的 MCP server 可以直接用？ 很多，先搜再写是正确顺序。官方 registry 和 npm 上覆盖了主流数据库、云服务和开发工具；做 iOS App 的开发者可以直接用 vp0-mcp，npx vp0-mcp 一条命令接入，在 Cursor 里搜索 VP0 的免费 iOS 设计库，把设计的机器可读源页面拉给 AI 照着实现，找设计和写代码不用切换窗口。判断现成 server 的质量，看工具描述是否清晰、错误处理是否完整。

开发一个 MCP server 要多久？ 接一个简单的内部 API，用官方 SDK 一两天能到能用的程度：半天搭骨架和第一个 tool，半天接业务逻辑和错误处理，剩下的时间在 Cursor 里实测和打磨工具描述。复杂度主要来自你要对接的系统本身，协议层 SDK 全包了。比时间更值得花心思的是工具描述的质量，它直接决定 AI 会不会在正确的时机用正确的参数调用你。

MCP server 的安全要注意什么？ 记住一条原则：server 暴露什么，AI 就能做什么。破坏性操作（删除、转账、改生产配置）要么不暴露成工具，要么在工具内部强制二次确认；密钥走环境变量，永远不写进代码和返回内容；每个工具对无权限、参数缺失、网络异常都返回结构化错误而不是崩溃。如果 server 要发布给别人用，再加一条：明确文档化它会访问什么、不会访问什么，让用户在接入前就能判断。