Perplexity AIのAPIを活用したインテリジェントなコード分析とデバッグ機能を提供するModel Context Protocol（MCP）サーバー。Claudeデスクトップクライアントとシームレスに連携します。
インテリジェントなエラー分析: 根本原因分析によるコーディングエラーの詳細な内訳
パターン検出: 一般的なエラーパターンを自動的に認識し、ターゲットを絞った解決策を提供します。
包括的なソリューション: 複数の実装オプションを備えた段階的な修正
ベストプラクティス: コーディング標準とエラー防止のヒントが含まれています
Python サポート: Python の型エラーと一般的なコーディングの問題を専門的に処理します
Related MCP server: Perplexity MCP Server
次のような質問をします。
「Pythonコード内のこのTypeErrorを修正してください」
「このエラーメッセージの原因は何ですか？」
「このコードを修正するにはどうすればいいですか？」
対象を絞った分析のためにコード スニペットを含めます。
def calculate_total(items):
total = 0
for item in items:
total = total + item['price'] # TypeError: string + int
data = [
{'name': 'Book', 'price': '10'},
{'name': 'Pen', 'price': '2'}
]
result = calculate_total(data)サーバーは以下を提供します:
エラーの根本原因分析
コード例付きのステップバイステップのソリューション
同様の問題を防ぐためのベストプラクティス
代替的な実装アプローチ
Node.js 18以上
Perplexity AI APIキー
# Using npm
npm install -g perplexity-mcp
# Or using the repository directly
npm install -g git+https://github.com/yourusername/perplexity-mcp.gitリポジトリをクローンします。
git clone https://github.com/yourusername/perplexity-server.git
cd perplexity-server依存関係をインストールします:
npm installグローバルにビルドしてインストールします。
npm run build
npm install -g .Claude デスクトップ構成ファイルに以下を追加します:
MacOS : ~/Library/Application Support/Claude/claude_desktop_config.json Windows : %APPDATA%/Claude/claude_desktop_config.json
{
"mcpServers": {
"perplexity": {
"command": "perplexity-mcp",
"args": [],
"env": {
"PERPLEXITY_API_KEY": "your-api-key-here"
}
}
}
}またはソースからインストールした場合:
{
"mcpServers": {
"perplexity": {
"command": "node",
"args": ["/absolute/path/to/perplexity-server/build/index.js"],
"env": {
"PERPLEXITY_API_KEY": "your-api-key-here"
}
}
}
}APIキーはClaudeのデスクトップ構成ファイルに安全に保存されます
キーは環境変数としてサーバーに渡されます
リポジトリには機密データは保存されません
サーバーは、Claude の環境から API キーが提供されることを期待しています。
perplexity-server/
├── src/
│ └── index.ts # Main server implementation
├── package.json # Project configuration
└── tsconfig.json # TypeScript configurationnpm run build : プロジェクトをビルドする
npm run watch : 変更を監視し、自動的に再構築する
npm run prepare : 公開用のパッケージを準備する
npm run inspector : デバッグ用に MCP インスペクタを実行する
リポジトリをフォークする
機能ブランチを作成します（ git checkout -b feature/amazing-feature ）
変更をコミットします ( git commit -m 'Add some amazing feature' )
ブランチにプッシュする ( git push origin feature/amazing-feature )
プルリクエストを開く
このプロジェクトは MIT ライセンスに基づいてライセンスされています - 詳細についてはLICENSEファイルを参照してください。
強力なAPIを提供してくれたPerplexity AIに感謝します
Search Perplexity for coding help
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The error or coding question to analyze | |
| code | No | Code snippet to analyze (optional) | |
| language | No | Programming language of the code snippet (optional) | auto |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full responsibility. It merely states the tool's purpose without disclosing behavioral traits like external dependencies, rate limits, or result format.
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 a single concise sentence that efficiently conveys the tool's purpose with no unnecessary words.
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 a simple schema, the description fails to explain output format or side effects. For a search tool, this is incomplete; agents need to know what the results look like.
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 description coverage is 100%, so the baseline is 3. The tool description adds no additional meaning beyond the schema, which is minimally adequate.
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 'Search Perplexity for coding help' clearly states the verb (search), resource (Perplexity), and domain (coding help). With no sibling tools, differentiation is not required.
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, nor any exclusions or context. The description only implies it is for coding help but does not elaborate.
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.
v0.1.0searchScored across 1 tool
Only one tool exists, so there is no risk of confusion between tools.
With a single tool named 'search', the naming is consistent and follows a verb_noun pattern.
A single tool is borderline for a server named 'Perplexity MCP Server', as it may imply broader capabilities, but it is reasonable for a focused search helper.
The tool covers the primary search function, but lacks additional features like filtering or retrieving different result types, leaving minor gaps.
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
Persistent memory for Claude Code and Cursor. Stop re-explaining your project every session.
The bug mediator for AI-built apps: plain-English diagnosis + a ready fix, in your editor.
Connect Claude to Fathom meeting recordings, transcripts, and summaries
