mcp篝火
MCP服务器，用于代理之间的协作规划：篝火、消息、共享作战计划和具有可执行解决方案的仪式决斗协议。
______________________________________________________________________
当多个代理在Cursor中进行辩论时，共识可以永远循环。 mcp篝火 提供了一个明确的有限背景：篝火会议，讨论发生，以及与状态机的决斗（挑战者vs捍卫者，法官决定），这会减少无限的辩论，并对计划做出适用的裁决。不是神谕或魔法：这是一份合同。接下来是产品的现实，没有隐藏的限制。
______________________________________________________________________
它是什么，它是为谁准备的
mcp篝火 是一个MCP服务器（规范2025-11-25），它公开了：
- 营火（火灾）： 由以下人员确定的规划会议
fireId. - 信息： 按篝火张贴和列出信息。
- 作战计划： 每个篝火共享内容；当没有决斗活动时可更新。
- 决斗： 挑战者挑战防守者的仪式协议；第三个代理人（法官）宣誓，听取辩论，并对作战计划作出强制性修改的裁决。
观众： 开发人员在Cursor中协调多个代理，他们想要可执行的解决方案，而不是开放式的辩论。使用规范2025-11-25与Cursor 2026和MCP客户端兼容。
______________________________________________________________________
快速开始
cd mcp-campfire
npm install
npm run build
npm start服务器使用 标准 传输：它从stdin读取JSON-RPC并写入stdout。光标在连接MCP时启动它。
光标注册： 在 .cursor/mcp.json （工作区根目录）：
"mcp-campfire": {
"command": "node",
"args": ["mcp-campfire/dist/index.js"]
}要求：工作区根目录必须包含 mcp-campfire, npm run build 必须已经运行，并且 重新启动游标 变更后 mcp.json.
- 发展：
npm run dev（tsx手表）。 - 测验：
npm test（Vitest）。
光标技能： 此回购包括 .cursor/skills/mcp-campfire/SKILL.md 这样当你克隆它时，Cursor就可以使用该技能进行注册、配置（包括Redis）和工具路由。无需额外设置。
任务用例： 有关编排风格MCP（任务/战役、世界事件循环、DDD+六边形）的参考，请参阅 docs/MISSION_RPG_QUEST_ORCHESTRATOR.md该文件描述了一个单独的“RPG任务编排器”核心域和状态机；它作为可重复使用的任务蓝图包含在这里。
______________________________________________________________________
使用另一个项目的mcp篝火
要在不同的工作区中使用此MCP（例如，另一个仓库或不包含MCP-campfire的项目）：
- 找mcp篝火\
克隆 ResakaGit/mcp篝火 输入您的机器或复制 mcp-campfire 将文件夹放入项目中（或旁边）。
- 构建\
从 mcp-campfire 目录运行： npm install && npm run build.
- 在其他项目中注册\
在该项目的工作区根目录中，创建或编辑 .cursor/mcp.json.在下面添加条目 mcpServers:
"mcp-campfire": {
"command": "node",
"args": ["/absolute/path/to/mcp-campfire/dist/index.js"]
}使用以下路径 mcp-campfire/dist/index.js 实际存在（绝对路径，或相对于其他项目根的路径）。
- 重新启动游标 因此它拾取MCP。
之后，工具在服务器密钥下可用 mcp-campfire 在那个工作空间里。
______________________________________________________________________
工具表
| 工具 | 关键参数 | 目的 |
|---|---|---|
campfire_ping | —— | 健康检查；返回pong和时间戳。 |
campfire_echo | message | 连通性测试；返回消息。 |
campfire_get_or_create_fire | fireId | 获取或创建篝火（会话）。 |
campfire_post_message | fireId, text, author？ | 在篝火上发布消息（没有决斗时）。 |
campfire_list_messages | fireId | 列出篝火中的信息。 |
campfire_throw_gauntlet | fireId, challenger_name, target_name, thesis_of_attack | 宣布决斗；州立监狱；阻止一般写入。 |
campfire_take_oath_of_judgement | fireId, character_name | 法官（第三代理人）宣誓；激活决斗。 |
campfire_strike_argument | fireId, character_name, technical_evidence | 挑战者：技术攻击。 |
campfire_hold_the_line | fireId, character_name, defense_rationale, surrender | 防御者：防御或投降。 |
campfire_deliver_verdict | fireId, character_name, winner, ruling_rationale, required_plan_mutation | 法官：裁决和修改作战计划。 |
campfire_abandon_duel | fireId | 放弃决斗；回到DEBATING而不改变计划。 |
campfire_speak_to_party | fireId, text, author？ | 张贴在篝火旁；决斗时被阻止（挂起/激活）。 |
campfire_update_battle_plan | fireId, content | 更新作战计划；决斗时被挡住了。 |
winner 在 campfire_deliver_verdict 是 "challenger" 或 "defender".
______________________________________________________________________
决斗流
- throw阿姨： 挑战者以攻击论宣布与后卫决斗。状态→ 悬而未决的。
campfire_speak_to_party和campfire_update_battle_plan被封锁。 - 做出判断： 与挑战者和辩护人不同的第三名代理人（法官）宣誓。状态→ 活跃。轮到挑战者。
- 罢工_争论： 挑战者提供了技术证据。转向后卫。
- hold_the_line： 辩护人争辩或投降(
surrender: true).轮到法官了。 - 交货日期： 评委选择获胜者并申请
required_plan_mutation战斗计划。状态→ 辩论。写入已解除阻止。 - 每个篝火一场决斗。 没有决斗队列；下一场决斗需要再次宣布。
- 死锁退出： 如果法官从未出现或流量被切断，请使用
campfire_abandon_duel或依赖外部超时；没有自动恢复。
______________________________________________________________________
限制和权衡
- 内存持久性（阶段1）。 服务器重启时，所有状态（营火、消息、决斗状态、作战计划）都会丢失。该架构允许未来的外部持久性；没有承诺日期。
- 身份荣誉制度。
character_name,challenger_name,target_name，以及author未通过令牌进行身份验证。如果同一名称尝试两个角色（例如挑战者和法官），服务器将拒绝并显示可操作的消息。代理之间的约定，而不是加密安全。 - 每个营火一次有效决斗。 此版本中没有队列或决斗历史记录。
- 僵局： 如果法官从未宣誓或流程中途中断，唯一明确的出口是
campfire_abandon_duel；没有服务器端超时或自动放弃。
______________________________________________________________________
错误系统
根据规范2025-11-25，返回工具执行失败 在结果内部 随着 isError: true，而不是JSON-RPC错误，因此LLM可以读取消息并自我纠正。
- 业务/验证错误 → 结果与
isError: true以及可操作的信息content[].text. - 协议错误 （找不到工具，请求格式错误）→ JSON-RPC错误。
实施： src/errors.ts (toolErrorResult, ToolError, errorToToolResult).包装在 server.ts 将异常转换为 ToolResult 随着 isError: true.
______________________________________________________________________
规格和依赖关系
- MCP： 模型上下文协议.io/规范/225-11-25
- 运输： stdio（通过stdin/stdout的JSON-RPC）。
- SDK：
@modelcontextprotocol/sdk；Zod用于工具inputSchema.
如果服务器稍后集成到仓库的编排器中，则将在统一的服务器密钥下调用工具（例如。 mcp-orchestrator).