クロード・シャノンの体系的な問題解決手法を示す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.
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.
