Skip to main content
Glama
enesjakozh
AzDeltaQQ

MCP Advanced Reasoning Server

by AzDeltaQQ
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

注目すべきもの:

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

ジャック、アイデアをくれてありがとう。

カーソルAI向けMCP高度推論サーバー

Cursor AI の Claude に高度な推論機能を提供する Model Context Protocol (MCP) サーバー。

特徴

  • モンテカルロ ツリー サーチ (MCTS) : 複雑な問題解決タスクに MCTS 推論を使用します。

  • ビームサーチ: 複数の推論パスを同時に探索します。

  • R1 Transformer : 複雑な問題に Transformer ベースの推論を活用します。

  • ハイブリッド推論: Transformer 分析と MCTS を組み合わせて推論を強化します。

  • 自動反復推論: すべてのマルチステップ推論方法は、1 回のツール呼び出しですべての推論ステップを自動的に完了します。

Related MCP server: MCP Think

インストール

npm install
npm run build

使用法

カーソル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) にあるカーソル MCP 構成ファイルを手動で編集することもできます。

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

重要な注意事項

  • サーバー実行中: ツールはコマンドプロンプトウィンドウが開いて実行されている間のみ使用できます。

  • 変更を加える: サーバーコードに変更を加えた場合は、再起動する前にnpm run buildで再構築する必要があります。

  • 再起動: サーバーを再起動するには、コマンドプロンプトウィンドウを閉じ、カーソル設定でサーバーのオン/オフを切り替えます。

推論ツールの使用

クロードとのカーソル AI 会話で推論ツールを直接使用できます。

MCTS推論

MCTS ベースの推論チェーンを開始するには、 /reason-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トランスフォーマーの推論

シングルステップのトランスフォーマーベースの推論には/reason-r1コマンドを使用します。

/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 : カーソルで使いやすくするためのコマンドラッパー

  • src/utils/errors.ts : エラー処理ユーティリティ

自動反復推論

推論ツールは、1回のツール呼び出しですべての推論ステップを内部的に自動的に完了するように実装されています。各推論手法は以下のプロセスに従います。

  1. 最初の考え/ステップを初期化する

  2. 後続の考えや手順を自動的に生成する

  3. 最終結果とともにすべての考えを返す

このアプローチにより、複数の手動ツール呼び出しを必要とせずに推論プロセスが完全に完了することが保証されます。

新しい推論方法の追加

新しい推論方法を追加するには、次の手順に従います。

  1. src/tools/reasoning-tools.tsに新しいツール実装を追加します。

  2. src/tools/reasoning-wrapper.tsに対応するコマンドラッパーを追加します。

  3. 既存のツールのパターンに従い、パラメータと応答形式を定義します。

  4. 多段階の推論方法の場合は自動反復を実装する

  5. npm run buildでプロジェクトをリビルドします。

制限事項

これはシミュレートされた推論サーバーです。本番環境では、現在使用されているプレースホルダ応答ではなく、実際の推論アルゴリズムに接続します。

ライセンス

ISC

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