北京
八年前Meta就有万亿参数模型了——但让AI真正"动手做事"，却是这两年才火起来的话题。MCP（模型上下文协议）就是干这个的：它让Claude这类对话模型不再只动嘴皮子，而是能直接操作外部系统。
我没光看文档，直接上手搭了个实战项目：让Claude读完我的草稿、改写成Markdown、自动发到Dev.to。三天跑通全流程后，我发现几个反直觉的细节。
第一步：让Claude"看见"你的工具
MCP的核心逻辑很简单——AI需要知道它能调用什么功能。我在Claude Desktop的配置文件里加了几行，指向自己写的Python服务，重启后Claude的输入框旁边就多了一个工具图标。
这个瞬间很关键：之前读再多架构图，不如亲眼看到"Publish Blog"按钮出现在AI界面里。协议层到应用层的打通，就这么朴素。
第二步：三个Python函数解决战斗
我的MCP服务器只暴露了三个工具：
• read_blog()：从本地读原始文本
• generate_markdown()：把口语化内容转成标准格式
• publish_to_devto()：调Dev.to API发文
代码结构比想象中轻量。用@app.tool()装饰器注册函数，Claude就能自动发现调用入口。不需要写复杂的意图识别，MCP协议帮你处理了"AI怎么知道该用哪个工具"的问题。
第三步：验证端到端闭环
我故意写了段很糙的草稿丢给它——口语化、没分段、格式混乱。Claude的完整操作链：
1. 调用read_blog()获取原文
2. 内部改写润色，生成标准Markdown
3. 调用publish_to_devto()完成发布
全程我没碰过Dev.to的后台。看着AI自己调API、返回200状态码，那种"它真的在执行"的实感，和看生成式回答完全不同。
两个踩坑经验
这个项目让我重新理解了"AI工具"的设计逻辑。
第一，返回结构比返回内容更重要。早期我图省事让函数返回"Success"字符串，结果Claude偶尔误判执行状态。改成标准JSON格式后：
{ "success": true, "message": "Blog published successfully", "url": "https://dev.to/xxx"}可靠性直接提升。AI代理需要可预测的字段来决策下一步，这是人和机器消费接口的根本差异。
第二，错误处理要假设AI会乱来。Dev.to API限流、Token过期、网络抖动——这些边界情况如果暴露给Claude，它会尝试"理解"错误信息并自行解决，有时候反而绕进死胡同。我在服务端做了更严格的预校验，把错误消化在MCP层，不给AI决策添乱。
这到底改变了什么？
说实话，单就"自动发博客"这个需求，Zapier或者GitHub Actions早就成熟了。但MCP的价值在于交互粒度：Claude不是按固定脚本执行，而是能根据内容实时调整——看到草稿太长发两部分、检测到代码块自动加语法高亮标签、甚至问我"这篇要加canonical链接吗"。
这种"有判断力的自动化"，是IFTTT链式反应做不到的。MCP把AI从回答者变成执行者，而执行过程中保留的决策弹性，才是协议设计真正狡猾的地方。
下一步我打算把同样的架构套到内部知识库上：让Claude读Notion文档、自动归档、给相关同事发摘要。工具还是那几个工具，但场景换到企业上下文，复杂度会指数级上升。
如果你也在玩Claude Desktop，建议别急着追新模型参数。花一个周末搭个MCP服务器，亲手让AI"做件事"——这种体感差异，比任何基准测试分数都直观。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
