MCP 服务器是一个程序，它赋予 AI 助手在自身对话之外做一些事情的能力：读取一个文件、查询一个数据库、发布一条帖子。
MCP 全称是 Model Context Protocol。它是助手与工具之间对话方式的一套标准，而它存在的原因值得了解，因为这解释了它为什么这么快就成了一个独立的品类。
它解决的问题
助手单独存在时只能生成文字。这很有用，但它没法帮你查日历，也没法把任何东西发送到任何地方。
显而易见的解决办法是把它连接到各种事物上，而在一段时间里，每个应用都用自己的方式在做这件事。每个助手都有自己的插件格式。一个想要对接三个助手的工具，得做三套集成，而多出一个第四个助手，就意味着每个工具都要再做一遍。这正是任何集成领域在走向标准化之前都会产生的那种组合爆炸式的混乱。
MCP 就是这场标准化。一个协议：一个工具只需要实现一次服务器，任何支持 MCP 的应用都能使用它。
一个服务器实际暴露了什么
一个 MCP 服务器提供的是工具（tools），也就是一组具名的、有明确输入定义的操作。一个发布类的服务器可能会提供用于创建帖子、列出你已连接账号、把内容排期到之后某个时间，以及查看队列中内容的工具。
助手会看到工具列表及其描述，再根据你的要求决定调用哪一个。你说”把这条排到周二早上”，助手就会推断出这意味着调用带有特定日期的排期工具，然后去调用它。
由此引出两个容易被忽略的地方。
是助手在做选择。 你不是在调用一个 API，你是在用语言提出要求，由模型决定该做什么。这正是它的吸引力所在，也正是为什么对任何有实际后果的操作，审核环节都很重要。
描述本身就是接口的一部分。 一个描述含糊的工具会被用错，因为描述正是模型用来判断该怎么做的依据。
它不是什么
不是让 AI 想做什么就做什么的方式。 一个服务器暴露的是一组特定的工具。如果发布不在其中，问多少次都产生不出一条帖子。
不是自动发生的。 需要有人去连接这个服务器并授权它。助手不会自己去发现工具。
不只是给开发者用的。 在一个支持 MCP 的应用里连接一个服务器，通常只是配置，而不是写代码。
作为用户，这对你意味着什么
如果你在用一个支持 MCP 的助手，连接一个服务器会把”帮我写这个”变成”去做这件事”。助手能够行动，而不只是起草。
具体到社交发布上，这就是”把生成好的文案粘贴进另一个应用”和”让助手直接去排期它、顺便查一下那一周还排了什么其他内容、再做调整”之间的区别。
值得早点想清楚的是：你允许它在多大程度上不经审核就自行行动。一个只负责起草的助手风险很低。一个直接向受众发布内容的助手则是完全不同的事情，大多数人应该先从草稿开始。
连接 BulkPublish
BulkPublish 在 npm 上发布了一个名为 @bulkpublish/mcp-server 的 MCP 服务器。连接到助手之后，它会把发布能力暴露到全部 15 个平台：Facebook、Instagram、TikTok、YouTube、X、Threads、Bluesky、Pinterest、Google Business Profile、LinkedIn、Mastodon、Discord、Telegram、Tumblr 和 Snapchat。
针对人们实际会用来接入它的应用，我们提供了对应的设置指南，包括 Claude、ChatGPT、Cursor、VS Code、Windsurf、Codex CLI、Gemini CLI、Cline 和 Warp。
在底层，它调用的是和开发者直接调用时完全一样的 API：
| 免费版 | Pro | Business | |
|---|---|---|---|
| 每日 API 请求数 | 30 | 5,000 | 50,000 |
| 帖子 | 每天 3 条 | 每天 30 条 | 无限 |
| 频道 | 3 | 30 | 75 |
帖子可以被创建为草稿而不是直接发布，当撰写工作是由助手完成时，这是合理的默认设置。
简而言之
MCP 服务器是一种赋予 AI 助手真实能力的标准方式。它暴露一组固定的具名工具，助手根据你的要求决定调用哪一个，而在此之前，必须先有人去连接并授权它。这个协议存在的意义，就是让工具只需要构建一次集成，而不是每个助手都做一遍。