北陌大叔折腾了几天，终于把"用 MCP 服务发 CSDN 博客"这件事跑通了。从最开始的"工具注册不上"，到现在的"一句话生成文章、一键发布、自动拿文章链接"，中间绕了不少弯路。这篇就当是我的一份测试记录，把这次 v4 版本的测试过程和踩坑经验完整理一遍，希望对打算在内容生产链路里接入 MCP 的人有点帮助。
先说结论：MCP 这套协议本身不复杂，真正麻烦的地方在于"目标平台"的接口形态、认证方式、字段约束，以及 Agent 在调用工具时对参数的理解偏差。CSDN 发帖这个场景不算难，但它把 MCP 服务开发、认证处理、内容格式约定、工具调用稳定性这些问题全串起来了，是一个非常适合上手的实战项目。
1. 为什么会有"CSDN 发帖 MCP"这种需求
1.1 MCP 到底解决了什么问题
MCP（Model Context Protocol）是给大模型应用提供的一种标准化工具调用协议。你可以把它理解成"AI 世界的 USB 接口"：不管底层是哪个模型、哪个客户端，只要两边都支持 MCP，模型就能通过一套统一的协议去调用外部工具，完成读文件、查数据库、调 API、发消息这些操作。
没接触过的人可能会问：直接让 AI 调用 HTTP 接口不行吗？当然行，但那是"一次性对接"。MCP 的价值在于：工具发现、参数校验、结果返回、错误处理这些事都被协议层标准化了。AI 客户端启动时会自动拉取工具列表，模型根据工具描述决定调用哪个工具，调用结果通过 JSON 结构返回。这套流程一旦跑通，后续接新的工具服务就非常简单。
1.2 发博客这个场景为什么有代表性
写博客的人多少都经历过这种状态：文章在本地写完，要复制到编辑器里，调整格式，贴封面图，填标签，最后点发布。如果是用 AI 辅助写文章，这个"复制粘贴"的过程就更痛苦了——AI 生成的是 Markdown，平台编辑器里贴进去经常变样。
把"发帖"做成 MCP 服务之后，流程就变成了：在 AI 客户端里直接说"帮我把本地这篇 xxx.md 发到 CSDN，标签加上 MCP、AI 编程，分类选后端"，Agent 会自己读取文件、调用发帖工具、提交内容、返回文章链接。这中间省掉的不是一次复制粘贴，而是整条"内容生成 → 格式转换 → 平台发布"的手动链路。
从平台角度看，CSDN 是中文技术社区里博客存量很大的一个平台，很多开发者会在上面做内容分发。我把发帖能力封装成 MCP 服务，本质上就是在"AI 工作流"和"内容平台"之间架一座桥。
1.3 先说明白：这是社区服务，不是官方 MCP 市场
开始之前必须澄清一点：CSDN 官方并没有正式发布过 MCP 服务。现在网上能搜到的"CSDN MCP"，基本都是开发者根据 CSDN 博客后台的发布接口自己封装的社区项目。这也意味着：接口变动风险、鉴权方式、字段兼容性这些问题，都需要自己测试、自己维护。
我这次测试的 v4 版本，就是这样一个社区实现。它把"登录态管理、草稿创建、正式发布、状态查询"封装成了几个 MCP 工具。理解了这一点，后面再看到各种"xx平台 MCP 服务"，你就会有同样的判断框架：本质上就是有人把平台上手工能做的事，翻译成了 MCP 工具。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 一次 MCP 发帖请求的完整调用路径
2.1 三个角色：客户端、服务端、目标平台
一次发帖请求，整条链路里至少有三个角色：
- MCP 客户端：AI 应用本体，比如 Claude Desktop、Cherry Studio、VS Code 里的 Codex / Cursor 等。它负责理解用户意图，决定调用哪个工具。
- MCP 服务端：我们开发的这个"CSDN 发帖服务"。它接收客户端发来的工具调用请求，执行真正的发帖动作。
- CSDN 平台：最终的内容落地平台，接收 HTTP 请求，完成文章存储和展示。
每次调用，数据流大致是这样的：
- 客户端启动时通过 MCP 协议从服务端拉取工具列表；
- 用户在对话框里输入指令；
- AI 判断需要调用
post_article工具，把参数（标题、正文、标签等）打包成 JSON 发送给服务端； - 服务端校验参数，带上用户配置的登录凭证，向 CSDN 的发布接口发起请求；
- CSDN 返回文章 ID 或链接；
- 服务端把这些信息整理成标准格式返回给 AI；
- AI 根据返回结果，用自然语言告诉用户"发布成功，文章链接是 xxx"。
这一步看似简单，但每一步都可能出问题。后面第 4 节我会专门讲我在测试中遇到的坑。