MCP 服务器，用于基于 Perplexity Sonar API 的结构化竞争/市场情报监测工作流。
更正（2026-08-26）： 本 README 的早期版本曾声称任何地方都不存在原生的 Perplexity MCP 连接器。那是错误的——Perplexity 发布了一个官方 MCP 服务器（github.com/perplexityai/modelcontextprotocol），包括一个由 Perplexity 托管的远程端点 https://api.perplexity.ai/mcp，可从云端定时会话访问，且完全无需自托管。如果你只是需要通用的临时 Sonar 搜索，请注册该服务器，而不是在这里构建或运行任何东西。
官方服务器不能提供的是结构化、可比较的每周监测输出：它只暴露通用的搜索/推理（Agent API、Search API），而不是固定版块的公司简报或受 JSON schema 约束的信号扫描。这才是本服务器存在的真正原因——它是一个由两个工作流工具构成的薄而窄的层，而不是 Perplexity 自家 MCP 服务器的替代品。
只需部署一次（见下文“远程部署”），并将 PERPLEXITY_API_KEY 设置为平台密钥，任何 MCP 客户端——包括云端定时 Cowork/Claude 会话——都可以通过 HTTP 调用它，而无需接触本地机器或设备桥接。请将它与 Perplexity 的官方服务器一起注册，而不是替代它。
perplexity_company_news — 结构化公司新闻简报（gouvernance、dirigeants、événements stratégiques、situation financière、mouvements RH），固定版块标题，使用 lookback_days 而不是自由文本日期范围。
perplexity_market_signals — 全行业信号扫描（M&A、融资、人事任命、重组），在服务端受 JSON schema 约束，因此结果是离散信号的真实数组，而不是需要重新解析的 markdown。当在所查期间内找不到任何有日期且可靠的信息时，返回空数组（而不是错误）——这是一个有意义的结果，而不是失败。
这两个工具都支持 response_format: "markdown" | "json"，并返回引用/来源。对于通用搜索，请使用 Perplexity 的官方 MCP 服务器——见上文更正。
Related MCP server: INDUSS Research Intelligence MCP Server
npm install
cp .env.example .env # then set PERPLEXITY_API_KEY
npm run build适合测试，或适合任何已经在你自己的机器上运行的工作流。在你 MCP 客户端的配置中注册它（例如 Claude Desktop 的 claude_desktop_config.json）：
{
"mcpServers": {
"perplexity": {
"command": "node",
"args": ["/absolute/path/to/perplexity-mcp-server/dist/index.js"],
"env": { "PERPLEXITY_API_KEY": "pplx-..." }
}
}
}这仍然将可用性与那台机器是否开启绑定在一起——它不能解决云端定时任务需要密钥这一原始问题。要解决该问题，请使用下面的 HTTP 部署。
在任何支持 Node 的主机（小型 VPS、Render、Railway、Fly.io，或任意云提供商的容器）上，用 TRANSPORT=http 运行同样的代码。唯一的要求是：Node 18+、能够设置环境变量密钥，以及一个公共 HTTPS URL。
PERPLEXITY_API_KEY=pplx-... TRANSPORT=http PORT=3000 npm start该服务器暴露：
POST /mcp — MCP 端点（streamable HTTP、无状态 JSON——每个请求都有全新的服务器+传输，因此调用之间不会泄漏任何数据，并且可以在没有共享状态的情况下水平扩展）
GET /health — 用于你的托管平台健康检查的简单存活探针
一旦部署到 HTTPS 之后（https://your-host/mcp），请将该 URL 注册为工作区中的远程 MCP 连接器，以便依赖于 Perplexity 的定时任务可以直接访问它，而密钥仅存在于服务端——这与 Pappers 已经使用的运营模式相同（原生连接器，凭据路径中没有本地密钥）。
npm run build 可干净地编译（严格 TypeScript，无 any）。
两种传输方式（stdio 和 HTTP）都能启动且不会崩溃。
GET /health 响应正确。
完整的 MCP 握手（initialize、tools/list）返回两个工具，并带有正确的 JSON schema、描述和注解。
使用无效 API 密钥调用 tools/call 会返回清晰、可操作的 isError: true 结果（401 提示指向 Perplexity 仪表盘）——服务器不会崩溃，并且之后仍保持响应。
构建环境中没有可用的真实 PERPLEXITY_API_KEY，因此一次真正成功的 Sonar 调用——真实的回答内容、真实的引用、market_signals 受 JSON schema 约束的响应确实能被解析为有效 JSON——尚未经过端到端验证。在生产环境监测流程中依赖此功能之前，请使用真实密钥各运行一次这两个工具（通过 stdio 在本地运行足以完成此检查），并确认输出与上文记录的形态相符。
perplexity_company_news 和 perplexity_market_signals 都默认使用 sonar-pro 模型（比 sonar 搜索更深、来源更多、单次调用成本更高），因为监测用例优先考虑完整性和引用质量，而非延迟/成本——这是本服务器这两个工具刻意为之的默认设置，已于 2026-08-26 确认。这里没有 perplexity_search 工具可供一次性查询选择更便宜的模型；如需该功能，请使用 Perplexity 的官方 MCP 服务器（见本文件顶部的更正）。在每周例行规模下对数以十计的公司运行之前，请先查看 Perplexity 当前的按模型定价——完整运行会处理大约 50-90 家公司，外加一次市场信号扫描，因此 sonar-pro 与 sonar 之间的边际成本会迅速累积。
Get a structured, cited news brief on one company: governance, executives, strategic events, financial situation, and senior HR moves.
This is a workflow tool built on top of Perplexity's Sonar chat/completions API: it fixes the prompt structure and section headings so every call returns a comparable, five-section brief, and maps a plain lookback_days number to Perplexity's recency buckets (there is no native "3 months" filter, so lookback_days=90 is mapped to the nearest bucket, 'month').
Args:
organization (string): Company name, e.g. "Doctolib".
lookback_days (number, 1-365, default 90): how far back to search ("90" = "last 3 months").
language ('fr'|'en'): default 'fr'.
response_format ('markdown'|'json'): default 'markdown'.
Returns: Markdown: five headed sections (Gouvernance/Governance, Dirigeants/Executives, Événements stratégiques/Strategic events, Situation financière/Financial situation, Mouvements RH/Senior HR moves), each stating "Rien à signaler"/"Nothing to report" if empty, followed by numbered Sources. JSON: { "answer": string (same structured text), "citations": string[], "search_results": [...], "organization": string, "lookback_days": number }
Examples:
Use when: "Quelle est l'actualité récente de Nexans ?" -> organization="Nexans"
Use when: weekly veille loop over a list of target companies -> call once per company
Don't use when: you need sector-wide signals across many companies -> use perplexity_market_signals instead.
Error Handling:
Returns "Error: ... Invalid Perplexity API key" if PERPLEXITY_API_KEY is missing/invalid (401).
Returns "Error: ... rate limit exceeded" if too many requests (429).
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Language of the synthesized answer. | fr |
| organization | Yes | Legal or commercial name of the company to research, e.g. 'Doctolib'. | |
| lookback_days | No | How far back to look for news, in days (default 90 = 'last 3 months'). Mapped internally to Perplexity's nearest recency bucket. | |
| response_format | No | Output format: 'markdown' for human-readable, 'json' for machine-readable. | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and non-destructive; the description adds substantial behavioral context: it explains it wraps Perplexity's API, fixes prompt/section structure, maps lookback_days to recency buckets, emits 'Nothing to report' placeholders, and returns specific errors for bad API keys or rate limits. This goes well beyond the annotations and helps predict actual 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 longer than average, but it is organized into clear, labeled sections (Args, Returns, Examples, Error Handling) with no filler. Every section contributes decision-relevant information, and the main purpose is front-loaded in the first sentence.
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?
The tool is a wraper with no output schema, so the description correctly takes on the burden of documenting return values, error behavior, parameter semantics, and usage boundaries. It covers the full range of invocation contexts and likely failure modes.
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?
Although schema description coverage is 100%, the description adds important meaning beyond the schema: it explains that lookback_days is mapped to Perplexity's nearest recency bucket because no native '3 months' filter exists. It also details what each response_format value produces, including the JSON shape and Markdown sections.
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 a specific verb and resource: 'Get a structured, cited news brief on one company,' then lists the exact content areas covered. It also names the sibling tool in the alternatives, making differentiation explicit.
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 gives explicit 'Use when' and 'Don't use when' guidance, including an example user query mapped to the organization parameter. It clearly directs agents to perplexity_market_signals for sector-wide signals instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find recent, dated market signals (M&A, funding rounds, executive appointments, restructurings, etc.) relevant to a given professional profile and region, as a structured list.
Unlike a free-text Sonar query, this tool constrains Perplexity's response to a JSON schema server-side, so the result is a real array of discrete signals — not markdown you have to re-parse. It returns an empty list rather than fabricated signals when nothing dated and reliable is found; that empty list is itself a meaningful, actionable result (it means the sweep ran and found nothing this period), not a failure.
Args:
profile (string): Target professional profile, e.g. "CTO groupe / VP Technology / Chief Transformation Officer / Group CIO".
regions (string[], default ["France","Europe","Luxembourg"]): geographic scope.
lookback_days (number, 1-30, default 7): how far back to search.
signal_types (string[], default M&A/levée de fonds/nomination/restructuration): categories.
language ('fr'|'en'): default 'fr'.
response_format ('markdown'|'json'): default 'markdown'.
Returns: Markdown: one numbered section per signal (title, type, date, source, summary), or an explicit "no signal found" statement if the array is empty. JSON: { "signals": [{title,type,date,source_url,summary}], "count": number, "lookback_days": number, "regions": string[] }
Examples:
Use when: weekly sector-wide sweep independent of any specific tracked company
Don't use when: you already know the company and want its own news -> use perplexity_company_news instead.
Error Handling:
Returns "Error: ... Invalid Perplexity API key" if PERPLEXITY_API_KEY is missing/invalid (401).
Returns "Error: ... rate limit exceeded" if too many requests (429).
If Perplexity returns non-JSON content despite the schema constraint, returns "Error: could not parse signals JSON" with the raw answer included so nothing is silently lost.
| Name | Required | Description | Default |
|---|---|---|---|
| profile | Yes | The professional profile signals should be relevant to, e.g. 'CTO groupe / VP Technology / Chief Transformation Officer / Group CIO'. | |
| regions | No | Geographic scope for signals. | |
| language | No | Language of the synthesized answer. | fr |
| signal_types | No | Categories of signal to look for. | |
| lookback_days | No | How far back to look for signals, in days (default 7 = 'this week'). | |
| response_format | No | Output format: 'markdown' for human-readable, 'json' for machine-readable. | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHInt and non-destructive, and the description adds meaningful behavior beyond that: it returns an empty list rather than fabricated signals, treating that empty result as a valid sweep outcome. It also discloses exact error behaviors for 401, 429, and per-answer parsing failures while preserving raw content, which is highly transparent.
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-structured with Args, Returns, Examples, and Error Handling sections. The core purpose and sibling differentiation are front-loaded, and each section contributes actionable information without filler.
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?
There is no output schema, so the description correctly takes responsibility for explaining both Markdown and JSON return shapes. It also covers error handling, empty-result semantics, and representative use cases, giving an agent everything needed to invoke and interpret the tool correctly.
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% and each parameter already has a description, so the baseline is 3. The description adds value by specifying the exact Markdown and JSON return structures tied to response_format, and by giving concrete examples for profile, signal_types, and lookback_days. This is a modest but genuine increment over the 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 opens with a specific verb and resource: 'Find recent, dated market signals ... relevant to a given professional profile and region, as a structured list.' It lists concrete signal categories and explicitly contrasts itself with a free-text Sonar query and with the sibling tool perplexity_company_news, so an agent can distinguish it without opening the schema.
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?
It provides explicit 'Use when' and 'Don't use when' guidance: use for 'weekly sector-wide sweep independent of any specific tracked company' and avoid when you want a specific company's news, routing to perplexity_company_news. This leaves no ambiguity about selection versus the sibling.
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.0perplexity_company_newsperplexity_market_signalsScored across 2 tools
The two tools have cleanly separated domains: one compiles a structured news brief for a single named company, while the other scans for market-wide signals across profiles and regions. Their descriptions explicitly cross-reference when not to use each, removing ambiguity.
Both tool names follow the same `perplexity_<object>` snake_case pattern and clearly indicate their target: `company_news` vs `market_signals`. No mixed conventions or vague verbs.
At two tools, the surface is on the thin side and borders on feeling minimal for a server named after Perplexity. Each tool does earn its place and covers a distinct workflow, but the count is at the low end of acceptable.
The pair covers the two main read-oriented intelligence workflows: focused company monitoring and broader market sweeps. A general free-text search or ask tool is missing, but the server's stated purpose appears to be these richer structured workflows, so the gap is minor.
Real-time financial news & regulatory intelligence: cited search, fetch, summaries, collections.
Realtime financial context for AI agents: what changed, who is affected, and what to watch next. One suite covering news, events, guidance, filing changes, sentiment, stakeholders, and alerts. Information-efficient responses with evidence for every result. First-class point-in-time safety for backtests. Pairs well with web search and a market-data API. All data is our own.
Primary-source SEC filing intelligence and financial/disclosure reconciliation for AI agents.
Search and monitor source-backed AI agent ecosystem signals, briefings, deltas, and source health.
