A narrowly focused MCP server for structured competitive/market-intelligence workflows on top of Perplexity Sonar, exposing two workflow tools rather than generic search.
perplexity_company_news: Generate a structured, cited news brief for a single company, with fixed sections (governance, executives, strategic events, financial situation, senior HR moves), configurable lookback window (1–365 days), language (French/English), and output as markdown or JSON.
perplexity_market_signals: Run a sector-wide signal sweep (M&A, funding, executive appointments, restructurings) filtered by professional profile, region, signal types, and lookback period, returning a structured JSON array of dated signals (or an empty array when nothing reliable is found).
Both tools support markdown or JSON responses and include citations/sources, with clean error handling for invalid API keys or rate limits.
Can run locally over stdio for testing, or deployed as a stateless streamable HTTP server (POST /mcp, GET /health) for cloud-scheduled MCP clients, with the Perplexity API key kept server-side.
It deliberately complements Perplexity's official MCP server: use this for repeatable, comparable veille workflows; use the official server for generic ad hoc search.
Provides structured competitive and market-intelligence workflows on top of Perplexity's Sonar API, including a fixed-section company news brief tool and a sector-wide signal sweep tool that returns discrete JSON-schema-constrained signals with citations.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@perplexity-mcp-server Pull a 7-day company news brief for OpenAI with sources"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for structured competitive/market-intelligence veille workflows on top of the Perplexity Sonar API.
Correction (2026-08-26): an earlier version of this README claimed no native Perplexity MCP
connector existed anywhere. That was wrong — Perplexity publishes an official MCP server
(github.com/perplexityai/modelcontextprotocol),
including a Perplexity-hosted remote endpoint at https://api.perplexity.ai/mcp that's reachable
from a cloud-scheduled session with zero self-hosting. If you just need generic ad hoc Sonar
search, register that instead of building or running anything here.
What the official server doesn't give you is a structured, comparable weekly veille output: it exposes generic search/reasoning (Agent API, Search API), not a fixed-section company brief or a JSON-schema-constrained signal sweep. That's this server's actual reason to exist — it's a thin, narrow layer of two workflow tools, not a replacement for Perplexity's own MCP server.
Deploy this once (see "Remote deployment" below) with PERPLEXITY_API_KEY set as a platform
secret, and any MCP client — including a cloud-scheduled Cowork/Claude session — can call it over
HTTP without ever touching the local machine or a device bridge. Register it alongside
Perplexity's official server, not instead of it.
perplexity_company_news — structured company news brief (governance, executives, strategic
events, financial situation, senior HR moves), fixed section headings, lookback_days instead of
free-text date ranges. Output language is fr (default) or en via the language parameter —
headings switch accordingly (e.g. Gouvernance/Governance, Dirigeants/Executives).
perplexity_market_signals — sector-wide signal sweep (M&A, funding, appointments,
restructurings) constrained to a JSON schema server-side, so the result is a real array of
discrete signals, not markdown to re-parse. Returns an empty array (not an error) when nothing
dated and reliable is found for the period — that's a meaningful result, not a failure.
Both tools support response_format: "markdown" | "json" and return citations/sources. For
general-purpose search, use Perplexity's official MCP server instead — see the correction above.
Related MCP server: earningsprism-mcp
npm install
cp .env.example .env # then set PERPLEXITY_API_KEY
npm run buildGood for testing, or for any workflow that already runs on your own machine. Register it in your
MCP client's config (e.g. Claude Desktop's claude_desktop_config.json):
{
"mcpServers": {
"perplexity": {
"command": "node",
"args": ["/absolute/path/to/perplexity-mcp-server/dist/index.js"],
"env": { "PERPLEXITY_API_KEY": "pplx-..." }
}
}
}This still ties availability to that machine being on — it does not solve the original problem of a cloud-scheduled task needing the key. For that, use the HTTP deployment below.
Run the same code with TRANSPORT=http, on any Node-capable host (a small VPS, Render, Railway,
Fly.io, a container on any cloud provider). The only requirements are: Node 18+, the ability to set
an environment variable secret, and a public HTTPS URL.
PERPLEXITY_API_KEY=pplx-... TRANSPORT=http PORT=3000 npm startThe server exposes:
POST /mcp — the MCP endpoint (streamable HTTP, stateless JSON — a fresh server+transport per
request, so nothing leaks between calls and it scales horizontally without shared state)
GET /health — plain liveness check for your hosting platform's health probe
Once deployed behind HTTPS (https://your-host/mcp), register that URL as a remote MCP connector
in the workspace so the Perplexity-dependent scheduled task can reach it directly, with the key
living server-side — the same operational model Pappers already uses (native connector, no local
secret in the credential path).
npm run build compiles cleanly (strict TypeScript, no any).
Both transports start without crashing (stdio and HTTP).
GET /health responds correctly.
Full MCP handshake (initialize, tools/list) returns both tools with correct JSON schemas,
descriptions, and annotations.
tools/call with an invalid API key returns a clean, actionable isError: true result (401
guidance pointing at the Perplexity dashboard) — the server does not crash and stays responsive
afterward.
No real PERPLEXITY_API_KEY was available in the build environment, so an actual successful
Sonar call — real answer content, real citations, the market_signals JSON-schema-constrained
response actually parsing as valid JSON — has not been exercised end-to-end. Before relying on this
in the production veille routine, run each of the two tools once with a real key (locally via
stdio is enough for this check) and confirm the output matches the shapes documented above.
perplexity_company_news and perplexity_market_signals both default to the sonar-pro model
(deeper search, more sources, higher cost per call than sonar) because the veille use case
prioritizes completeness and citation quality over latency/cost — this is the deliberate default
for both of this server's tools, confirmed 2026-08-26. There is no perplexity_search tool here to
opt into a cheaper model for one-off queries; use Perplexity's official MCP server for that (see
the correction at the top of this file). Review Perplexity's current per-model pricing before
running this at the weekly-routine scale
across dozens of companies — a full run enriches on the order of 50-90 companies plus one
market-signals sweep, so the marginal cost of sonar-pro vs sonar compounds quickly.
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. Dates show when Glama detected each change.
v1.0.0perplexity_company_newsperplexity_market_signalsThe 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Structured company & industry news for AI agents: typed, dated, source-linked events.
Private company data & real-time news signals for AI agents.
Audited SEC catalyst signals for agents — ranked filing intel with a public track record. Free tier.
Investment research superagent: podcasts, SEC filings, and no-code research pipelines.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/thierrysays/perplexity-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
