정의된 단계를 통해 체계적이고 점진적인 사고를 가능하게 하는 모델 컨텍스트 프로토콜(MCP) 서버입니다. 이 도구는 복잡한 문제를 순차적인 사고로 나누고, 사고 과정의 진행 상황을 추적하며, 요약을 생성하는 데 도움을 줍니다.
구조화된 사고 프레임워크 : 표준적인 인지 단계(문제 정의, 조사, 분석, 종합, 결론)를 통해 사고를 구성합니다.
생각 추적 : 메타데이터를 사용하여 순차적인 생각을 기록하고 관리합니다.
관련 사고 분석 : 유사한 사고 간의 연결을 식별합니다.
진행 상황 모니터링 : 전반적인 사고 순서에서 위치를 추적합니다.
요약 생성 : 전체 사고 과정에 대한 간결한 개요를 생성합니다.
영구 저장소 : 스레드 안전성을 통해 사고 세션을 자동으로 저장합니다.
데이터 가져오기/내보내기 : 사고 세션 공유 및 재사용
확장 가능한 아키텍처 : 기능을 쉽게 사용자 지정하고 확장할 수 있습니다.
강력한 오류 처리 : 예외 상황 및 손상된 데이터의 우아한 처리
유형 안전성 : 포괄적인 유형 주석 및 유효성 검사
Related MCP server: Sequential Thinking MCP Server
Python 3.10 이상
UV 패키지 관리자( 설치 가이드 )
Pydantic : 데이터 검증 및 직렬화를 위해
Portalocker : 스레드 안전 파일 액세스를 위해
FastMCP : 모델 컨텍스트 프로토콜 통합을 위해
Rich : 향상된 콘솔 출력을 위해
PyYAML : 구성 관리용
지엑스피1
프로젝트 설정
# Create and activate virtual environment
uv venv
.venv\Scripts\activate # Windows
source .venv/bin/activate # Unix
# Install package and dependencies
uv pip install -e .
# For development with testing tools
uv pip install -e ".[dev]"
# For all optional dependencies
uv pip install -e ".[all]"서버 실행
# Run directly
uv run -m mcp_sequential_thinking.server
# Or use the installed script
mcp-sequential-thinking테스트 실행
# Run all tests
pytest
# Run with coverage report
pytest --cov=mcp_sequential_thinkingClaude Desktop 구성에 추가하세요(Windows의 경우 %APPDATA%\Claude\claude_desktop_config.json ):
{
"mcpServers": {
"sequential-thinking": {
"command": "uv",
"args": [
"--directory",
"C:\\path\\to\\your\\mcp-sequential-thinking\\run_server.py",
"run",
"server.py"
]
}
}
}또는 pip install -e . 사용하여 패키지를 설치한 경우 다음을 사용할 수 있습니다.
{
"mcpServers": {
"sequential-thinking": {
"command": "mcp-sequential-thinking"
}
}
}서버는 생각의 이력을 유지하고 체계적인 워크플로를 통해 처리합니다. 각 생각은 Pydantic 모델을 사용하여 검증되고, 사고 단계로 분류되며, 관련 메타데이터와 함께 스레드 안전 저장 시스템에 저장됩니다. 서버는 데이터 지속성, 백업 생성을 자동으로 처리하고, 생각 간의 관계를 분석하는 도구를 제공합니다.
Sequential Thinking 서버는 세 가지 주요 도구를 제공합니다.
process_thought순차적 사고 과정에서 새로운 생각을 기록하고 분석합니다.
매개변수:
thought (문자열): 생각의 내용
thought_number (정수): 시퀀스의 위치(예: 첫 번째 생각의 경우 1)
total_thoughts (정수): 시퀀스에서 예상되는 총 생각 수
next_thought_needed (부울): 이 생각 이후에 더 많은 생각이 필요한지 여부
stage (문자열): 사고 단계 - 다음 중 하나여야 합니다.
"문제 정의"
"연구"
"분석"
"합성"
"결론"
tags (문자열 목록, 선택 사항): 생각에 대한 키워드 또는 카테고리
axioms_used (문자열 목록, 선택 사항): 생각에 적용되는 원리 또는 공리
assumptions_challenged (문자열 목록, 선택 사항): 가정, 생각, 질문 또는 과제
예:
# First thought in a 5-thought sequence
process_thought(
thought="The problem of climate change requires analysis of multiple factors including emissions, policy, and technology adoption.",
thought_number=1,
total_thoughts=5,
next_thought_needed=True,
stage="Problem Definition",
tags=["climate", "global policy", "systems thinking"],
axioms_used=["Complex problems require multifaceted solutions"],
assumptions_challenged=["Technology alone can solve climate change"]
)generate_summary전체 사고 과정을 요약하여 보여줍니다.
출력 예:
{
"summary": {
"totalThoughts": 5,
"stages": {
"Problem Definition": 1,
"Research": 1,
"Analysis": 1,
"Synthesis": 1,
"Conclusion": 1
},
"timeline": [
{"number": 1, "stage": "Problem Definition"},
{"number": 2, "stage": "Research"},
{"number": 3, "stage": "Analysis"},
{"number": 4, "stage": "Synthesis"},
{"number": 5, "stage": "Conclusion"}
]
}
}clear_history기록된 생각을 모두 지워 사고 과정을 재설정합니다.
의사결정 : 중요한 결정을 체계적으로 처리합니다.
문제 해결 : 복잡한 문제를 관리 가능한 구성 요소로 분해
연구 계획 : 명확한 단계로 연구 접근 방식을 구성하세요
글쓰기 구성 : 글쓰기 전에 점진적으로 아이디어를 개발하세요
프로젝트 분석 : 정의된 분석 단계를 통해 프로젝트를 평가합니다.
MCP를 제대로 설정했다면, process_thought 도구를 사용하여 생각을 순서대로 정리하기 시작하면 됩니다. 진행하면서 generate_summary 사용하여 개요를 확인하고, 필요할 때 clear_history 사용하여 초기화할 수 있습니다.
Sequential Thinking 서버를 사용자 지정하고 확장하는 방법에 대한 자세한 예시는 example.md 를 참조하세요. 여기에는 다음 코드 샘플이 포함되어 있습니다.
사고 단계 수정
Pydantic을 사용하여 사고 데이터 구조 강화
데이터베이스를 사용하여 지속성 추가
NLP를 활용한 향상된 분석 구현
사용자 정의 프롬프트 만들기
고급 구성 설정
웹 UI 통합 구축
시각화 도구 구현
외부 서비스에 연결
협업 환경 만들기
테스트 코드 분리
재사용 가능한 유틸리티 구축
MIT 라이센스
Clear the thought history.
Returns:
dict: Status message
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose all behavioral traits. It only states the action and return type, omitting details like destructiveness, scope, or confirmation requirements.
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 concise at two sentences, front-loading the key action. While it lacks depth, it contains no superfluous information.
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?
Despite the tool's simplicity, the description is incomplete. It does not mention that clearing history is irreversible or provide any behavioral context, especially given the lack of annotations and output schema.
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?
The input schema has zero parameters, so the baseline is 4. The description does not need to add parameter information since none exist.
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 explicitly states 'Clear the thought history,' which matches the tool name 'clear_history.' The verb 'clear' and resource 'thought history' are clear and distinct from sibling tools like export_session or process_thought.
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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, side effects, or context for clearing history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export the current thinking session to a file.
Args:
file_path: Path to save the exported session
Returns:
dict: Status message
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose side effects, file overwrite behavior, or access permissions; merely states the action and returns 'Status message' without detail.
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?
Two sentences plus structured Args/Returns sections, clear and front-loaded; no unnecessary text.
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?
Adequate for a simple tool with one parameter and no output schema, but lacks information on file format, overwrite behavior, or status message contents.
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 0%, but the description adds 'Path to save the exported session' for file_path, clarifying its purpose beyond the schema's type definition.
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 uses a specific verb ('Export') and resource ('current thinking session') with destination ('to a file'), clearly distinguishing from siblings like import_session or generate_summary.
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?
No guidance on when to use this tool versus alternatives; lacks context on prerequisites or situations like saving vs sharing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a summary of the entire thinking process.
Returns:
dict: Summary of the thinking process
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose behavioral traits (e.g., whether it is a read-only operation, requires state, or has side effects). It only states it returns a dict, which is insufficient.
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 extremely concise with two short sentences, no unnecessary words, and the key information is front-loaded.
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 no output schema and sibling tools, the description lacks details about what the summary contains, how it is generated, or any dependencies. It feels incomplete for a tool that produces a significant output.
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?
There are no parameters, so schema coverage is trivially 100%. The description adds meaning by specifying the output is a summary of the thinking process, which is helpful beyond an empty schema.
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 states the action ('Generate') and the resource ('summary of the entire thinking process'). It is a specific verb+resource combination that distinguishes it from sibling tools like 'clear_history', 'export_session', etc.
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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Import a thinking session from a file.
Args:
file_path: Path to the file to import
Returns:
dict: Status message
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It only states 'Import a thinking session from a file' without mentioning side effects (e.g., overwriting current session), file requirements, or error behavior.
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 brief (three lines) and uses a standard Args/Returns structure. However, it is too terse to be fully effective, lacking essential details.
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 absence of an output schema, the description only vaguely states 'dict: Status message'. It does not explain what the status indicates or what happens to the existing session, leaving the agent uninformed.
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?
The input schema has 0% description coverage, so the description must compensate. It merely repeats 'Path to the file to import', adding no detail about file format, size limits, or path constraints.
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 states the action (import) and the object (thinking session from a file). It is distinguishable from sibling tools like export_session, but lacks specifics on file format or source.
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?
No guidance on when to use this tool versus alternatives, no context on prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a sequential thought with its metadata.
Args:
thought: The content of the thought
thought_number: The sequence number of this thought
total_thoughts: The total expected thoughts in the sequence
next_thought_needed: Whether more thoughts are needed after this one
stage: The thinking stage (Problem Definition, Research, Analysis, Synthesis, Conclusion)
tags: Optional keywords or categories for the thought
axioms_used: Optional list of principles or axioms used in this thought
assumptions_challenged: Optional list of assumptions challenged by this thought
is_revision: Whether this thought revises an earlier thought
revises_thought_number: The number of the earlier thought being revised (required if is_revision is true)
branch_from_thought: The thought number this thought branches from, to explore an alternative path
branch_id: Identifier for the branch (letters, digits, '-', '_'; max 64 chars; requires branch_from_thought)
ctx: Optional MCP context object
Returns:
dict: Analysis of the processed thought
| Name | Required | Description | Default |
|---|---|---|---|
| ctx | No | ||
| tags | No | ||
| stage | Yes | ||
| thought | Yes | ||
| branch_id | No | ||
| axioms_used | No | ||
| is_revision | No | ||
| thought_number | Yes | ||
| total_thoughts | Yes | ||
| branch_from_thought | No | ||
| next_thought_needed | Yes | ||
| assumptions_challenged | No | ||
| revises_thought_number | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose all behavioral traits. It details what the tool does but omits side effects, permission requirements, error handling, or the state modifications (e.g., appending to a thought list). The return value is only vaguely described as 'dict: Analysis of the processed thought.'
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 front-loaded with a one-line summary, then structured as a docstring with Args and Returns. It is reasonably concise, though the parameter list is lengthy. Every sentence adds value, but could be more compact.
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 (13 parameters, no output schema, no annotations), the description explains each parameter but lacks guidance on the overall workflow (e.g., sequential numbering, when to set 'next_thought_needed'). The stage values are enumerated, but the return value and error conditions are unspecified.
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?
The input schema has no property descriptions (0% coverage), so the description must compensate. The Args list provides brief explanations for each parameter, but these mostly restate the parameter names (e.g., 'thought: The content of the thought') without adding deeper semantics, constraints, or examples.
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 opens with 'Add a sequential thought with its metadata,' which clearly states the action and resource. This distinguishes it from sibling tools (clear_history, export_session, generate_summary, import_session) which serve different purposes.
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 does not explicitly state when to use this tool versus alternatives. The usage is implied by the tool name and sibling context, but no exclusion criteria or when-not scenarios are provided.
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.
v1.0.1clear_historyexport_sessiongenerate_summaryimport_sessionprocess_thoughtScored across 5 tools
Each tool has a distinct purpose: clearing history, exporting/importing sessions, generating summaries, and processing thoughts. No functional overlap.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., clear_history, export_session). The naming is predictable and clear.
Five tools is appropriate for a focused sequential thinking server, covering core operations without unnecessary bloat.
The tool surface covers the full lifecycle: adding thoughts (with revision and branching), clearing, exporting/importing, and generating summaries. Minor gap: lack of a dedicated edit/delete tool, but revisions handle edits.
Official DevSpeak MCP server — translate technical text into formal specs from any AI IDE or agent
An MCP server for deep research or task groups
Official MCP server for Agentwork — delegate tasks to AI agents with human-in-the-loop
MCP server for generating rough-draft project plans from natural-language prompts.
