Perplexity Sonar API 기반의 구조화된 경쟁/시장 인텔리전스 모니터링 워크플로우를 위한 MCP 서버입니다.
수정(2026-08-26): 이 README의 이전 버전은 네이티브 Perplexity MCP 커넥터가 어디에도 존재하지 않는다고 주장했습니다. 이는 잘못된 정보입니다 — Perplexity는 공식 MCP 서버(github.com/perplexityai/modelcontextprotocol)를 게시하며, 여기에는 자체 호스팅 없이도 클라우드 스케줄링 세션에서 접근할 수 있는 Perplexity 호스팅 원격 엔드포인트 https://api.perplexity.ai/mcp가 포함됩니다. 일반적인 임시 Sonar 검색만 필요하다면 여기서 아무것도 빌드하거나 실행하지 말고 그 서버를 등록하세요.
공식 서버가 제공하지 않는 것은 구조화되고 비교 가능한 주간 모니터링 출력입니다. 공식 서버는 고정 섹션 회사 브리핑이나 JSON 스키마로 제약된 시그널 스윕이 아니라 일반적인 검색/추론(Agent API, Search API)을 노출합니다. 이것이 이 서버가 존재하는 실제 이유입니다 — 두 개의 워크플로우 도구로 구성된 얇고 좁은 계층일 뿐, Perplexity 자체 MCP 서버를 대체하는 것이 아닙니다.
PERPLEXITY_API_KEY를 플랫폼 시크릿으로 설정하여 이 서버를 한 번 배포하고(아래 "원격 배포" 참조) 나면, 클라우드 스케줄링된 Cowork/Claude 세션을 포함한 모든 MCP 클라이언트가 로컬 머신이나 디바이스 브리지를 거치지 않고 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 — 요청마다 새 server+transport를 생성하므로 호출 간 누출이 없고 공유 상태 없이 수평 확장됨)
GET /health — 호스팅 플랫폼의 헬스 프로브를 위한 단순한 liveness 확인
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으로 파싱되는 것 — 이 엔드투엔드로 실행되지는 않았습니다. 프로덕션 모니터링 루틴에서 이 서버에 의존하기 전에 실제 키로 두 도구를 각각 한 번씩 실행하고(이 확인에는 로컬에서 stdio로 실행하는 것으로 충분합니다), 출력이 위에 문서화된 형태와 일치하는지 확인하세요.
perplexity_company_news와 perplexity_market_signals는 모두 기본적으로 sonar-pro 모델을 사용합니다(sonar보다 더 깊은 검색, 더 많은 소스, 호출당 더 높은 비용). 모니터링 사용 사례가 지연 시간/비용보다 완전성과 인용 품질을 우선시하기 때문입니다. 이는 이 서버의 두 도구 모두에 대한 의도된 기본값이며, 2026-08-26에 확인되었습니다. 일회성 쿼리에 더 저렴한 모델을 선택할 수 있는 perplexity_search 도구는 여기에 없습니다. 그런 용도로는 Perplexity 공식 MCP 서버를 사용하세요(이 파일 상단의 수정 사항 참조). 주간 루틴 규모로 수십 개 회사를 대상으로 실행하기 전에 Perplexity의 현재 모델별 가격을 검토하세요 — 전체 실행은 약 50-90개 회사와 한 번의 market-signals 스윕을 처리하므로 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.
