Skip to main content
Glama
enesjakozh
AzDeltaQQ

MCP Advanced Reasoning Server

by AzDeltaQQ
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

值得一提的是：

https://github.com/Jacck/mcp-reasoner

感谢 Jackk 给我这个想法。

光标AI的MCP高级推理服务器

模型上下文协议 (MCP) 服务器为 Cursor AI 中的 Claude 提供高级推理能力。

特征

  • 蒙特卡洛树搜索（MCTS） ：使用 MCTS 推理解决复杂的问题任务。

  • 定向搜索：同时探索多条推理路径。

  • R1 Transformer ：利用基于 Transformer 的推理解决复杂问题。

  • 混合推理：将 Transformer 分析与 MCTS 相结合，增强推理能力。

  • 自动迭代推理：所有多步骤推理方法在一次工具调用中自动完成所有推理步骤。

Related MCP server: MCP Think

安装

npm install
npm run build

用法

使用 Cursor AI 配置

  1. 首先搭建服务器：

    cd mcp-reasoning-server
npm run build

  2. 打开光标AI

  3. 导航至“设置”>“功能”>“MCP”

  4. 点击“+ 添加新的全局 MCP 服务器”按钮

  5. 输入以下详细信息：

    • 在命令字段中： node C:\\Users\\[YourUsername]\\path\\to\\mcp-reasoning-server\\dist\\index.js

    • 确保使用项目 dist/index.js 文件的完整路径

    • 对 Windows 路径使用双反斜杠

  6. 点击“添加”

  7. 在列表中找到您的服务器（它最初会显示为“已禁用”）

  8. 单击“已禁用”将其切换为“已启用”

  9. 单击刷新按钮以加载可用的工具

  10. 命令提示符窗口将自动打开 - 这是您的服务器正在运行

  11. 只要此命令提示符窗口保持打开状态，推理工具就可用

或者，您可以手动编辑位于C:\Users\[Username]\.cursor\mcp.json (Windows) 的 Cursor MCP 配置文件：

{
  "mcpServers": {
    "mcp-reasoner": {
      "command": "node",
      "args": ["C:\\Users\\[Username]\\path\\to\\mcp-reasoning-server\\dist\\index.js"]
    }
  }
}

重要提示

  • 服务器运行：这些工具仅在命令提示符窗口打开并运行时可用

  • 进行更改：如果您对服务器代码进行了更改，则必须在重新启动之前使用npm run build重新构建它

  • 重新启动：要重新启动服务器，请关闭命令提示符窗口并在“光标设置”中关闭/打开服务器

使用推理工具

您可以在 Cursor AI 与 Claude 的对话中直接使用推理工具：

MCTS推理

使用/reason-mcts命令后跟您的查询来启动基于 MCTS 的推理链：

/reason-mcts How can I optimize the performance of this React component?

定向搜索推理

使用/reason-beam命令进行基于波束搜索的推理：

/reason-beam What architecture would be best for this microservice system?

R1 Transformer 推理

使用/reason-r1命令进行单步基于Transformer的推理：

/reason-r1 Analyze the complexity of this algorithm.

混合推理

使用/reason-hybrid命令将Transformer与MCTS推理结合起来：

/reason-hybrid How should we approach refactoring this legacy codebase?

克劳德积分

为了让 Claude 更容易使用这些推理工具，可以添加以下自定义指令：

When I use commands like /reason-mcts, /reason-beam, /reason-r1, or /reason-hybrid in chat, interpret them as requests to use the corresponding reasoning tools:

/reason-mcts: Use the reason_mcts tool with the text following the command as the query
Example: "/reason-mcts How do I solve this problem?" should call the reason_mcts tool

/reason-beam: Use the reason_beam tool with the text following the command as the query
Example: "/reason-beam What's the best approach for this complex problem?" should call the reason_beam tool

/reason-r1: Use the reason_r1 tool with the text following the command as the query
Example: "/reason-r1 Analyze this code for performance issues" should call the reason_r1 tool

/reason-hybrid: Use the reason_hybrid tool with the text following the command as the query
Example: "/reason-hybrid How should we restructure this architecture?" should call the reason_hybrid tool

When these commands are used, extract the text after the command as the query parameter and use the corresponding tool to perform advanced reasoning.

发展

项目结构

  • src/index.ts ：主服务器入口点

  • src/tools/reasoning-tools.ts ：推理工具的实现

  • src/tools/reasoning-wrapper.ts ：命令包装器，方便在 Cursor 中使用

  • src/utils/errors.ts ：错误处理实用程序

自动迭代推理

推理工具的实现方式是在单次工具调用过程中自动在内部完成所有推理步骤。每种推理方法都遵循以下流程：

  1. 初始化第一个想法/步骤

  2. 自动生成后续想法/步骤

  3. 将所有想法连同最终结果一起归还

这种方法可确保推理过程完全完成，而无需多次手动工具调用。

添加新的推理方法

要添加新的推理方法，请按照以下步骤操作：

  1. 在src/tools/reasoning-tools.ts中添加新的工具实现

  2. 在src/tools/reasoning-wrapper.ts中添加相应的命令包装器

  3. 遵循现有工具的模式，定义参数和响应格式

  4. 如果是多步骤推理方法，则实现自动迭代

  5. 使用npm run build重建项目

限制

这是一个模拟推理服务器。在实际生产环境中，您将连接到实际的推理算法，而不是当前使用的占位符响应。

执照

国际学习中心

Available Tools

8 tools
beam_search_reasoningD
ParametersJSON Schema
NameRequiredDescriptionDefault
promptYesThe problem or query to reason about
thoughtYesCurrent reasoning step
thoughtNumberYesCurrent step number
totalThoughtsYesTotal expected steps
nextThoughtNeededYesWhether another step is needed
beamWidthNoNumber of top paths to maintain (n-sampling)

TDQS

D1/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

hybrid_reasoningD
ParametersJSON Schema
NameRequiredDescriptionDefault
promptYesThe problem or query to reason about
thoughtYesCurrent reasoning step
thoughtNumberYesCurrent step number
totalThoughtsYesTotal expected steps
nextThoughtNeededYesWhether another step is needed
numSimulationsNoNumber of MCTS simulations to run

TDQS

D1/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcts_reasoningD
ParametersJSON Schema
NameRequiredDescriptionDefault
promptYesThe problem or query to reason about
thoughtYesCurrent reasoning step
thoughtNumberYesCurrent step number
totalThoughtsYesTotal expected steps
nextThoughtNeededYesWhether another step is needed
numSimulationsNoNumber of MCTS simulations to run

TDQS

D1/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

r1_reasoningD
ParametersJSON Schema
NameRequiredDescriptionDefault
promptYesThe problem or query to reason about

TDQS

D1/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

reason_beamD
ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesThe problem or task to reason about using Beam Search

TDQS

D1/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

reason_hybridD
ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesThe problem or task to reason about using Hybrid reasoning

TDQS

D1/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

reason_mctsD
ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesThe problem or task to reason about using MCTS

TDQS

D1/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

reason_r1D
ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesThe problem or task to reason about using R1 Transformer

TDQS

D1/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 8 tool updates
    • First observedbeam_search_reasoning
    • First observedhybrid_reasoning
    • First observedmcts_reasoning
    • First observedr1_reasoning
    • First observedreason_beam
    • First observedreason_hybrid
    • First observedreason_mcts
    • First observedreason_r1
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

D1.3/5.0

Scored across 8 tools

Disambiguation1/5

The tool set has severe ambiguity issues with multiple tools appearing to do the same thing. There are clear duplicates: beam_search_reasoning and reason_beam, hybrid_reasoning and reason_hybrid, mcts_reasoning and reason_mcts, r1_reasoning and reason_r1. Without descriptions, these appear to be identical pairs, making it impossible for an agent to distinguish between them.

Naming Consistency2/5

The naming is inconsistent with two different patterns mixed together: some use 'algorithm_reasoning' (e.g., beam_search_reasoning) while others use 'reason_algorithm' (e.g., reason_beam). This creates confusion and lacks a unified convention, though both patterns are readable individually.

Tool Count3/5

With 8 tools, the count is reasonable for a reasoning server, but the apparent duplication suggests it's borderline. If these are truly 4 distinct algorithms with redundant naming, the effective count would be 4, which feels thin for an 'advanced' reasoning server.

Completeness2/5

The server appears to cover multiple reasoning algorithms (beam search, hybrid, MCTS, R1), but without descriptions, it's unclear if there are gaps in the reasoning lifecycle. The duplication suggests potential missing operations like configuration or result retrieval, and the lack of clear domain coverage makes assessment difficult.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches