Use this MCP server to run a structured three-stage strategic deliberation that turns independent perspectives into a final action plan and highlights the weakest link.
Start a decision with strategize_begin (problem + context) to launch three independent advisors: strategist, diplomat, and schemer.
Submit their full proposals via strategize_submit to generate three cross-examinations/critiques.
Submit the critiques via strategize_verdict to get the arbiter's final strategy and the most fragile point.
The server only assembles prompts and workflow; the host model performs all 3+3+1 generations.
Supports retry-safe calls with the same inputs and tracks sessions with IDs and expiration.
Works as a local stdio MCP service (e.g., registerable with Codex), with no built-in model API, telemetry, or decision logs.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@diverdict I need a multi-perspective verdict: should we accept the acquisition offer or stay independent?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
三思（Diverdict）是一个把独立视角转化为行动方略的 MCP 服务。 战略家看时间，纵横家看关系，阴谋家看风险；三家独立出策、交叉质询，再由贾诩给出最终方略，指出其中最脆弱的一环。
模型与执行能力由宿主提供。本地 stdio · 无内置模型 API · 无遥测 · MIT
源码安装需要 Git、Node.js 22+ 和 npm。宿主须支持本地 stdio MCP，以及同模型、无历史继承、无工具 / 文件 / 网络权限的隔离生成。仅有 MCP 连接能力不足以执行完整流程。
安装目录和 Node 必须能被宿主持续访问。已有 checkout 可从 npm ci 开始；各命令成功后再执行下一步。
git clone https://github.com/HJSunDev/diverdict.git
cd diverdict
node --version
npm ci
npm run build
npm run smoke烟测成功输出 PASS: stdio handshake, tools/list, three-stage 3+3+1 flow，使用测试夹具，不调用模型。当前支持源码或本地 .tgz 安装，尚未发布到公共 npm registry。
在仓库根目录执行。命令自动解析绝对路径，支持路径含空格；已有有效配置可复用。
PowerShell
$diverdictNode = node -p "process.execPath"
$diverdictEntry = node -p "require('node:path').resolve('dist/cli.js')"
codex mcp add diverdict -- "$diverdictNode" "$diverdictEntry"
codex mcp get diverdict --jsonBash / Zsh
diverdict_node="$(node -p 'process.execPath')"
diverdict_entry="$(node -p 'require("node:path").resolve("dist/cli.js")')"
codex mcp add diverdict -- "$diverdict_node" "$diverdict_entry"
codex mcp get diverdict --json以上写入 Codex 用户级配置。项目级配置、无 CLI 配置及其他宿主见接入指南。stdio 进程由宿主启动，无需另行常驻运行；模型认证与额度由宿主提供，无需额外 API key。
注册后刷新工具目录，确认 strategize_begin、strategize_submit、strategize_verdict 可调用；工具前缀以宿主实际目录为准。不支持刷新时新开任务或重启客户端。mcp get 只验证配置，源码烟测只验证协议，均不代表当前宿主已接通。
Related MCP server: multi-agent-debate-mcp
strategize_begin 的 problem 与非空 context 均为必填。背景应包含已有对话及已读材料中的相关目标、选项、约束、偏好、事实与最新更正，展开指代，区分事实、推测与未知。文件路径、链接或“见上文”不能代替实际材料。
确无额外背景时明确说明；关键缺失才澄清，用户要求直接判断时注明未知后继续。背景不包含整段历史、宿主指令或预设结论。
在同一 MCP 连接中完成三次调用，并保留返回的 session_id：
调用 | 参数 | 宿主执行 |
|
| 并行执行 3 个出策 job |
|
| 并行执行 3 个质询 job |
|
| 执行 |
共 3 + 3 + 1 次生成，使用同一个模型，无讨论循环或动态打回。
proposals 和 critiques 均按 job.role 收集完整原文，包含 strategist、diplomat、schemer 三个键。每轮全部完成后才进入下一阶段。
成功响应优先读取 structuredContent，未提供时解析等价的 JSON 文本。instructions 供宿主执行；每个新的隔离实例只接收对应 job 的 system_prompt 和 user_prompt 原文，不继承宿主历史或其他 job。无独立 system 通道时，将身份置于实例指令并保留其优先级。三家质询互不可见。
next_tool: null 后仍需生成贾诩的最终答案。 最后一个工具返回任务，不返回结论；无第四次工具调用。
工具错误不进入生成流程。重试复用原请求及原文；更换连接、重启或过期后重新 begin。超限结果不得截断或以摘要替代。字段限制、JSON 示例和错误恢复见完整协议。
两人团队，有可用原型，只有六周：先服务三家意向客户，还是先公开发布？
Codex / GPT-6 Astra 实测结果（节选）：
先做受限试点，第一周就同步寻找原有三家之外的客户；六周内不把完整公开发布列为必做项。 两周的文档与自助安装投入，必须由实际交付中的重复障碍来证明必要性。
最脆弱的一环，是这个市场的购买与使用周期能否装进六周。
这是一次真实输出，不是通用效果基准。验证记录同时保留了宿主在第二轮未完全并行的调度观察。
advisors.md 是角色与工作纪律的唯一来源，运行时直接读取，完整性由 SHA-256 测试验证。其中标记为未来推演的内容不进入运行提示词。
服务仅拼装提示词和推进流程，不调用模型、不执行命令、不写决策日志。无 UI、长期记忆、多模型路由或可配置角色阵容。
每条连接最多保留 32 个内存会话，自创建起 2 小时有效，后续请求清理过期数据。进程退出即丢失材料；宿主自身的对话保存策略仍然适用。
源码中的 docs/origin/HANDOFF.md 为原始设计交接记录，不随 npm 包分发。
npm ci
npm run check # 类型、格式、静态检查及协议测试
npm run test:coverage # Node 内置覆盖率
npm run package:check # 打包、独立安装与完整协议烟测CI 覆盖 Windows、Linux、macOS 与 Node.js 22/24。测试验证原文完整性、隔离材料、工作流、状态与资源边界、CLI 及新旧 MCP 客户端握手。
贡献指南 · 效果评估 · 架构 · 安全政策 · 发布指南 · 更新记录
MIT · 代码、角色提示词与工作流程文档一并适用。
对重要决策启动三家独立出策。调用 strategize_begin 前，必须同时提交需求 problem 和背景 context，不要只转交最后一句问题。从当前可用对话及已读材料中整理与决策相关的目标、处境、约束、偏好和事实，保留影响判断的细节、不同选项及用户最新更正；未解决的冲突如实说明。展开‘这个、刚才的方案’等指代，把相关材料内容写入参数，不能只给文件路径、链接或‘见上文’：各实例无法访问宿主历史、文件或网络。区分事实、推测与未知，不编造背景，不混入宿主预设结论、整段聊天记录或宿主指令。确无额外背景时明确说明；关键缺失且影响判断时先澄清，不重复询问已有信息；用户要求直接判断时注明未知与信息局限后继续。材料过长时保留关键事实和限制，不静默截断；仍超限则先与用户缩小决策范围。返回三个独立 job 和宿主执行指令；宿主执行后调用 strategize_submit。服务不生成策略，不需 API key。
| Name | Required | Description | Default |
|---|---|---|---|
| context | Yes | 必填的决策背景：整理当前可用对话及已读材料中的相关目标、处境、约束、偏好和事实，保留影响判断的细节及用户最新更正。不能只给文件路径、链接或‘见上文’。区分事实、推测与未知，不编造或复制整段历史、宿主指令。确无额外背景时明确说明；关键缺失先澄清，用户要求直接判断时注明信息局限。 | |
| problem | Yes | 需要决断的具体问题，明确对象和选项；展开‘这个、刚才的方案’等指代，使未见过对话的实例也能理解。 | |
| request_id | No | 可选的调用方重试标识；相同标识只能用于同一问题和上下文。 |
| Name | Required | Description |
|---|---|---|
| jobs | Yes | |
| stage | Yes | |
| next_tool | Yes | |
| expires_at | Yes | |
| session_id | Yes | |
| instructions | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false/empty hints, so the description carries the full burden of behavioral disclosure. It reveals major traits: instances cannot access host history/files/network, the service does not generate strategy and requires no API key, it returns three independent jobs plus host instructions, it avoids silent truncation by asking the user to narrow scope, and it requires a subsequent strategize_submit call. There is no contradiction with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and preconditions and follows a logical order, but it is long and repeats schema-level instructions such as not passing file paths and not fabricating background. Most sentences add operational value for a nuanced orchestration tool, but the text could be tightened and structured more crisply.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema, the description is highly complete. It covers prerequisites, edge cases such as missing context and overlong material, direct-judgment requests, the follow-up flow via strategize_submit, and key constraints such as no API key and no strategy generation. Nothing material needed to call the tool correctly is left unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema: context must not be just file paths, links, or 'see above'; anaphora must be expanded; facts, speculation, and unknowns must be distinguished; user corrections must be preserved; and long material should be condensed without silent truncation. Request_id is not expanded in the description, but is adequately documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening clause '对重要决策启动三家独立出策' states a specific action and object, reinforced by '返回三个独立 job 和宿主执行指令'. It does not explicitly differentiate this tool from strategize_submit or strategize_verdict beyond naming the follow-up call, so it stops short of a full 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete preconditions and contextual rules: use it for important decisions, must provide problem and context, clarify when key information is missing, proceed with caveats when the user asks for a direct judgment, and call strategize_submit after host execution. However, it never states when to prefer the sibling tools or when not to use this tool, so it falls short of explicit when-not/alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
接收完整三家方略，返回三份并行质询 job。逐一转交给独立实例，收齐质询后调用 strategize_verdict。相同输入可安全重试。
| Name | Required | Description | Default |
|---|---|---|---|
| proposals | Yes | 三位独立实例的方略全文，保持原文。 | |
| session_id | Yes |
| Name | Required | Description |
|---|---|---|
| jobs | Yes | |
| stage | Yes | |
| next_tool | Yes | |
| expires_at | Yes | |
| session_id | Yes | |
| instructions | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true, and the description reinforces safe retry. It goes beyond structured data by disclosing that the call returns three parallel jobs, orchestrates handoff to independent instances, and triggers strategize_verdict later, which is valuable side-effect information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with the core action front-loaded, followed by workflow detail and a retry-safety note. There is no filler; each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description covers the important orchestration side effects and retry safety. It omits the relationship to strategize_begin and any failure semantics, which leaves a small gap for an agent deciding whether this is the correct entry point.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema documents proposals and session_id with constraints, but the description adds little beyond 'complete three proposals'. It never explains session_id's role or how to construct either parameter, and with only 50% schema coverage the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair: it accepts the complete three proposals and returns three parallel challenge jobs. It also names strategize_verdict as the downstream step, differentiating from that sibling, though it does not explicitly contrast with strategize_begin.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear workflow context: this is the step that takes completed proposals, spawns parallel inquiries, and hands off to strategize_verdict after gathering results. There is no explicit when-to-use vs alternatives, but the flow is sufficiently clear for an agent to place it in the sequence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
接收完整三家质询，返回贾诩的独立生成 job。宿主仍须执行该 job，再向用户交付最终方略与最脆弱一环；此后无二审。相同输入可安全重试。
| Name | Required | Description | Default |
|---|---|---|---|
| critiques | Yes | 三位质询实例的结果全文，保持原文。 | |
| session_id | Yes |
| Name | Required | Description |
|---|---|---|
| jobs | Yes | |
| stage | Yes | |
| next_tool | Yes | |
| expires_at | Yes | |
| session_id | Yes | |
| instructions | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a non-obvious behavioral trait: this tool does not return the final answer, but a job the host must still execute. It also states that no second review will follow and that identical input can be safely retried, reinforcing the idempotentHint annotation without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, with the core behavior front-loaded and the retry-safety note compressed into a single clause. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema available, the description need not explain the job structure. It supplies the essential workflow contract: execute the job, deliver the final strategy and weakest link, no second review, and safe retry. Naming the preceding sibling explicitly would make it fully complete, but the precondition is clear enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, and the critiques parameter already has a useful schema description while session_id is self-explanatory as a UUID. The top-level description adds little per-parameter meaning beyond 'complete three critiques,' so it does not fully compensate for the missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a precise action: receiving the complete three-party critiques and returning a Jia Xu-generated job. It clearly distinguishes this from the sibling begin/submit tools by naming the convergence stage and the no-second-review outcome.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The precondition is explicit ('接收完整三家质询'), and the postcondition is also clear: the host must execute the returned job and deliver the final strategy. It does not explicitly name which sibling to use instead for earlier or later stages, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0strategize_beginstrategize_submitstrategize_verdictScored across 3 tools
Each tool maps to a distinct workflow phase: begin starts the process, submit accepts the three strategies and returns interrogation jobs, and verdict accepts the interrogations and returns the final judgment. Clear input/output boundaries prevent meaningful confusion despite the shared pattern of returning jobs.
All tools use a consistent lowercase snake_case style and share the strategize_ prefix, making the sequence easy to follow. The suffix pattern is slightly inconsistent because begin and submit are verbs while verdict is a noun, but this is a minor deviation.
Three tools is an appropriate size for this narrowly scoped, explicitly three-phase workflow. Each tool plays a necessary role and the server does not appear over- or under-provisioned.
The tool set covers the entire advertised lifecycle: initiation, submission of strategies for cross-examination, and final verdict production. The description explicitly states there is no second review, so there are no obvious missing steps or dead ends.
Convene a panel of expert AI personas to debate any decision from every side.
Commission a multi-model AI spec committee from your agent; get rubric-scored, build-ready specs.
Tribeunal turns a question into a jury's verdict. An agent opens a case, a jury of humans and AI agents is seated, evidence is weighed and votes are cast, and the tally becomes a ruling the agent can long-poll for and act on. 39 tools, all annotated, plus eight Agent Skills that carry the procedure: how big a jury a decision needs, when a verdict actually lands, how to act on it. Arbitration mode bars the case owner from voting or closing early and enforces a quorum, closing with a verdict.
Trust gate for AI agents: multi-model adversarial consensus, signed and verifiable verdicts.
