먼저 서버를 빌드하세요.
```
cd mcp-reasoning-server
npm run build
```
오픈 커서 AI
설정 > 기능 > MCP로 이동하세요.
"+ 새로운 글로벌 MCP 서버 추가" 버튼을 클릭하세요.
다음 세부 정보를 입력하세요.
- 명령 필드에서: node C:\\Users\\[YourUsername]\\path\\to\\mcp-reasoning-server\\dist\\index.js
- 프로젝트의 dist/index.js 파일에 대한 전체 경로를 사용해야 합니다.
- Windows 경로에는 이중 백슬래시를 사용하세요
"추가"를 클릭하세요
목록에서 서버를 찾으세요(처음에는 "비활성화됨"으로 표시됩니다)
"비활성화"를 클릭하여 "활성화"로 전환합니다.
새로 고침 버튼을 클릭하여 사용 가능한 도구를 로드하세요.
명령 프롬프트 창이 자동으로 열립니다. 이것은 서버가 실행 중임을 나타냅니다.
이 명령 프롬프트 창이 열려 있는 한 추론 도구를 사용할 수 있습니다.

또는 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 로 다시 빌드해야 합니다.
다시 시작 : 서버를 다시 시작하려면 명령 프롬프트 창을 닫고 커서 설정에서 서버를 켜거나 끕니다.

추론 도구 사용

Claude와의 Cursor 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 변압기 추론

단일 단계 Transformer 기반 추론을 위해 /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 : 오류 처리 유틸리티

자동 반복 추론

추론 도구는 단일 도구 호출 시 모든 추론 단계를 내부적으로 자동으로 완료하도록 구현됩니다. 각 추론 방법은 다음 프로세스를 따릅니다.

첫 번째 생각/단계를 초기화하세요
이후의 생각/단계를 자동으로 생성합니다.
최종 결과와 함께 모든 생각을 반환하세요

이 접근 방식을 사용하면 여러 번의 수동 도구 호출 없이도 추론 프로세스가 완전히 완료됩니다.

새로운 추론 방법 추가

새로운 추론 방법을 추가하려면 다음 단계를 따르세요.

src/tools/reasoning-tools.ts 에 새로운 도구 구현을 추가합니다.
src/tools/reasoning-wrapper.ts 에 해당 명령 래퍼를 추가합니다.
기존 도구의 패턴을 따르고 매개변수와 응답 형식을 정의합니다.
다단계 추론 방법인 경우 자동 반복을 구현합니다.
npm run build 로 프로젝트를 다시 빌드하세요.

제한 사항

이는 시뮬레이션된 추론 서버입니다. 실제 구현에서는 현재 사용되는 플레이스홀더 응답 대신 실제 추론 알고리즘에 연결하게 됩니다.

특허

아이에스씨

Available Tools

8 tools

beam_search_reasoningD

ParametersJSON Schema

Name	Required	Description
`prompt`	Yes	The problem or query to reason about
`thought`	Yes	Current reasoning step
`thoughtNumber`	Yes	Current step number
`totalThoughts`	Yes	Total expected steps
`nextThoughtNeeded`	Yes	Whether another step is needed
`beamWidth`	No	Number 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

Name	Required	Description
`prompt`	Yes	The problem or query to reason about
`thought`	Yes	Current reasoning step
`thoughtNumber`	Yes	Current step number
`totalThoughts`	Yes	Total expected steps
`nextThoughtNeeded`	Yes	Whether another step is needed
`numSimulations`	No	Number 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

Name	Required	Description
`prompt`	Yes	The problem or query to reason about
`thought`	Yes	Current reasoning step
`thoughtNumber`	Yes	Current step number
`totalThoughts`	Yes	Total expected steps
`nextThoughtNeeded`	Yes	Whether another step is needed
`numSimulations`	No	Number 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

Name	Required	Description	Default
`prompt`	Yes	The 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

Name	Required	Description	Default
`query`	Yes	The 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

Name	Required	Description	Default
`query`	Yes	The 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

Name	Required	Description	Default
`query`	Yes	The 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

Name	Required	Description	Default
`query`	Yes	The 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.

8 tool updatesAug 15, 2025
- 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 2026-04-18 11:15 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

GitHub Repository

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
238
mcp COAuth
com.wix
A Model Context Protocol server for Wix AI tools
Developer Tools Content Management Systems App Automation
215
RogerRat A
io.github.opcastil11
Real-time chat hub for AI agents — Claude Code, Cursor, Cline, Codex over MCP or REST.
Communication Agent Orchestration
21
Reasoning Commons
io.github.chenyuan35
AI Reasoning Cache & Consensus Layer with 11 MCP tools via Streamable HTTP.
AI & Machine Learning Knowledge & Memory Autonomous Agents
2

Related MCP Servers

MCP Think Tool Server
Autonomous Agents Code Execution RAG Systems
abhinav-mangla
A
license
A
quality
D
maintenance
A Model Context Protocol server that provides Claude with a dedicated space for structured thinking during complex problem-solving tasks, helping improve its reasoning capabilities.
Updated a year ago (2025-08-12 07:39 UTC)
1
29 npm
16
MIT
MCP Think
Autonomous Agents Developer Tools Knowledge & Memory
ddkang1
A
license
Not graded
quality
D
maintenance
A Model Context Protocol server that provides AI assistants like Claude with a dedicated space for structured thinking during complex problem-solving tasks.
Updated a year ago (2025-06-05 01:17 UTC)
MIT
AI Development Pipeline MCP
Developer Tools Agent Orchestration
theburgerllc
A
license
B
quality
D
maintenance
A Model Context Protocol server that enables seamless integration between Claude AI and development tools like VSCode, Augment, Vercel, Airtable, and Square.
Updated a year ago (2025-06-06 02:06 UTC)
7
MIT
Zen MCP Enhanced
Agent Orchestration Coding Agents Developer Tools
199-mcp
A
license
Not graded
quality
F
maintenance
An enhanced Model Context Protocol server that enables Claude to seamlessly collaborate with multiple AI models (Gemini, OpenAI, local models) for code analysis and development tasks, maintaining context across conversations.
Updated a year ago (2025-06-14 04:22 UTC)
23 npm
54
Apache 2.0

Appeared in Searches

Methods to Enhance Deep Research Capabilities