此存储库不再维护。
该工具的功能现已在mcp-omnisearch中提供，它将多个 MCP 工具组合在一个统一的包中。
请改用mcp-omnisearch 。
一个模型上下文协议 (MCP) 服务器，用于将 Perplexity 的 AI API 与 LLM 集成。该服务器提供高级聊天补全功能，并针对各种用例提供专用的提示模板。
Related MCP server: DocGen MCP Server
🤖 使用 Perplexity 的 AI 模型完成高级聊天
📝 常见场景的预定义提示模板：
技术文档生成
安全最佳实践分析
代码审查和改进
结构化格式的 API 文档
🎯 针对特殊用例的自定义模板支持
📊 多种输出格式（文本、markdown、JSON）
🔍 响应中可选包含源 URL
⚙️ 可配置模型参数（温度、最大代币数量）
🚀 支持包括 Sonar 和 LLaMA 在内的各种 Perplexity 模型
此服务器需要通过您的 MCP 客户端进行配置。以下是不同环境的示例：
将其添加到您的 Cline MCP 设置中：
{
"mcpServers": {
"mcp-perplexity-search": {
"command": "npx",
"args": ["-y", "mcp-perplexity-search"],
"env": {
"PERPLEXITY_API_KEY": "your-perplexity-api-key"
}
}
}
}对于 WSL 环境，将其添加到您的 Claude Desktop 配置中：
{
"mcpServers": {
"mcp-perplexity-search": {
"command": "wsl.exe",
"args": [
"bash",
"-c",
"source ~/.nvm/nvm.sh && PERPLEXITY_API_KEY=your-perplexity-api-key /home/username/.nvm/versions/node/v20.12.1/bin/npx mcp-perplexity-search"
]
}
}
}服务器需要以下环境变量：
PERPLEXITY_API_KEY ：您的 Perplexity API 密钥（必需）
服务器实现了具有可配置参数的单个 MCP 工具：
使用 Perplexity API 生成聊天完成，并支持专门的提示模板。
参数：
messages （数组，必需）：消息对象数组，包含以下内容：
role （字符串）：“系统”、“用户”或“助理”
content （字符串）：消息内容
prompt_template （字符串，可选）：要使用的预定义模板：
technical_docs ：包含代码示例的技术文档
security_practices ：安全实施指南
code_review ：代码分析和改进
api_docs ：JSON 格式的 API 文档
custom_template （对象，可选）：自定义提示模板，包括：
system （字符串）：助手行为的系统消息
format （字符串）：输出格式偏好
include_sources （布尔值）：是否包含源
format （字符串，可选）：“text”、“markdown”或“json”（默认值：“text”）
include_sources （布尔值，可选）：包含源 URL（默认值：false）
model （字符串，可选）：要使用的困惑度模型（默认值：'sonar'）
temperature （数字，可选）：输出随机性（0-1，默认值：0.7）
max_tokens （数字，可选）：最大响应长度（默认值：1024）
克隆存储库
安装依赖项：
pnpm install构建项目：
pnpm build以开发模式运行：
pnpm dev该项目使用变更集进行版本管理。要发布：
创建变更集：
pnpm changeset对包进行版本控制：
pnpm changeset version发布到 npm：
pnpm release欢迎贡献代码！欢迎提交 Pull 请求。
MIT 许可证 - 有关详细信息，请参阅LICENSE文件。
基于模型上下文协议
由Perplexity SONAR提供支持
Generate chat completions using the Perplexity API
| Name | Required | Description | Default |
|---|---|---|---|
| messages | Yes | ||
| prompt_template | No | Predefined prompt template to use for common use cases. Available templates: - technical_docs: Technical documentation with code examples and source references - security_practices: Security best practices and implementation guidelines with references - code_review: Code analysis focusing on best practices and improvements - api_docs: API documentation in structured JSON format with examples | |
| custom_template | No | Custom prompt template. If provided, overrides prompt_template. | |
| format | No | Response format. Use json for structured data, markdown for formatted text with code blocks. Overrides template format if provided. | text |
| include_sources | No | Include source URLs in the response. Overrides template setting if provided. | |
| model | No | Model to use for completion. Note: llama-3.1 models will be deprecated after 2/22/2025 | sonar |
| temperature | No | Controls randomness in the output. Higher values (e.g. 0.8) make the output more random, while lower values (e.g. 0.2) make it more focused and deterministic. | |
| max_tokens | No | The maximum number of tokens to generate in the response. One token is roughly 4 characters for English text. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but only states the basic function. It doesn't mention rate limits, authentication requirements, cost implications, error handling, or response characteristics. For a complex API tool with 8 parameters, this is inadequate.
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, efficient sentence with zero wasted words. It's appropriately sized and gets straight to the point without unnecessary elaboration.
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?
For a complex chat completion tool with 8 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what a 'chat completion' entails, typical use cases, or what the response looks like. The agent must rely entirely on the schema for operational details.
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?
With 88% schema description coverage, the schema already documents most parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema, so it meets the baseline for high coverage but doesn't provide additional semantic context.
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 chat completions') and target ('using the Perplexity API'), providing a specific verb+resource combination. However, with no sibling tools mentioned, it cannot demonstrate differentiation from alternatives, which prevents a perfect score.
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 provides no guidance on when to use this tool versus alternatives, prerequisites, or typical use cases. It simply states what the tool does without context about appropriate scenarios or limitations.
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.0chat_completionScored across 1 tool
With only one tool, there is no possibility of ambiguity or overlap between tools. The single tool's purpose is clearly defined as generating chat completions using the Perplexity API, leaving no room for misselection.
Since there is only one tool, naming consistency is inherently perfect. The tool name 'chat_completion' follows a clear verb_noun pattern, and there are no other tools to compare or create inconsistencies with.
A single tool is generally too few for a server's purpose, as it limits functionality and may indicate an incomplete or overly narrow scope. While it could be appropriate for a very simple service, it often feels thin and lacks the breadth needed for typical agent workflows.
The tool provides a core function for chat completions, but with only one tool, the surface is notably incomplete. There are obvious gaps, such as missing operations for managing conversations, handling different models, or supporting related search functionalities, which could hinder agent performance in broader tasks.
Provide your AI coding tools with token-efficient access to up-to-date technical documentation for…
@latest documentation and code examples to 9000+ libraries for LLMs and AI code editors in a singl…
Discover, compare, and monitor 1,400+ APIs directly from your AI coding agent.
Versioned documentation registry and semantic search for AI tools and coding assistants.
