Skip to main content
Glama
enesjakozh
AzDeltaQQ

MCP Advanced Reasoning Server

by AzDeltaQQ
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Menciones notables:

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

Gracias por darme la idea Jacck.

Servidor de razonamiento avanzado MCP para Cursor AI

Un servidor de Protocolo de Contexto de Modelo (MCP) que proporciona capacidades de razonamiento avanzadas para Claude en Cursor AI.

Características

  • Búsqueda de árbol de Monte Carlo (MCTS) : utilice el razonamiento MCTS para tareas de resolución de problemas complejos.

  • Beam Search : explora múltiples caminos de razonamiento simultáneamente.

  • Transformador R1 : Aproveche el razonamiento basado en transformadores para problemas complejos.

  • Razonamiento híbrido : combine el análisis de transformadores con MCTS para un razonamiento mejorado.

  • Razonamiento autoiterativo : todos los métodos de razonamiento de varios pasos completan automáticamente todos los pasos de razonamiento en una sola llamada de herramienta.

Related MCP server: MCP Think

Instalación

npm install
npm run build

Uso

Configuración con Cursor AI

  1. Primero construya el servidor:

    cd mcp-reasoning-server
npm run build

  2. Cursor abierto AI

  3. Vaya a Configuración > Funciones > MCP

  4. Haga clic en el botón "+ Agregar nuevo servidor MCP global"

  5. Introduzca los siguientes datos:

    • En el campo de comando: node C:\\Users\\[YourUsername]\\path\\to\\mcp-reasoning-server\\dist\\index.js

    • Asegúrese de utilizar la ruta completa al archivo dist/index.js de su proyecto

    • Utilice barras invertidas dobles para las rutas de Windows

  6. Haga clic en "Agregar"

  7. Encuentre su servidor en la lista (inicialmente se mostrará como "Deshabilitado")

  8. Haga clic en "Deshabilitado" para cambiarlo a "Habilitado".

  9. Haga clic en el botón Actualizar para cargar las herramientas disponibles

  10. Se abrirá automáticamente una ventana del símbolo del sistema: este es su servidor ejecutándose

  11. Mientras esta ventana del símbolo del sistema permanezca abierta, las herramientas de razonamiento estarán disponibles

Como alternativa, puede editar manualmente el archivo de configuración de Cursor MCP en C:\Users\[Username]\.cursor\mcp.json (Windows):

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

Notas importantes

  • Servidor en ejecución : las herramientas solo están disponibles mientras la ventana del símbolo del sistema está abierta y en ejecución

  • Realizar cambios : si realiza cambios en el código del servidor, debe reconstruirlo con npm run build antes de reiniciar

  • Reinicio : para reiniciar el servidor, cierre la ventana del símbolo del sistema y active o desactive el servidor en Configuración del cursor

Usando las herramientas de razonamiento

Puedes utilizar las herramientas de razonamiento directamente en tus conversaciones de Cursor AI con Claude:

Razonamiento MCTS

Utilice el comando /reason-mcts seguido de su consulta para iniciar una cadena de razonamiento basada en MCTS:

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

Razonamiento de búsqueda de haz

Utilice el comando /reason-beam para el razonamiento basado en búsqueda de haces:

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

Razonamiento del transformador R1

Utilice el comando /reason-r1 para el razonamiento basado en Transformer de un solo paso:

/reason-r1 Analyze the complexity of this algorithm.

Razonamiento híbrido

Utilice el comando /reason-hybrid para combinar el razonamiento de Transformer y MCTS:

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

Integración de Claude

Para facilitarle a Claude trabajar con estas herramientas de razonamiento, puede agregar las siguientes instrucciones personalizadas:

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.

Desarrollo

Estructura del proyecto

  • src/index.ts : Punto de entrada del servidor principal

  • src/tools/reasoning-tools.ts : Implementación de herramientas de razonamiento

  • src/tools/reasoning-wrapper.ts : Envoltorios de comandos para un uso más sencillo en Cursor

  • src/utils/errors.ts : Utilidades de manejo de errores

Razonamiento autoiterativo

Las herramientas de razonamiento se implementan para completar automáticamente todos los pasos de razonamiento internamente durante una sola llamada. Cada método de razonamiento sigue este proceso:

  1. Inicializar el primer pensamiento/paso

  2. Generar automáticamente pensamientos/pasos subsiguientes

  3. Devuelve todos los pensamientos junto con el resultado final.

Este enfoque garantiza que el proceso de razonamiento se complete por completo sin necesidad de múltiples llamadas manuales a herramientas.

Añadiendo nuevos métodos de razonamiento

Para agregar un nuevo método de razonamiento, siga estos pasos:

  1. Agregue una nueva implementación de herramienta en src/tools/reasoning-tools.ts

  2. Agregue un contenedor de comandos correspondiente en src/tools/reasoning-wrapper.ts

  3. Seguir el patrón de las herramientas existentes, definiendo parámetros y formato de respuesta

  4. Implementar la iteración automática si se trata de un método de razonamiento de varios pasos

  5. Reconstruir el proyecto con npm run build

Limitaciones

Este es un servidor de razonamiento simulado. En una implementación de producción, se conectaría a algoritmos de razonamiento reales en lugar de a las respuestas de marcador de posición utilizadas actualmente.

Licencia

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