Boundary MCP is a decision structure analysis engine that helps clarify complex life decisions by exposing underlying variables, constraints, and strategies without providing definitive answers.
Core Capabilities:
• De-emotionalize problems - Transforms anxious, emotionally charged questions into objective, structured decision problems
• Identify decision components - Extracts goals, key variables, hard constraints (visa limits, finances, time windows), and sources of uncertainty
• Generate strategy space - Creates multiple strategic paths (aggressive, conservative, hedging, stop-loss) rather than a single "correct" answer
• Analyze risk distribution - Provides probability ranges for potential outcomes of each strategy (e.g., 20% optimal, 35% partial success) instead of deterministic predictions
• Detect cognitive biases - Identifies thinking blind spots like survivorship bias, groupthink pressure, anchoring effects, and short-term focus
• Provide structured outputs - Offers formatted analysis reports (analyze_decision) and raw JSON data (get_analysis_json) for programmatic use
• Support major life decisions - Applicable to career changes, geographic moves, major investments, relationships, and education choices
• Integrate with MCP clients - Works with Claude Desktop, Claude Code, and other Model Context Protocol compatible tools
Core Philosophy: The tool never tells you what to do—it only helps you see clearly what you're betting on, exposing decision structure rather than providing prescriptive advice or emotional support.
Click on "Install 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., "@Boundary MCP Analyze my dilemma: quitting my job to move abroad despite limited savings and family ties."
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.
不告诉你该怎么做，只帮你看清你在赌什么。
你是否遇到过这样的时刻：
凌晨三点睡不着，反复问自己「要不要辞职」「要不要出国」「要不要 all in」
打开搜索引擎，看了 100 篇「过来人」的建议，却越看越焦虑
问了 AI 一个人生问题，得到一堆「要综合考虑」的正确废话
最后发现：你不是缺答案，你是看不清问题本身
传统的建议型工具会告诉你「应该这样做」，但它们忽略了一个事实：
你的人生没有标准答案，只有属于你的约束和边界。
Related MCP server: Waldzell Metagames Server
Boundary MCP 是一个决策结构分析引擎，基于 Model Context Protocol。
它不会：
❌ 告诉你「该不该做」
❌ 预测你会成功还是失败
❌ 给你情绪安慰或成功学鸡汤
❌ 迎合你已有的立场
它只会：
✅ 把你焦虑模糊的问题，翻译成可分析的结构
✅ 告诉你：你有哪些目标、变量、约束、不确定性
✅ 展示多条策略路径，而不是「唯一正确答案」
✅ 提醒你可能存在的认知盲点
最终选择，永远是你自己的。
把「我好焦虑，再不润就来不及了」变成：
在给定个人背景、目标和约束条件下，地理迁移相比现状的长期价值与成本结构是什么？
目标:
- 长期收入稳定性
- 职业发展空间
- 身份与安全边际
关键变量:
- 年龄
- 技能可迁移性
- 资金储备
硬约束:
- 签证/政策限制
- 时间窗口
- 家庭责任
不确定性:
- 政策变化
- 经济周期波动不给你「最优解」，给你完整的选择空间：
策略 | 类型 | 核心思路 |
策略 A | 激进型 | 立即行动，主动出击 |
策略 B | 保守型 | 观望等待，收集信息 |
策略 C | 对冲型 | 双轨并行，分散风险 |
策略 D | 止损型 | 放弃该路径，转向其他 |
不说「会成功」或「会失败」，只给概率区间：
策略 A 的结果分布：
20% ████ 目标达成，收益符合或超出预期
35% ███████ 部分达成，结果低于预期但有所收获
30% ██████ 遇到较大阻力，需要调整计划
15% ███ 执行失败，需要承受损失并重新规划主动指出你可能的思维盲点：
⚠️ 幸存者偏差：可能将个别成功案例误认为普遍路径
建议：主动寻找失败案例，关注基础率而非个案。
无需安装，直接在 MCP 客户端配置中使用：
npx @eternalheart/mcp-boundarynpm install -g @eternalheart/mcp-boundarygit clone https://github.com/wh131462/mcp-boundary.git
cd mcp-boundary
npm install
npm run build运行以下命令添加 MCP 服务器：
claude mcp add boundary -- npx @eternalheart/mcp-boundary或手动编辑配置文件 ~/.claude.json：
{
"mcpServers": {
"boundary": {
"command": "npx",
"args": ["@eternalheart/mcp-boundary"]
}
}
}编辑配置文件：
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"boundary": {
"command": "npx",
"args": ["@eternalheart/mcp-boundary"]
}
}
}任何支持 MCP 协议的客户端都可以使用，配置方式类似。
在配置好的 MCP 客户端中，直接描述你的决策困境：
请帮我分析：我今年 30 岁，做了 5 年后端开发，最近很焦虑，
看到身边朋友都在准备出国，我是不是也该考虑润了？
但是我英语一般，存款也不多，父母年纪大了...AI 会调用 analyze_decision 工具，返回完整的决策结构分析报告。
工具名 | 描述 |
| 完整的决策结构分析，返回格式化报告 |
| 返回结构化 JSON，适合程序化处理 |
这四条原则贯穿整个工具的设计，不可违背：
原则 | 实现 |
不做决定 | 只暴露结构，展示多条路径 |
不给答案 | 只给边界，明确约束和变量 |
不预测未来 | 只给分布，用概率区间代替确定性 |
不迎合情绪 | 只校正幻觉，主动提示认知偏差 |
🎯 职业转型：要不要换行业 / 换城市 / 换赛道
🌍 地理选择：要不要出国 / 回国 / 去哪个城市
💰 重大投资：要不要创业 / 买房 / 大额投入
🤝 人生关系：要不要结婚 / 离婚 / 重大承诺
📚 教育投资：要不要考研 / 读博 / 技能培训
❌ 寻找「正确答案」或「最优解」
❌ 需要情绪支持和安慰
❌ 简单的是非判断题
❌ 需要预测具体结果
# 决策结构分析报告
## 1. 问题重述
**原始问题：**
> 我真的很焦虑，感觉再不润就来不及了，国内卷得要死，看别人都出去了，我是不是也该赶紧跑？
**重述后的核心问题：**
> 在给定个人背景、目标和约束条件下，地理迁移相比现状的长期价值与成本结构是什么？
**识别出的情绪化元素：**
- 焦虑情绪：'真的很焦虑'
- 紧迫感假设：'再不...就来不及'
- 群体压力：'看别人都出去了'
- 竞争焦虑：'卷得要死'
## 2. 变量与约束
### 目标
- 长期收入稳定性
- 职业发展空间
- 身份与安全边际
### 关键变量
- 年龄
- 技能可迁移性
- 资金储备
- 语言能力
### 硬约束
- 签证/政策限制
- 资金约束
- 时间窗口
### 不确定性来源
- 政策变化
- 经济周期波动
- 行业发展趋势
## 3. 策略空间
### 策略 A：立即行动（激进型）
**前提条件：** 对目标有清晰认知，具备基本资源，能承受最坏后果
**执行成本：** 时间全力投入；资金需前期投入；放弃其他路径
**最坏情况：** 全力投入后失败，损失时间和资金，难以回到原点
### 策略 B：观望等待（保守型）
**前提条件：** 当前状态可持续，等待期有信息渠道，延迟不会丧失机会
**执行成本：** 等待期时间消耗；可能错过窗口期；持续焦虑
**最坏情况：** 窗口关闭，最佳时机永久错过
### 策略 C：双轨并行（对冲型）
**前提条件：** 有精力维护多条路径，路径间无严重冲突
**执行成本：** 精力分散；可能双重投入；效率损失
**最坏情况：** 两边都未取得进展，资源分散导致竞争力不足
### 策略 D：转向放弃（止损型）
**前提条件：** 存在可行替代方向，沉没成本可接受
**执行成本：** 沉没成本；心理接受成本；重建成本
**最坏情况：** 放弃后原方向意外变好，产生强烈后悔
## 4. 风险与回报分布
### 策略 A：立即行动
20% ████ 目标达成，收益符合或超出预期
35% ███████ 部分达成，结果低于预期但有所收获
30% ██████ 遇到较大阻力，需要调整计划
15% ███ 执行失败，需要承受损失并重新规划
## 5. 认知偏差提示
### ⚠️ 群体压力
**表现：** 从表述中检测到：群体压力：'看别人都出去了'
**建议：** 明确自己的独特条件和目标，不同人适合不同路径。
### ⚠️ 短期聚焦偏差
**表现：** 从表述中检测到：紧迫感假设：'再不...就来不及'
**建议：** 拉长时间维度思考，区分'真紧迫'和'假紧迫'。
---
*本分析旨在暴露决策结构，而非给出答案。最终选择取决于你对自身目标和约束的权衡。*Runtime: Node.js
Language: TypeScript
Protocol: Model Context Protocol (MCP)
Schema: Zod
# 开发模式（热重载）
npm run dev
# 构建
npm run build
# 使用 MCP Inspector 调试
npm run inspectsrc/
├── index.ts # MCP 服务器入口
├── types/ # 类型定义
├── analyzers/ # 核心分析模块
│ ├── reframe.ts # 问题重述
│ ├── variables.ts # 变量识别
│ ├── strategies.ts # 策略生成
│ ├── risk.ts # 风险分析
│ └── bias.ts # 偏差检测
├── prompts/ # 提示词模板
└── tools/ # MCP 工具定义"人生不是一道有标准答案的选择题，而是一场在不确定性中做决策的游戏。
你能做的不是找到'正确答案'，而是看清自己在赌什么，然后为自己的选择负责。"
这个工具的存在，是为了帮你在做决定之前，先把牌桌上的筹码数清楚。
MIT
感谢每一个在深夜辗转反侧、认真思考人生的你。
决策的勇气不在于找到正确答案，而在于看清边界后依然敢于选择。
对现实问题进行结构化策略分析。
这是一个"暴露现实结构"的决策思考引擎，而不是建议生成器。
功能：
问题去情绪化重述 - 将模糊、情绪化的问题转化为客观、结构化的决策问题
关键变量与约束识别 - 识别目标、关键变量、硬约束和不确定性来源
策略空间生成 - 生成多个可选策略路径（激进、保守、对冲、止损）
风险与回报分布分析 - 为每个策略生成概率分布，而非确定性预测
认知偏差与幻觉提示 - 识别可能影响决策的认知偏差
注意：本工具不会告诉你"该不该做"，只会帮助你看清决策的结构和边界。
| Name | Required | Description | Default |
|---|---|---|---|
| problem_text | Yes | 用户描述的决策问题，可以包含情绪、立场、焦虑等自然表达 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does an excellent job describing what the tool does (5 specific functions), what it doesn't do (won't provide recommendations), and its philosophical approach ('expose reality structure'). However, it doesn't mention technical behaviors like response format, processing time, or error conditions that would be helpful for an AI agent.
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 perfectly structured and front-loaded with the core purpose, followed by specific functions in a numbered list, and concluding with important limitations. Every sentence earns its place by adding distinct value, with no redundancy or wasted words. The bilingual presentation (Chinese with English translation) is efficiently handled.
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 (5 distinct functions) and absence of both annotations and output schema, the description does an excellent job explaining what the tool does and doesn't do. However, without an output schema, the description doesn't specify what format the analysis results will be returned in, which is a gap for an AI agent trying to use this tool effectively.
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 schema has 100% description coverage for its single parameter, so the baseline is 3. The description adds meaningful context by explaining that the problem_text parameter should contain 'emotional, positional, anxious natural expressions' that will be 'de-emotionalized and restructured.' This provides valuable semantic context beyond the schema's technical description.
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 explicitly states the tool's purpose as 'structured strategy analysis for real-world problems' and clearly distinguishes it from a suggestion generator. It provides a specific verb ('analyze') and resource ('decision problems') while differentiating from the sibling tool get_analysis_json by emphasizing its unique 'expose reality structure' approach rather than generating recommendations.
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 provides explicit guidance on when to use this tool ('for structured strategy analysis of real-world problems') and when not to use it ('will not tell you whether to do something'). It clearly distinguishes this tool's purpose from alternatives by stating it's 'not a suggestion generator' and only helps 'see the structure and boundaries of decisions'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取决策分析的原始 JSON 数据结构。
与 analyze_decision 功能相同，但返回结构化的 JSON 数据而非格式化文本。 适用于需要程序化处理分析结果的场景。
| Name | Required | Description | Default |
|---|---|---|---|
| problem_text | Yes | 用户描述的决策问题 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description states it returns '原始 JSON 数据结构' (raw JSON data structure), which implies a read-only operation that doesn't modify data. However, it doesn't disclose other behavioral traits like error conditions, rate limits, authentication requirements, or what the JSON structure contains. The description adds some context about the return format but lacks comprehensive behavioral details.
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 extremely concise and well-structured with just two sentences. The first sentence states the core purpose, and the second sentence provides differentiation from the sibling tool and usage context. Every sentence earns its place with no wasted words.
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 simple nature (single parameter, no output schema, no annotations), the description is reasonably complete. It clearly explains what the tool does, how it differs from its sibling, and when to use it. However, without an output schema, the description could better explain what the returned JSON structure contains. The lack of annotations means the description should ideally cover more behavioral aspects.
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 schema description coverage is 100% with one parameter ('problem_text') fully documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema. According to the scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter information in the description.
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 clearly states the tool's purpose: '获取决策分析的原始 JSON 数据结构' (get the raw JSON data structure for decision analysis). It specifies the verb ('获取' - get) and resource ('决策分析的原始 JSON 数据结构' - raw JSON data structure for decision analysis), and explicitly distinguishes it from its sibling tool 'analyze_decision' by noting it returns structured JSON data instead of formatted text.
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 provides explicit guidance on when to use this tool versus its alternative: '与 analyze_decision 功能相同，但返回结构化的 JSON 数据而非格式化文本。适用于需要程序化处理分析结果的场景。' (Same functionality as analyze_decision, but returns structured JSON data instead of formatted text. Suitable for scenarios requiring programmatic processing of analysis results). This clearly defines the use case and names the alternative tool.
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.
analyze_decisionget_analysis_jsonScored across 2 tools
The two tools are essentially identical in purpose, both performing structured decision analysis on real-world problems. The only difference is output format (formatted text vs. JSON), which is insufficient to distinguish their core functionality. An agent would likely struggle to choose between them without arbitrary preference for output type.
Both tools follow a consistent verb_noun naming pattern with clear, descriptive names. 'analyze_decision' and 'get_analysis_json' maintain the same structure and style, making them predictable and easy to understand within the set.
With only two tools that essentially duplicate functionality, the count feels too thin for a decision analysis engine. A more complete surface might include tools for different analysis phases (e.g., problem framing, constraint identification, strategy evaluation) rather than just output format variants.
The server claims to be a 'decision thinking engine' but offers only a single analysis operation in two output formats. There are obvious gaps: no tools for modifying analyses, comparing multiple decisions, tracking decision outcomes, or integrating external data—all expected in a comprehensive decision support system.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Adversarial behavioural-bias engine — audits your decisions for cognitive biases via your own AI.
Multi-expert decision intelligence with transparent synthesis and auditable workflows.
Deterministic multi-criteria decision analysis for AI agents — score, rank & explain options.
Deterministic reasoning stack for AI agents: simulate, decide & compute, plus cross-domain tools.
