debug-thinking
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@debug-thinkingDefine a problem: App crashes on login due to undefined token"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
🧠 Debug Thinking MCP
Debug Thinking MCP について
デバッグ時の思考フレームワークと、そこで得た知見をローカルディレクトリに保存 → 活用までを提供する MCP サーバーです。
Debug Thinking MCP は、デバッグプロセスを永続的な知識グラフとして構造化し、を再利用可能な資産に変えます。
📚 クイックスタートガイド - 実際のデバッグシナリオで使い方を学ぶ
Related MCP server: Debug MCP
🚀 主要機能
🌳 問題解決ツリー
複雑な問題を管理可能なサブ問題に分解し、各問題を独立して解決
🔬 H-E-Lサイクル
仮説を立て、実験で検証し、観察から学習を抽出する科学的手法
🧠 知識グラフ
すべてのデバッグセッションが検索可能な知識として蓄積
🔍 類似問題検索
過去の類似問題と解決策を高速検索し、デバッグパスを提供
📦 クイックスタート
1. インストール
npm install -g mcp-server-debug-thinking2. MCP Server 設定
{
"mcpServers": {
"debug-thinking": {
"command": "npx",
"args": ["mcp-server-debug-thinking"]
}
}
}🎯 使用方法
基本的なデバッグフロー
graph LR
A[問題発生] --> B[問題を定義]
B --> C[仮説を立てる]
C --> D[実験を設計]
D --> E[結果を観察]
E --> F{問題解決?}
F -->|Yes| G[学習を抽出]
F -->|No| C
G --> H[知識として保存]実際の使用例
1️⃣ 問題の定義
await use_tool("debug_thinking", {
action: "create",
nodeType: "problem",
content: "Next.jsアプリが'TypeError: Cannot read property of undefined'でクラッシュ",
metadata: {
tags: ["nextjs", "runtime-error", "production"],
},
});2️⃣ 仮説の作成
await use_tool("debug_thinking", {
action: "create",
nodeType: "hypothesis",
content: "SSRでのデータフェッチ時にundefinedチェックが不足している可能性",
parentId: "problem-123",
metadata: {
confidence: 85,
},
});3️⃣ 実験と観察
// 実験を実行
await use_tool("debug_thinking", {
action: "create",
nodeType: "experiment",
content: "getServerSidePropsでオプショナルチェーンを追加",
parentId: "hypothesis-456",
});
// 結果を記録
await use_tool("debug_thinking", {
action: "create",
nodeType: "observation",
content: "エラーが解消し、ページが正常にレンダリングされる",
parentId: "experiment-789",
});4️⃣ 知識の活用
// 類似問題を検索
await use_tool("debug_thinking", {
action: "query",
type: "similar-problems",
parameters: {
pattern: "TypeError undefined Next.js SSR",
limit: 5,
},
});📊 グラフ構造
デバッグ知識グラフの仕組み
Debug Thinkingは、すべてのデバッグプロセスを有向グラフとして記録します。各ノードは特定の意味を持ち、エッジ(矢印)がノード間の関係を表現します。
ノードタイプと役割
ノードタイプ | 役割 | 例 |
🔴 Problem | 解決すべき問題・エラー |
|
🔵 Hypothesis | 問題の原因についての仮説 |
|
🟡 Experiment | 仮説を検証する実験 |
|
🟢 Observation | 実験結果の観察 |
|
⚪ Learning | 得られた知見・教訓 |
|
🟣 Solution | 検証済みの解決策 |
|
関係性(エッジ)の種類
問題の分解
graph TD
P1[🔴 問題] -->|decomposes| P2[🔴 サブ問題]大きな問題を小さく分割
仮説検証サイクル
graph TD
P3[🔴 問題] -->|hypothesizes| H[🔵 仮説]
H -->|tests| E[🟡 実験]
E -->|produces| O[🟢 観察]仮説→実験→観察の流れ
知識の蓄積
graph TD
O2[🟢 観察] -->|learns| L[⚪ 学習]
L -->|solves| P4[🔴 問題]観察から学習し解決へ
実際のデバッグ例:「ボタンクリックが効かない」
graph TD
P["🔴 問題<br/>ボタンが反応しない"]
P -->|hypothesizes| H1["🔵 仮説1<br/>イベントリスナーが<br/>登録されていない"]
P -->|hypothesizes| H2["🔵 仮説2<br/>別の要素が<br/>ボタンを覆っている"]
H1 -->|tests| E1["🟡 実験1<br/>console.logで<br/>クリック確認"]
E1 -->|produces| O1["🟢 観察1<br/>ログが出力<br/>されない"]
H2 -->|tests| E2["🟡 実験2<br/>DevToolsで<br/>要素を調査"]
E2 -->|produces| O2["🟢 観察2<br/>透明なdivが<br/>上に存在"]
O1 -->|supports| H1
O2 -->|supports| H2
O2 -->|learns| L1["⚪ 学習<br/>z-indexの確認は<br/>デバッグの基本"]
L1 -->|solves| S["🟣 解決策<br/>z-indexを修正"]
S -->|solves| P
style P fill:#ff6b6b,stroke:#333,stroke-width:3px
style H1 fill:#4ecdc4,stroke:#333,stroke-width:2px
style H2 fill:#4ecdc4,stroke:#333,stroke-width:2px
style E1 fill:#f39c12,stroke:#333,stroke-width:2px
style E2 fill:#f39c12,stroke:#333,stroke-width:2px
style O1 fill:#2ecc71,stroke:#333,stroke-width:2px
style O2 fill:#2ecc71,stroke:#333,stroke-width:2px
style L1 fill:#ecf0f1,stroke:#333,stroke-width:2px
style S fill:#9b59b6,stroke:#333,stroke-width:2pxこの例では、よくある「ボタンがクリックできない」問題を通じて、Debug Thinkingがどのように動作するかを示しています:
問題を定義: ボタンが反応しないという明確な問題
複数の仮説: イベントリスナーの問題とレイアウトの問題
実験で検証: console.logとDevToolsを使った検証
観察から学習: z-indexの重要性を学習
解決策の適用: 具体的な修正方法
🔍 クエリ機能
類似問題の検索と解決策の取得
過去の類似問題とその解決策を検索し、デバッグパスも含めて取得します。
const result = await use_tool("debug_thinking", {
action: "query",
type: "similar-problems",
parameters: {
pattern: "TypeError undefined Next.js SSR",
limit: 5,
minSimilarity: 0.3,
},
});
// レスポンス例:
{
"problems": [{
"nodeId": "prob-123",
"content": "TypeError: Cannot read property 'name' of undefined in getServerSideProps",
"similarity": 0.85,
"status": "solved",
"solutions": [{
"nodeId": "sol-456",
"content": "Add optional chaining to handle undefined data",
"verified": true,
"debugPath": [
{ "nodeId": "prob-123", "type": "problem", "content": "..." },
{ "nodeId": "hyp-234", "type": "hypothesis", "content": "..." },
{ "nodeId": "exp-345", "type": "experiment", "content": "..." },
{ "nodeId": "obs-456", "type": "observation", "content": "..." },
{ "nodeId": "sol-456", "type": "solution", "content": "..." }
]
}]
}]
}最近の活動を確認
直近のデバッグノードを時系列で取得し、セッションの継続性を保ちます。
const recentActivity = await use_tool("debug_thinking", {
action: "query",
type: "recent-activity",
parameters: {
limit: 10, // 取得件数(デフォルト: 10)
},
});
// レスポンス例:
{
"nodes": [{
"nodeId": "node-789",
"type": "solution",
"content": "Fixed by adding null check",
"createdAt": "2024-01-20T10:30:00Z",
"parent": {
"nodeId": "node-678",
"type": "observation",
"content": "Variable is undefined on first render"
},
"edges": [
{ "type": "solves", "targetNodeId": "prob-123", "direction": "from" }
]
}],
"totalNodes": 156
}🏗️ アーキテクチャ
mcp-server-debug-thinking/
├── src/
│ ├── index.ts # MCPサーバーエントリーポイント
│ ├── services/
│ │ ├── GraphService.ts # グラフ操作のコアロジック
│ │ └── GraphStorage.ts # 永続化レイヤー
│ ├── types/
│ │ ├── graph.ts # グラフデータ型定義
│ │ └── graphActions.ts # アクション型定義
│ └── utils/
│ └── logger.ts # ロギングユーティリティ
└── .debug-thinking-mcp/ # データストレージ
├── nodes.jsonl # ノードデータ
├── edges.jsonl # エッジデータ
└── graph-metadata.json # メタデータ🛠️ 開発者向け
ローカル開発
# リポジトリをクローン
git clone https://github.com/tosssssy/mcp-server-debug-thinking.git
cd mcp-server-debug-thinking
# 依存関係をインストール
npm install
# 開発モードで実行
npm run dev
# テストを実行
npm test
# プロダクションビルド
npm run build📄 ライセンス
このプロジェクトはMITライセンスの下で公開されています。詳細はLICENSEをご覧ください。
Available Tools
1 tooldebug_thinkingA
Graph-based debugging knowledge management system. Helps track debugging process systematically and retrieve past solutions.
Use this tool when:
User reports an error or bug that needs systematic investigation
You need to document your debugging approach for complex issues
You want to check if similar problems were solved before
Building a knowledge base of debugging patterns
Actions:
CREATE - Add nodes to the debugging graph
nodeType: problem|hypothesis|experiment|observation|learning|solution
content: Description of the node
parentId: Optional parent node for automatic edge creation
metadata: Optional tags, confidence scores, etc.
CONNECT - Link nodes with relationships
from/to: Node IDs to connect
type: decomposes|hypothesizes|tests|produces|learns|contradicts|supports|solves
strength: 0-1 relationship strength
QUERY - Search and analyze the graph
queryType: similar-problems|recent-activity
parameters: pattern (search text), limit, minSimilarity
Example workflow:
CREATE problem "TypeError: Cannot read property 'x' of undefined"
CREATE hypothesis "Missing null check in async operation"
CREATE experiment "Add optional chaining operator"
CREATE observation "Error resolved"
QUERY similar-problems with pattern "TypeError undefined"
Data persists in ~/.debug-thinking-mcp/
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform | |
| nodeType | No | Type of node to create (for create action) | |
| content | No | Content of the node (for create action) | |
| parentId | No | Parent node ID for automatic relationship creation (for create action) | |
| metadata | No | Additional metadata for the node (for create action) | |
| from | No | Source node ID (for connect action) | |
| to | No | Target node ID (for connect action) | |
| type | No | Type of relationship (for connect action) | |
| strength | No | Strength of the relationship (for connect action) | |
| queryType | No | Type of query to perform (for query action) | |
| parameters | No | Query parameters (for query action) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully discloses behavior: it maintains a graph, persists data to ~/.debug-thinking-mcp/, and describes the effects of each action (create, connect, query). No contradictions.
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-organized: purpose sentence, usage guidelines, bullet-pointed actions, example workflow, and persistence note. Front-loaded and every section adds value without redundancy.
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 (11 params, nested objects, no output schema, no siblings), the description explains the graph concept, all actions, when to use, and provides a complete example. No gaps for effective use.
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 baseline is 3. The description groups parameters by action and provides an example workflow, adding context beyond the schema. However, it does not delve deeper into each parameter's semantics beyond what the schema provides.
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 it is a 'Graph-based debugging knowledge management system' that helps track debugging systematically and retrieve past solutions. It lists specific actions (CREATE, CONNECT, QUERY) with details, making the purpose unambiguous. No siblings exist to differentiate from.
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?
Explicitly provides 'Use this tool when:' conditions: error reporting, need to document approach, check past solutions, build knowledge base. Also includes an example workflow demonstrating how to use the actions in sequence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
Only one tool exists, so there is no ambiguity between tools. The tool's multiple actions are clearly separated within it.
The single tool name 'debug_thinking' is consistent and descriptive. No naming inconsistencies exist.
One tool is appropriate for this domain as it encapsulates all necessary operations (create, connect, query) in a cohesive interface for debugging knowledge management.
The tool covers core actions like creating nodes, connecting them, and querying. Missing explicit update/delete operations for nodes, but the graph-based approach may rely on recreation.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Shared debugging memory for AI coding agents
Give your AI agent a persistent map of your project's structure, dependencies, and bugs.
AI Agent with Architectural Memory. Impact analysis (free), tests and code from the graph (pro).
Ground-truth code graph for your codebase: exact callers, callees, symbols & dependencies.
Related MCP Servers
- -licenseNot gradedqualityNot gradedmaintenanceAn active, stateful software knowledge graph engine that serves as an 'all-knowing development partner' for AI agents and human developers by modeling software projects into queryable knowledge graphs.
- AlicenseAqualityDmaintenanceAn intelligent debugging assistant that automates the debugging process by analyzing bugs, injecting HTTP-based debug logs into code across multiple environments (browser, Node.js, mobile, etc.), and iteratively fixing issues based on real-time feedback.8MIT
- AlicenseBqualityAmaintenanceTemporal knowledge graph for codebases that captures decision traces, links test failures to code changes, learns co-edit patterns, predicts regression risk, and enforces learned constraints at the edit boundary via a PreToolUse hook.3122MIT
- AlicenseAqualityDmaintenanceEnables creating and querying semantic knowledge graphs to model business logic, code relationships, and project structure across multiple projects.111MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/tosssssy/mcp-server-debug-thinking'
If you have feedback or need assistance with the MCP directory API, please join our Discord server