Which integrations are available for this server?

Supports performance optimization analysis for React components through the advanced reasoning tools

How do I use MCP Advanced Reasoning Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Advanced Reasoning Server reason-mcts How can we optimize this database query for better performance?" 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.

en es ja ko zh

MCP Advanced Reasoning Server

by AzDeltaQQ

Overview Schema Related Servers Score Discussions

TypeScript

Local

Notable Mentions :

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

Thanks for giving me the idea Jacck .

MCP Advanced Reasoning Server for Cursor AI

A Model Context Protocol (MCP) server that provides advanced reasoning capabilities for Claude in Cursor AI.

Features

Monte Carlo Tree Search (MCTS): Use MCTS reasoning for complex problem-solving tasks.
Beam Search: Explore multiple reasoning paths simultaneously.
R1 Transformer: Leverage Transformer-based reasoning for complex problems.
Hybrid Reasoning: Combine Transformer analysis with MCTS for enhanced reasoning.
Auto-Iterative Reasoning: All multi-step reasoning methods automatically complete all reasoning steps in a single tool call.

Related MCP server: MCP Think

Installation

npm install
npm run build

Usage

Configuring with Cursor AI

Build the server first:
```
cd mcp-reasoning-server
npm run build
```
Open Cursor AI
Navigate to Settings > Features > MCP
Click the "+ Add new global MCP server" button
Enter the following details:
- In the command field: node C:\\Users\\[YourUsername]\\path\\to\\mcp-reasoning-server\\dist\\index.js
- Make sure to use the full path to your project's dist/index.js file
- Use double backslashes for Windows paths
Click "Add"
Find your server in the list (it will initially show as "Disabled")
Click "Disabled" to toggle it to "Enabled"
Click the refresh button to load the available tools
A command prompt window will open automatically - this is your server running
As long as this command prompt window remains open, the reasoning tools will be available

Alternatively, you can manually edit your Cursor MCP configuration file at C:\Users\[Username]\.cursor\mcp.json (Windows):

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

Important Notes

Server Running: The tools are only available while the command prompt window is open and running
Making Changes: If you make changes to the server code, you must rebuild it with npm run build before restarting
Restarting: To restart the server, close the command prompt window and toggle the server off/on in Cursor Settings

Using the Reasoning Tools

You can use the reasoning tools directly in your Cursor AI conversations with Claude:

MCTS Reasoning

Use the /reason-mcts command followed by your query to start a MCTS-based reasoning chain:

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

Beam Search Reasoning

Use the /reason-beam command for beam search-based reasoning:

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

R1 Transformer Reasoning

Use the /reason-r1 command for single-step Transformer-based reasoning:

/reason-r1 Analyze the complexity of this algorithm.

Hybrid Reasoning

Use the /reason-hybrid command to combine Transformer and MCTS reasoning:

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

Claude Integration

To make it easier for Claude to work with these reasoning tools, you can add the following custom instructions:

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.

Development

Project Structure

src/index.ts: Main server entry point
src/tools/reasoning-tools.ts: Implementation of reasoning tools
src/tools/reasoning-wrapper.ts: Command wrappers for easier use in Cursor
src/utils/errors.ts: Error handling utilities

Auto-Iterative Reasoning

The reasoning tools are implemented to automatically complete all reasoning steps internally during a single tool call. Each reasoning method follows this process:

Initialize the first thought/step
Automatically generate subsequent thoughts/steps
Return all thoughts along with the final result

This approach ensures that the reasoning process completes fully without requiring multiple manual tool calls.

Adding New Reasoning Methods

To add a new reasoning method, follow these steps:

Add a new tool implementation in src/tools/reasoning-tools.ts
Add a corresponding command wrapper in src/tools/reasoning-wrapper.ts
Follow the pattern of existing tools, defining parameters and response format
Implement auto-iteration if it's a multi-step reasoning method
Rebuild the project with npm run build

Limitations

This is a simulated reasoning server. In a production implementation, you would connect to actual reasoning algorithms instead of the placeholder responses currently used.

License

ISC

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. Dates show when Glama detected each change.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

D1.3/5.0

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

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

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
237
mcp COAuth
com.wix
A Model Context Protocol server for Wix AI tools
Developer Tools Content Management Systems App Automation
216
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
Remote Desktop CommanderOAuth
app.desktopcommander
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Shell Access OS Automation
214

Related MCP Servers

MCP Think Tool Server
Autonomous Agents Code Execution RAG Systems
abhinav-mangla
A
license
A
quality
C
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
41
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)
22
54
Apache 2.0

Appeared in Searches

Methods to Enhance Deep Research Capabilities

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/AzDeltaQQ/Mcp-Reasoning-Server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server