Un servidor MCP que demuestra la metodología sistemática de resolución de problemas de Claude Shannon. Este servidor proporciona una herramienta que ayuda a descomponer problemas complejos en ideas estructuradas siguiendo el enfoque de Shannon: definición de problemas, modelado matemático e implementación práctica.
Claude Shannon, conocido como el padre de la teoría de la información, abordó problemas complejos a través de una metodología sistemática:
Definición del problema : despojar al problema de sus elementos fundamentales
Restricciones : Identificar las limitaciones y límites del sistema
Modelo : Desarrollar marcos matemáticos/teóricos
Prueba/Validación : Validar mediante pruebas formales o pruebas experimentales.
Implementación/Experimentación : Diseño y prueba de soluciones prácticas.
Este servidor MCP demuestra esta metodología como una herramienta que ayuda a guiar la resolución sistemática de problemas a través de estas etapas.
Related MCP server: Sequential Thinking MCP Server
{
"mcpServers": {
"shannon-thinking": {
"command": "npx",
"args": [
"-y",
"server-shannon-thinking@latest"
]
}
}
}El servidor proporciona una única herramienta llamada shannonthinking que estructura los pensamientos de resolución de problemas según la metodología de Shannon.
Cada pensamiento debe incluir:
El contenido real del pensamiento
Tipo (definición del problema/restricciones/modelo/prueba/implementación)
Estimación del número de pensamientos y del total de pensamientos
Nivel de confianza (incertidumbre: 0-1)
Dependencias de pensamientos previos
Supuestos explícitos
Si es necesario otro paso de reflexión
Capacidades adicionales:
Revisión : Los pensamientos pueden revisar los pasos anteriores a medida que evoluciona la comprensión.
Revisar : marcar los pasos que necesitan volver a examinarse con nueva información
Validación experimental : Apoyo a las pruebas empíricas junto con las pruebas formales
Notas de implementación : Restricciones prácticas y soluciones propuestas
const thought = {
thought: "The core problem can be defined as an information flow optimization",
thoughtType: "problem_definition",
thoughtNumber: 1,
totalThoughts: 5,
uncertainty: 0.2,
dependencies: [],
assumptions: ["System has finite capacity", "Information flow is continuous"],
nextThoughtNeeded: true,
// Optional: Mark as revision of earlier definition
isRevision: false,
// Optional: Indicate step needs recheck
recheckStep: {
stepToRecheck: "constraints",
reason: "New capacity limitations discovered",
newInformation: "System shows non-linear scaling"
}
};
// Use with MCP client
const result = await client.callTool("shannonthinking", thought);Resolución iterativa de problemas : admite revisiones y verificaciones a medida que evoluciona la comprensión.
Validación flexible : combina pruebas formales con validación experimental
Seguimiento de dependencias : rastrea explícitamente cómo los pensamientos se basan en los anteriores.
Gestión de suposiciones : requiere una documentación clara de las suposiciones
Niveles de confianza : cuantifica la incertidumbre en cada paso
Comentarios enriquecidos : salida de consola formateada con codificación de colores, símbolos y resultados de validación
# Install dependencies
npm install
# Build
npm run build
# Run tests
npm test
# Watch mode during development
npm run watchLa herramienta acepta pensamientos con la siguiente estructura:
interface ShannonThought {
thought: string;
thoughtType: "problem_definition" | "constraints" | "model" | "proof" | "implementation";
thoughtNumber: number;
totalThoughts: number;
uncertainty: number; // 0-1
dependencies: number[];
assumptions: string[];
nextThoughtNeeded: boolean;
// Optional revision fields
isRevision?: boolean;
revisesThought?: number;
// Optional recheck field
recheckStep?: {
stepToRecheck: ThoughtType;
reason: string;
newInformation?: string;
};
// Optional validation fields
proofElements?: {
hypothesis: string;
validation: string;
};
experimentalElements?: {
testDescription: string;
results: string;
confidence: number; // 0-1
limitations: string[];
};
// Optional implementation fields
implementationNotes?: {
practicalConstraints: string[];
proposedSolution: string;
};
}Este patrón de pensamiento es particularmente valioso para:
Análisis de sistemas complejos
Problemas de procesamiento de información
Desafíos del diseño de ingeniería
Problemas que requieren marcos teóricos
Problemas de optimización
Sistemas que requieren implementación práctica
Problemas que necesitan refinamiento iterativo
Casos en los que la validación experimental complementa la teoría
A problem-solving tool inspired by Claude Shannon's systematic and iterative approach to complex problems.
This tool helps break down problems using Shannon's methodology of problem definition, mathematical modeling, validation, and practical implementation.
When to use this tool:
Complex system analysis
Information processing problems
Engineering design challenges
Problems requiring theoretical frameworks
Optimization problems
Systems requiring practical implementation
Problems that need iterative refinement
Cases where experimental validation complements theory
Key features:
Systematic progression through problem definition → constraints → modeling → validation → implementation
Support for revising earlier steps as understanding evolves
Ability to mark steps for re-examination with new information
Experimental validation alongside formal proofs
Explicit tracking of assumptions and dependencies
Confidence levels for each step
Rich feedback and validation results
Parameters explained:
thoughtType: Type of thinking step (PROBLEM_DEFINITION, CONSTRAINTS, MODEL, PROOF, IMPLEMENTATION)
uncertainty: Confidence level in the current thought (0-1)
dependencies: Which previous thoughts this builds upon
assumptions: Explicit listing of assumptions made
isRevision: Whether this revises an earlier thought
revisesThought: Which thought is being revised
recheckStep: For marking steps that need re-examination
proofElements: For formal validation steps
experimentalElements: For empirical validation
implementationNotes: For practical application steps
The tool supports an iterative approach:
Define the problem's fundamental elements (revisable as understanding grows)
Identify system constraints and limitations (can be rechecked with new information)
Develop mathematical/theoretical models
Validate through proofs and/or experimental testing
Design and test practical implementations
Each thought can build on, revise, or re-examine previous steps, creating a flexible yet rigorous problem-solving framework.
| Name | Required | Description | Default |
|---|---|---|---|
| thought | Yes | Your current thinking step | |
| isRevision | No | Whether this thought revises an earlier one | |
| assumptions | Yes | Explicit list of assumptions | |
| recheckStep | No | For marking steps that need re-examination | |
| thoughtType | Yes | Type of thinking step | |
| uncertainty | Yes | Confidence level (0-1) | |
| dependencies | Yes | Thought numbers this builds upon | |
| proofElements | No | Elements required for formal proof steps | |
| thoughtNumber | Yes | Current thought number | |
| totalThoughts | Yes | Estimated total thoughts needed | |
| revisesThought | No | The thought number being revised | |
| nextThoughtNeeded | Yes | Whether another thought step is needed | |
| implementationNotes | No | Notes for practical implementation steps | |
| experimentalElements | No | Elements for experimental validation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior. It thoroughly explains the iterative nature, support for revisions, re-examination, and tracking of assumptions and confidence levels. It leaves little ambiguity about how the tool operates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections but is somewhat verbose, especially the 'Key features' and iterative process parts which are partially redundant with the 'Parameters explained' and usage guidelines. It could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 parameters, nested objects) and no output schema, the description is reasonably complete. It explains the methodology, parameter purposes, and iterative workflow. However, it does not specify what the tool returns or how errors are handled.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description's 'Parameters explained' section reiterates schema descriptions, adding some context (e.g., 'Which previous thoughts this builds upon') but does not provide significant new meaning beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool as a problem-solving tool inspired by Claude Shannon's systematic approach. It explicitly states the verb (break down problems) and resource (Shannon's methodology), and lists specific use cases, making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an extensive list of when to use the tool, covering complex systems, engineering, optimization, etc. It also outlines the iterative process and key features. However, it does not explicitly state when not to use the tool or suggest alternatives, but given no siblings, this is acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
shannonthinkingScored across 1 tool
With only one tool, there is no risk of confusion between tools. The tool's purpose is clearly described and stands alone.
A single tool name 'shannonthinking' is trivially consistent. No naming conflicts or inconsistencies exist.
One tool for a complex problem-solving methodology is minimal. The tool is monolithic, handling all thought types via parameters, which reduces modularity and discoverability.
The tool covers all key stages of problem-solving (definition, constraints, modeling, proof, implementation, iteration) and includes validation and revision features. However, packing everything into one tool limits granularity and specialized access.
33 tools that make AI write, implement, and verify intent against explicit, testable constraints.
Breaks a hard question or decision into checkable sub-questions, grounds each to a real tool.
Deterministic reasoning stack for AI agents: simulate, decide & compute, plus cross-domain tools.
Turns vague automation requests into tool stacks, prompts, QA checks, and human boundaries.
