Perplexity Sonar APIを基盤とした、構造化された競合/市場インテリジェンスのモニタリングワークフロー用のMCPサーバー。
訂正(2026-08-26): このREADMEの以前のバージョンでは、ネイティブなPerplexity MCPコネクタはどこにも存在しないと主張していました。それは誤りでした — Perplexityは公式のMCPサーバーを公開しています(github.com/perplexityai/modelcontextprotocol)。これには、Perplexityがホストするリモートエンドポイントhttps://api.perplexity.ai/mcpも含まれており、セルフホスティングなしでクラウドスケジュールされたセッションから到達できます。ただ汎用的なアドホックのSonar検索が必要なだけなら、ここで何かを構築・実行する代わりに、そちらを登録してください。
公式サーバーが提供しないのは、構造化され、比較可能な週次モニタリング出力です。公式サーバーが公開しているのは汎用の検索/推論(Agent API、Search API)であり、固定セクションの企業ニュース要約やJSONスキーマで制約されたシグナルスイープではありません。それがこのサーバーが存在する実際の理由です — 2つのワークフローツールからなる薄く狭いレイヤーであり、Perplexity自身のMCPサーバーの代替品ではありません。
このサーバーを一度デプロイし(下記の「リモートデプロイメント」を参照)、PERPLEXITY_API_KEYをプラットフォームのシークレットとして設定すれば、あらゆるMCPクライアント — クラウドスケジュールされたCowork/Claudeセッションを含む — が、ローカルマシンやデバイスブリッジに一切触れることなく、HTTP経由で呼び出せます。Perplexityの公式サーバーと併用して登録してください。その代わりに登録するのではありません。
perplexity_company_news — 構造化された企業ニュース要約(ガバナンス、経営陣、戦略的イベント、財務状況、人事異動)、固定セクション見出し、フリーテキストの日付範囲の代わりにlookback_daysを使用します。
perplexity_market_signals — サーバーサイドのJSONスキーマに制約された、セクター全体のシグナルスイープ(M&A、資金調達、任命、再編)。そのため、結果は再パースが必要なマークダウンではなく、個別のシグナルの実際の配列になります。期間内に日付があり信頼できるものが見つからない場合は、エラーではなく空配列を返します — これは失敗ではなく、意味のある結果です。
両ツールは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デプロイメントを使用してください。
同じコードをTRANSPORT=httpで、Node対応の任意のホスト(小規模なVPS、Render、Railway、Fly.io、任意のクラウドプロバイダーのコンテナ)上で実行します。唯一の要件は、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スキーマ、説明、注釈とともに両ツールを返します。
無効なAPIキーを使ったtools/callは、クリーンで、対処可能なisError: trueの結果(Perplexityダッシュボードを指し示す401ガイダンス)を返します — サーバーはクラッシュせず、その後も応答し続けます。
ビルド環境では実際のPERPLEXITY_API_KEYを利用できなかったため、実際のSonar呼び出しの成功 — 実際の回答内容、実際の引用、market_signalsのJSONスキーマ制約付きレスポンスが実際に有効なJSONとしてパースされること — はエンドツーエンドで確認されていません。本番のモニタリングルーチンでこれに依存する前に、実際のキーを使って2つのツールをそれぞれ一度実行し(この確認にはローカルのstdioで十分です)、出力が上記で説明した形状と一致することを確認してください。
perplexity_company_newsとperplexity_market_signalsはどちらも、デフォルトでsonar-proモデルを使用します(sonarよりも深い検索、より多くの情報源、呼び出しごとのコストが高い)。これは、モニタリングのユースケースがレイテンシー/コストよりも完全性と引用品質を優先するためです — このサーバーの両ツールにおける意図的なデフォルトであり、2026-08-26に確認済みです。1回限りのクエリでより安価なモデルを選択するためのperplexity_searchツールはここにはありません。その場合は、Perplexity公式のMCPサーバーを使用してください(このファイル冒頭の訂正を参照)。数十社にわたる週次ルーチンの規模でこれを実行する前に、Perplexityの現在のモデル別料金を確認してください — フル実行では、およそ50〜90社に加えて1回のマーケットシグナルスイープを処理するため、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.
