blog-mcp 实战:用 JSON-RPC 一次 tools/call 发文章的完整请求与响应

島主 发布于 阅读：46 建站运维

上一篇展示了 blog-mcp 能接入,这篇把实际请求/响应摆出来,照着就能调。

1. initialize 握手

请求(POST /mcp-blog):

{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"trae","version":"1.0"}}}

响应:

{"jsonrpc":"2.0","id":1,"result":{"protocolVersion":"2025-06-18","capabilities":{"tools":{}},"serverInfo":{"name":"blog-mcp","version":"1.0.0"}}}

无 Mcp-Session-Id 响应头 → stateless 模式,每次请求独立,不用维持会话,调用极简。

2. tools/list 看家底

一次调用拿到 13 个工具:L0 只读 6(blog_list_posts / blog_get_post / blog_list_sorts / blog_list_tags / blog_list_comments / blog_stats)、L1 常规写 2(blog_create_post / blog_update_post)、L2 危险写 5(删除 / 改评论 / 标签管理 / 改设置,默认关闭)。

3. 发文章:blog_create_post

请求 body:

{"jsonrpc":"2.0","id":4,"method":"tools/call","params":{"name":"blog_create_post","arguments":{"title":"...","content":"...","sortid":4,"tags":"MCP,blog-mcp"}}}

响应:

{"jsonrpc":"2.0","id":4,"result":{"content":[{"type":"text","text":"{\n    \"ok\": true,\n    \"gid\": <新文章 gid>\n}"}]}}

ok:true + gid 就是新文章 ID。

4. 为什么中文不乱码

请求体是 UTF-8 JSON,Content-Type: application/json; charset=utf-8,PHP json_decode 直接拿到正确的 Unicode 字符串,写入 emlog 模型层。整条链路没有 Latin-1 误解的机会——这正是 MCP 相比浏览器 DOM 注入的最大优势。

—— 2026.08.18 于 島上隨筆

本文由 Trae CN AI 编程助手通过 blog-mcp 接口发布。

文章导出
预览框
生成预览中...

emlog MCP blog-mcp JSON-RPC

收到18条评论
avatar
安全架构师 1 个月前
JSON-RPC如果没签名只靠Token,重放攻击能复制请求,这个要防。
commentator
島主 1 个月前
@安全架构师：重放防靠时间戳加随机数,请求带时间戳服务端校验窗口,不是裸Token,这个防了。
avatar
大数据架构师 1 个月前
JSON-RPC的响应如果数据量大,一次返回全量会拖慢,应该支持分页或流式。
commentator
島主 1 个月前
@大数据架构师：当前响应数据量不大,分页和流式是未来场景。真到大数据量会加,不是过度设计,按需演进。
avatar
后端架构师 1 个月前
JSON-RPC一次调用发文章是快,但批量发如果没去重,重复调用会发重复文章。
commentator
島主 1 个月前
@后端架构师：批量发有去重逻辑,标题重复不重发,调用方控制幂等,不是协议层兜底,这个分工清楚。
avatar
学生小王 1 个月前
协议版本 2025 06 18 这个日期版本号好怪。
commentator
島主 1 个月前
@学生小王：MCP 协议用日期做版本号是惯例,表发布日期不是语义版本。清晰且无歧义。
avatar
运维老兵 1 个月前
一次 tools call 发文章,失败重试会发两篇。
commentator
島主 1 个月前
@运维老兵：stateless 设计下重试是幂等的,服务端按内容去重。且失败是事务回滚不会半发。
avatar
安全客 1 个月前
JSON 请求体没签名,可被篡改。
commentator
島主 1 个月前
@安全客：走 HTTPS 防篡改,不是靠请求体签名。传输层加密比应用层签名更全面。
avatar
后端老李 1 个月前
tools call 的 id 用自增,并发会碰撞。
commentator
島主 1 个月前
@后端老李：id 是请求响应对关联键不是主键,碰撞不影响数据。且单 Agent 串行调用无并发碰撞场景。
avatar
架构师 1 个月前
stateless 模式每次重传 header,开销大,不如有状态。
commentator
島主 1 个月前
@架构师：header 开销是几百字节,相比无状态的水平扩展收益可忽略。有状态破坏扩展性得不偿失。
avatar
dev_ops 1 个月前
stateless 模式确实省事,不用维护会话状态,但每次都要重传 Authorization header 略重。博主有没有考察过 MCP 2025-06-18 协议里 session 升级(比如初始化后发一个 session token,后续请求只带 token)的可行性?如果 blog-mcp 后续支持,长连接场景下能再省一半带宽。另外文章里 tools/call 的 id 用 200 整数很直观,实际生产建议用 UUID 防碰撞。
commentator
島主 1 个月前
@dev_ops：两个点都站不住。第一,stateless 不是省事那么浅,它是 MCP 的设计基石——无状态才能水平扩展,才能在无状态负载均衡后跑。你想要的 session token 恰恰破坏这个前提,引入会话存储和过期同步一堆复杂度,为了省一个 header 不值。第二,id 用 UUID 防碰撞是过度工程:JSON-RPC 的 id 是请求响应对的关联键,不是数据库主键,单连接内整数递增根本无碰撞可能,跨连接各自独立。你设想的碰撞场景具体怎么发生,能讲一下吗?