클로드 섀넌의 체계적인 문제 해결 방법론을 보여주는 MCP 서버입니다. 이 서버는 섀넌의 문제 정의, 수학적 모델링, 그리고 실제 구현 방식에 따라 복잡한 문제를 구조화된 사고로 분해하는 데 도움이 되는 도구를 제공합니다.
정보 이론의 아버지로 알려진 클로드 섀넌은 체계적인 방법론을 통해 복잡한 문제에 접근했습니다.
문제 정의 : 문제의 근본 요소만 추출
제약 조건 : 시스템 제한 사항 및 경계 식별
모델 : 수학적/이론적 프레임워크 개발
증명/검증 : 공식적인 증명이나 실험적 테스트를 통해 검증합니다.
구현/실험 : 실용적인 솔루션 설계 및 테스트
이 MCP 서버는 이러한 단계를 통해 체계적인 문제 해결을 안내하는 도구로서 이 방법론을 보여줍니다.
Related MCP server: Sequential Thinking MCP Server
지엑스피1
이 서버는 섀넌의 방법론에 따라 문제 해결에 대한 사고를 구조화하는 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.
