The Shannon Thinking MCP Server is a problem-solving tool that provides a structured approach to tackling complex problems inspired by Claude Shannon's methodology.
It allows you to:
Structure thinking into stages: problem definition, constraints, mathematical modeling, validation, and implementation
Document each step with confidence levels (0-1), dependencies, and assumptions
Track how thoughts build upon previous ones
Revise earlier steps and request rechecks when new information emerges
Validate solutions through both formal proofs and experimental testing
Receive rich feedback with formatted console output
Ideal for complex systems analysis, information processing, engineering design, optimization problems, and challenges requiring both theoretical frameworks and practical implementation.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Shannon Thinking MCP Server help me design a recommendation algorithm for our e-commerce platform"
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.
An MCP server demonstrating Claude Shannon's systematic problem-solving methodology. This server provides a tool that helps break down complex problems into structured thoughts following Shannon's approach of problem definition, mathematical modeling, and practical implementation.
Claude Shannon, known as the father of information theory, approached complex problems through a systematic methodology:
Problem Definition: Strip the problem to its fundamental elements
Constraints: Identify system limitations and boundaries
Model: Develop mathematical/theoretical frameworks
Proof/Validation: Validate through formal proofs or experimental testing
Implementation/Experiment: Design and test practical solutions
This MCP server demonstrates this methodology as a tool that helps guide systematic problem-solving through these stages.
Related MCP server: Sequential Thinking MCP Server
{
"mcpServers": {
"shannon-thinking": {
"command": "npx",
"args": [
"-y",
"server-shannon-thinking@latest"
]
}
}
}The server provides a single tool named shannonthinking that structures problem-solving thoughts according to Shannon's methodology.
Each thought must include:
The actual thought content
Type (problem_definition/constraints/model/proof/implementation)
Thought number and total thoughts estimate
Confidence level (uncertainty: 0-1)
Dependencies on previous thoughts
Explicit assumptions
Whether another thought step is needed
Additional capabilities:
Revision: Thoughts can revise earlier steps as understanding evolves
Recheck: Mark steps that need re-examination with new information
Experimental Validation: Support for empirical testing alongside formal proofs
Implementation Notes: Practical constraints and proposed solutions
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);Iterative Problem-Solving: Supports revisions and rechecks as understanding evolves
Flexible Validation: Combines formal proofs with experimental validation
Dependency Tracking: Explicitly tracks how thoughts build upon previous ones
Assumption Management: Requires clear documentation of assumptions
Confidence Levels: Quantifies uncertainty in each step
Rich Feedback: Formatted console output with color-coding, symbols, and validation results
# Install dependencies
npm install
# Build
npm run build
# Run tests
npm test
# Watch mode during development
npm run watchThe tool accepts thoughts with the following structure:
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;
};
}This thinking pattern is particularly valuable for:
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
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
33 tools that make AI write, implement, and verify intent against explicit, testable constraints.
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.
Discover software problems, analyze evidence, and create implementation-ready Build plans.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/olaservo/shannon-thinking'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
