一个演示克劳德·香农系统性问题解决方法的 MCP 服务器。该服务器提供了一个工具，可以帮助将复杂问题分解为结构化思路，遵循香农的问题定义、数学建模和实际实施方法。
克劳德·香农被誉为信息论之父，他通过系统的方法来处理复杂问题：
问题定义：将问题分解成基本要素
约束：识别系统限制和边界
模型：开发数学/理论框架
证明/验证：通过正式证明或实验测试进行验证
实施/实验：设计和测试实用解决方案
该 MCP 服务器演示了这种方法，作为一种工具，可帮助指导通过这些阶段进行系统性问题解决。
Related MCP server: Sequential Thinking MCP Server
{
"mcpServers": {
"shannon-thinking": {
"command": "npx",
"args": [
"-y",
"server-shannon-thinking@latest"
]
}
}
}该服务器提供了一个名为shannonthinking的单一工具，该工具根据香农的方法论来构建解决问题的思路。
每个想法必须包括：
实际的思想内容
类型（问题定义/约束/模型/证明/实施）
想法数量和想法总数估计
置信水平（不确定性：0-1）
依赖于先前的想法
明确的假设
是否需要进一步思考
附加功能：
修订：随着理解的深入，思想可以修改先前的步骤
重新检查：用新信息标记需要重新检查的步骤
实验验证：支持实证检验和正式证明
实施说明：实际限制和建议的解决方案
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);迭代解决问题：随着理解的深入，支持修订和重新检查
灵活验证：将形式证明与实验验证相结合
依赖关系跟踪：明确跟踪想法如何建立在先前想法之上
假设管理：需要清晰的假设文件
置信水平：量化每一步的不确定性
丰富的反馈：带有颜色编码、符号和验证结果的格式化控制台输出
# Install dependencies
npm install
# Build
npm run build
# Run tests
npm test
# Watch mode during development
npm run watch该工具接受具有以下结构的想法：
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;
};
}这种思维模式对于以下情况尤其有价值：
复杂系统分析
信息处理问题
工程设计挑战
需要理论框架的问题
优化问题
需要实际实施的系统
需要迭代改进的问题
实验验证补充理论的情况
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. Dates show when Glama detected each change.
shannonthinkingWith 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.
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.
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
