模型上下文协议 (MCP) 服务器，通过定义的阶段促进结构化、渐进式的思考。此工具可帮助您将复杂问题分解为连续的思路，跟踪思考过程的进展并生成摘要。
结构化思维框架：通过标准认知阶段（问题定义、研究、分析、综合、结论）组织思想
思维追踪：使用元数据记录和管理连续的思维
相关思想分析：识别相似思想之间的联系
进度监控：跟踪你在整个思考序列中的位置
摘要生成：创建整个思考过程的简明概述
持久存储：自动保存你的思考过程，确保线程安全
数据导入/导出：共享和重复使用思考会议
可扩展架构：轻松定制和扩展功能
强大的错误处理：优雅地处理边缘情况和损坏的数据
类型安全：全面的类型注释和验证
Related MCP server: Sequential Thinking MCP Server
Python 3.10 或更高版本
UV 包管理器（安装指南）
Pydantic ：用于数据验证和序列化
Portalocker ：用于线程安全的文件访问
FastMCP ：用于模型上下文协议集成
Rich ：用于增强控制台输出
PyYAML ：用于配置管理
mcp-sequential-thinking/
├── mcp_sequential_thinking/
│ ├── server.py # Main server implementation and MCP tools
│ ├── models.py # Data models with Pydantic validation
│ ├── storage.py # Thread-safe persistence layer
│ ├── storage_utils.py # Shared utilities for storage operations
│ ├── analysis.py # Thought analysis and pattern detection
│ ├── testing.py # Test utilities and helper functions
│ ├── utils.py # Common utilities and helper functions
│ ├── logging_conf.py # Centralized logging configuration
│ └── __init__.py # Package initialization
├── tests/
│ ├── test_analysis.py # Tests for analysis functionality
│ ├── test_models.py # Tests for data models
│ ├── test_storage.py # Tests for persistence layer
│ └── __init__.py
├── run_server.py # Server entry point script
├── debug_mcp_connection.py # Utility for debugging connections
├── README.md # Main documentation
├── CHANGELOG.md # Version history and changes
├── example.md # Customization examples
├── LICENSE # MIT License
└── pyproject.toml # Project configuration and dependencies设置项目
# 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_thinking添加到您的 Claude 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 模型进行验证，并按思维阶段进行分类，并将其与相关元数据一起存储在线程安全的存储系统中。服务器自动处理数据持久化、备份创建，并提供用于分析思维之间关系的工具。
顺序思维服务器公开了三个主要工具：
process_thought记录并分析您连续思考过程中的新想法。
参数：
thought （字符串）：你的想法的内容
thought_number （整数）：序列中的位置（例如，1 表示第一个想法）
total_thoughts （整数）：序列中预期的总想法数
next_thought_needed (boolean): 是否需要在此之后进行更多思考
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 实现增强分析
创建自定义提示
设置高级配置
构建 Web 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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/arben-adm/mcp-sequential-thinking'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
