MCP Troubleshooter
MCP トラブルシューター [進行中]
⚠️重要:このパッケージは現在開発中であり、まだ本番環境での使用には適していません。現在のバージョンは開発中であり、不完全な機能や互換性に影響する変更が含まれている可能性があります。
MCP 関連の問題を診断して修正できるようにする AI モデルの自己診断フレームワーク。
建築
flowchart TB
Client["AI Model\n(e.g., Claude)"]
subgraph "MCP Troubleshooter Server"
LogTools["Log Management"]
ConnTools["Connection Testing"]
ConfigTools["Configuration Analysis"]
FixTools["Fix Implementation"]
subgraph "Log Analysis Engine"
LogReader["Log Reader"]
LogParser["Pattern Recognition"]
ErrorClassifier["Issue Classification"]
end
subgraph "Connection Diagnostics"
ConnTester["Transport Testing"]
PortScanner["Port Availability"]
HandshakeTester["Protocol Validation"]
end
subgraph "Configuration Manager"
ConfigReader["Config Parser"]
ConfigValidator["Schema Validation"]
TemplateLibrary["Template Repository"]
end
end
FileSystem["Host File System\n(Logs & Configs)"]
OtherMCPs["Target MCP Servers"]
Client <--> LogTools
Client <--> ConnTools
Client <--> ConfigTools
Client <--> FixTools
LogTools --> LogAnalysisEngine
ConnTools --> ConnectionDiagnostics
ConfigTools --> ConfigurationManager
LogReader --> FileSystem
ConfigReader --> FileSystem
ConnTester --> OtherMCPs
FixTools --> FileSystem
FixTools --> OtherMCPs
style Client fill:#f9f,stroke:#333,stroke-width:2px
style FileSystem fill:#bbf,stroke:#333,stroke-width:2px
style OtherMCPs fill:#bbf,stroke:#333,stroke-width:2px
style "MCP Troubleshooter Server" fill:#eff,stroke:#333,stroke-width:4pxRelated MCP server: OpenShift SRE Copilot
概要
MCP トラブルシューターは、トラブルシューティングを開発者のみのタスクから AI 自体が活用できる機能へと変換する特殊な MCP サーバーであり、AI モデルで次のことが可能になります。
MCPログを分析- 一般的なエラーパターンを自動的にスキャンし、洞察力のある診断を提供します
構成の検証- サーバーの構成をベストプラクティスと照らし合わせてチェックし、問題を特定します
テスト接続- ネットワーク接続とサーバーの可用性を確認します
テンプレートを生成- 迅速なセットアップのために実用的な MCP サーバー構成を作成します
一般的な問題を修正- 構成を更新し、ソリューションを直接実装する
インストール
# Install the package globally
npm install -g @devlimelabs/mcp-troubleshooter
# Start the server
mcp-troubleshooter使用法
Claudeデスクトップの設定
Claude Desktop の構成にこれを追加します:
{
"mcpServers": {
"troubleshooter": {
"command": "mcp-troubleshooter"
}
}
}ツール
ログ管理ツール
read-mcp-logs : MCP ログファイルを取得して表示します
analyze-mcp-logs : パターン認識を使用して一般的なエラーシグネチャを識別します
設定ツール
read-mcp-config : Claude Desktop の MCP 構成を抽出して検証します。
update-mcp-config : 適切なバックアップメカニズムを使用して構成を安全に更新します
validate-mcp-server-config : サーバー構成の詳細な検証を実行します
接続テストツール
test-port-availability : MCP サーバーに必要なポートが使用可能かどうかを確認します。
check-mcp-server-process : MCP サーバープロセスが正しく実行されているかどうかを確認します。
実装ツールの修正
generate-mcp-server-template : さまざまな言語用にカスタマイズされたサーバーテンプレートを作成します。
generate-claude-desktop-config : Claude Desktop 用に最適化された設定ファイルを構築します。
リソース
common-mcp-issues : 一般的な MCP の問題とその解決策に関する包括的なガイド
mcp-config-templates : さまざまな MCP サーバー設定用の構成テンプレート
使用例
壊れたMCPサーバーの診断
User: My MCP server isn't connecting properly to Claude Desktop. Can you help diagnose it?
Claude: I'll help diagnose your MCP server connection issue. First, let me run some diagnostics.
[Uses check-mcp-server-process tool with the command from the user]
I've identified several possible issues with your MCP server:
1. **Connection Timeout**: The server isn't responding within the expected timeframe.
2. **JSON-RPC Format Error**: There seems to be a format issue in the JSON-RPC responses.
3. **Transport Mismatch**: Claude Desktop is expecting stdio transport, but your server might be using SSE.
Let me run a more specific connection test to confirm:
[Uses test-port-availability tool]
The connection test confirms that your server is starting, but it's timing out during the handshake phase. This is likely due to incorrect JSON-RPC message formatting in your server implementation.
Recommended fixes:
1. Ensure your server returns properly formatted JSON-RPC 2.0 responses
2. Check your transport implementation, it should be using proper stdio pipes
3. Verify that your server is correctly handling the initialize method
Would you like me to analyze a specific log file or check your server's code for these issues?MCP構成の検証
User: Can you validate my Claude Desktop MCP configuration?
Claude: I'd be happy to validate your Claude Desktop MCP configuration.
[Uses read-mcp-config tool]
I've analyzed your Claude Desktop configuration file. Here are my findings:
✅ **Valid Configuration Structure**: The overall structure of your configuration is valid.
⚠️ **Path Issues**: 2 servers have invalid paths:
- "code-llm": The file path "/usr/local/bin/code-llm" doesn't exist
- "database-tool": The command "db-tool" is not in the PATH
❌ **Environment Variables**: 1 server has missing required environment variables:
- "firebase-mcp": Missing required FIREBASE_API_KEY
✅ **Transport Configuration**: All servers properly specify transport options
Recommended fixes:
1. Update the path for "code-llm" to the correct location
2. Install "db-tool" or correct its path
3. Add the missing FIREBASE_API_KEY to the "firebase-mcp" server configuration
Would you like me to help you implement any of these fixes?プラットフォームサポート
Windows :
%APPDATA%\Claude\内のログと構成にアクセスします。macOS :
~/Library/Logs/Claude/のログと~/Library/Application Support/Claude/の設定にアクセスします。Linux :
~/.local/share/Claude/logs/のログと~/.config/Claude/の設定にアクセスします。
発達
# Clone the repository
git clone https://github.com/devlimelabs/master-mcps.git
cd master-mcps
# Install dependencies
pnpm install
# Build the package
pnpm -F @devlimelabs/mcp-troubleshooter build
# Run tests
pnpm -F @devlimelabs/mcp-troubleshooter testライセンス
マサチューセッツ工科大学
Available Tools
9 toolsanalyze-mcp-logsD
| Name | Required | Description | Default |
|---|---|---|---|
| serverName | No | Specific server name to analyze logs for |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check-mcp-server-processD
| Name | Required | Description | Default |
|---|---|---|---|
| serverName | Yes | Name of the MCP server to check |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate-claude-desktop-configD
| Name | Required | Description | Default |
|---|---|---|---|
| serverConfigs | Yes | Array of server configurations |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate-mcp-server-templateD
| Name | Required | Description | Default |
|---|---|---|---|
| features | Yes | Features to include in the template | |
| serverName | Yes | Name for the MCP server | |
| serverType | Yes | Type of server to generate |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read-mcp-configD
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read-mcp-logsD
| Name | Required | Description | Default |
|---|---|---|---|
| lines | No | Number of lines to read from the end | |
| serverName | No | Specific server name to filter logs for |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
test-port-availabilityD
| Name | Required | Description | Default |
|---|---|---|---|
| port | Yes | Port number to test |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update-mcp-configD
| Name | Required | Description | Default |
|---|---|---|---|
| config | Yes | JSON configuration to write (entire file content) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate-mcp-server-configD
| Name | Required | Description | Default |
|---|---|---|---|
| serverName | No | Specific server configuration to validate |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
9 tool updates
v1.0.0- First observed
analyze-mcp-logs - First observed
check-mcp-server-process - First observed
generate-claude-desktop-config - First observed
generate-mcp-server-template - First observed
read-mcp-config - First observed
read-mcp-logs - First observed
test-port-availability - First observed
update-mcp-config - First observed
validate-mcp-server-config
TDQS
Most tools have distinct purposes targeting different aspects of MCP troubleshooting (logs, config, server process, ports, templates). However, 'analyze-mcp-logs' and 'read-mcp-logs' could potentially overlap in function if both involve log inspection, creating some ambiguity about their specific differences.
All tool names follow a consistent verb-noun pattern with hyphen-separated lowercase words (e.g., 'analyze-mcp-logs', 'check-mcp-server-process'). The naming convention is uniform throughout the set, making it predictable and easy to parse.
With 9 tools, this server is well-scoped for MCP troubleshooting. The count is appropriate as it covers key areas like configuration, logs, server status, and testing without being overwhelming or too sparse for the domain.
The tool set provides good coverage for MCP troubleshooting, including reading/analyzing logs, managing configs, checking server processes, and testing ports. A minor gap might be the lack of tools for fixing or repairing issues (e.g., 'restart-mcp-server' or 'fix-mcp-config'), but core diagnostic and setup functions are well-represented.
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
MCP-native AI SRE: ask what's broken in production, get a reviewed GitHub fix PR.
Workflow diagnostics, capability routing, and x402 settlement for MCP-compatible agents.
- mttrlyOAuthcom.mttrly
AI-powered incident management and server monitoring via MCP.
Compliance frameworks (SOC 2, ISO 27001, CMMC, NIST, more) delivered to AI agents as MCP tools.
Related MCP Servers
- AlicenseAqualityCmaintenanceEnables AI agents to programmatically inspect, test, and validate other MCP servers by exposing MCP Workbench capabilities as structured tools. It supports automated test spec generation, execution, and detailed failure analysis to ensure server reliability.419Apache 2.0
- FlicenseAqualityDmaintenanceAI-powered MCP server for enterprise OpenShift/Kubernetes cluster management, providing diagnostic tools, RAG knowledge retrieval, and autonomous remediation recommendations.9-
- AlicenseNot gradedqualityDmaintenanceA comprehensive MCP server that provides system troubleshooting and diagnostic tools, enabling LLMs to diagnose system issues, monitor resources, check logs, and test connectivity.1MIT
- AlicenseBqualityBmaintenanceSelf-healing test automation MCP server that diagnoses and fixes issues in mobile and web apps, including a one-command vibe-check to prioritize broken functionality.2395MIT
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/devlimelabs/mcp-troubleshooter-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server