Perplexity MCP Server
Provides tools to perform web searches and deep research using Perplexity's Sonar models, returning answers with citations and search results.
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 Serversummarize the latest space exploration news"
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.
Perplexity MCP Server
Python MCP server that exposes Perplexity Sonar Chat Completions to any MCP client (Cursor, Claude Desktop, custom agents).
Tools
Tool | Default model | Purpose |
|
| General web search |
|
| Comprehensive synthesis |
Both tools accept optional Sonar parameters and return JSON:
{
"answer": "...",
"citations": ["https://..."],
"search_results": [],
"model": "sonar-pro",
"usage": {}
}Optional parameters
Parameter | Values / format | When to use |
|
| Lower = more focused; raise only for more varied phrasing |
|
| Cap answer length; omit for API default |
|
| News / “latest” questions; omit for evergreen topics |
|
| Absolute start of publication window |
|
| Absolute end of publication window |
| up to 20 domains; allowlist or | Trusted sources only, or exclude noisy sites |
|
| Papers ( |
|
| Override tool default only when you need a different speed/depth tradeoff |
Prefer date filters over search_recency_filter when the window is known exactly. Queries are capped at 4,000 characters. The API key is never logged or returned in tool output.
Related MCP server: Perplexity Web-Search MCP
Setup
Copy env template and add your Perplexity API key:
cp .env.example .envInstall with uv:
uv syncRun locally (stdio)
uv run mcp-perplexityCursor / Claude Desktop
Add to your MCP config (adjust the project path):
{
"mcpServers": {
"perplexity": {
"command": "uv",
"args": ["--directory", "C:/Users/KozakJ/git/mcp_perplexity", "run", "mcp-perplexity"],
"env": {
"PERPLEXITY_API_KEY": "pplx-your-api-key-here"
}
}
}
}Or rely on a .env file in the project directory (PERPLEXITY_API_KEY=...).
Cursor / Claude Desktop (container, stdio)
Rebuild after image changes, then only the API key is required — other settings use the same defaults as local runs:
{
"mcpServers": {
"perplexity": {
"command": "podman",
"args": [
"run", "-i", "--rm",
"-e", "PERPLEXITY_API_KEY",
"mcp-perplexity"
],
"env": {
"PERPLEXITY_API_KEY": "pplx-your-api-key-here"
}
}
}
}Override any setting the same way (-e MCP_PORT, etc.) only when you need non-defaults.
Run with Podman (streamable HTTP)
podman compose needs a compose provider (podman-compose or Docker Compose). On a plain Podman install, use build + run:
podman build -t mcp-perplexity .
podman run --rm -p 8000:8000 --env-file .env ^
-e MCP_TRANSPORT=streamable-http ^
-e MCP_HOST=0.0.0.0 ^
-e MCP_PORT=8000 ^
--name mcp-perplexity mcp-perplexity(On bash/zsh, replace ^ with \.)
If you have a compose provider installed (pip install podman-compose, or Docker Compose):
podman compose up --buildEndpoint: http://localhost:8000/mcp (Streamable HTTP). Bind to trusted networks only — this image does not add HTTP auth.
Configuration
Variable | Default | Description |
| (required) | Perplexity API key |
|
|
|
|
| HTTP bind host |
|
| HTTP bind port |
|
| Soft client-side requests/minute limit |
|
| Max concurrent API calls |
|
| Search timeout (seconds) |
|
| Deep research timeout (seconds) |
|
| Retries on 429/5xx and transport errors |
Retries use exponential backoff (honors Retry-After when present). Logging goes to stderr only so stdio JSON-RPC stays clean.
Available Tools
2 toolsperplexity_deep_researchA
Comprehensive synthesis via Perplexity Sonar Deep Research.
Returns JSON with answer, citations, and optional search_results/usage.
Uses a longer timeout suitable for exhaustive research.
When to use optional filters:
- search_recency_filter: current events / "latest" questions (hour|day|week|month|year).
- search_after/before_date_filter: absolute windows as MM/DD/YYYY; prefer over recency when exact.
- search_domain_filter: trusted sources (allowlist) or exclude noise (denylist with '-'); one mode only.
- search_mode: 'academic' for papers, 'sec' for SEC filings; omit for general web.
- Leave filters unset for broad evergreen queries.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Sonar model id: sonar (fast), sonar-pro (default search quality), sonar-deep-research (exhaustive synthesis), or sonar-reasoning-pro. Leave the tool default unless you need a different speed/depth tradeoff. | sonar-deep-research |
| query | Yes | Natural-language search or research question. Non-empty; max 4000 characters. | |
| max_tokens | No | Maximum completion tokens. Omit to use the API default; set only when you need a shorter or longer answer budget. | |
| search_mode | No | Search corpus: 'web' (general web, default), 'academic' (scholarly papers), or 'sec' (SEC filings). Set academic for literature reviews; sec for company filings; omit or web for general questions. | |
| temperature | No | Sampling temperature (0-2). Lower values (default 0.2) keep answers focused and factual; raise only when more varied phrasing is wanted. | |
| search_domain_filter | No | Limit or exclude domains/URLs (max 20). Allowlist: ['nature.com', 'nih.gov']. Denylist: ['-reddit.com', '-pinterest.com']. Use one mode only - do not mix allowlist and denylist entries in the same request. | |
| search_recency_filter | No | Restrict results to recent publications: hour, day, week, month, or year. Use for news, live events, or 'latest' questions. Omit for evergreen topics. Prefer absolute date filters when an exact window is known. | |
| search_after_date_filter | No | Only include results published after this date. Format: MM/DD/YYYY (e.g. 01/15/2024). Prefer over search_recency_filter for an absolute start. | |
| search_before_date_filter | No | Only include results published before this date. Format: MM/DD/YYYY (e.g. 12/31/2024). Prefer over search_recency_filter for an absolute end. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the burden. It discloses the output format (JSON with answer, citations, optional fields), timeout behavior ('longer timeout suitable for exhaustive research'), and optional filter behavior. However, it does not discuss error states, rate limits, or authentication requirements, which could be important for agent planning.
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 concise, with a clear front-loaded purpose and output format, followed by the timeout note and structured filter guidance. Every sentence adds value. The filter section could be more bulletized, but it remains easy to scan. No redundant or tautological content.
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?
Given the tool's complexity (9 parameters, output schema exists), the description covers the core purpose, output format, timeout, and filter usage comprehensively. It does not need to explain return values since the output schema provides that. Missing details like error handling or limits are acceptable given the parameter and schema richness.
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 description coverage is 100%, so the baseline is 3. The description adds value by connecting filter usage to real-world scenarios (e.g., 'current events / "latest" questions' for recency, 'absolute windows as MM/DD/YYYY' for date filters) and stating preferences (e.g., 'prefer over recency when exact'). This context clarifies when to use each parameter beyond the schema's individual descriptions.
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 tool performs 'comprehensive synthesis via Perplexity Sonar Deep Research' and returns JSON with answer and citations. It implies a deeper, more exhaustive research capability compared to the sibling tool 'perplexity_search', though it does not explicitly differentiate. The purpose is specific and actionable.
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 detailed guidance on when to use optional filters (e.g., 'search_recency_filter: current events / "latest" questions'), and advises 'Leave filters unset for broad evergreen queries.' However, it lacks explicit guidance on when to choose this tool over the sibling 'perplexity_search,' leaving the AI agent to infer based on the 'deep research' name and 'longer timeout' mention.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
perplexity_searchA
General web search via Perplexity Sonar (default model: sonar-pro).
Returns JSON with answer, citations, and optional search_results/usage.
When to use optional filters:
- search_recency_filter: current events / "latest" questions (hour|day|week|month|year).
- search_after/before_date_filter: absolute windows as MM/DD/YYYY; prefer over recency when exact.
- search_domain_filter: trusted sources (allowlist) or exclude noise (denylist with '-'); one mode only.
- search_mode: 'academic' for papers, 'sec' for SEC filings; omit for general web.
- Leave filters unset for broad evergreen queries.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Sonar model id: sonar (fast), sonar-pro (default search quality), sonar-deep-research (exhaustive synthesis), or sonar-reasoning-pro. Leave the tool default unless you need a different speed/depth tradeoff. | sonar-pro |
| query | Yes | Natural-language search or research question. Non-empty; max 4000 characters. | |
| max_tokens | No | Maximum completion tokens. Omit to use the API default; set only when you need a shorter or longer answer budget. | |
| search_mode | No | Search corpus: 'web' (general web, default), 'academic' (scholarly papers), or 'sec' (SEC filings). Set academic for literature reviews; sec for company filings; omit or web for general questions. | |
| temperature | No | Sampling temperature (0-2). Lower values (default 0.2) keep answers focused and factual; raise only when more varied phrasing is wanted. | |
| search_domain_filter | No | Limit or exclude domains/URLs (max 20). Allowlist: ['nature.com', 'nih.gov']. Denylist: ['-reddit.com', '-pinterest.com']. Use one mode only - do not mix allowlist and denylist entries in the same request. | |
| search_recency_filter | No | Restrict results to recent publications: hour, day, week, month, or year. Use for news, live events, or 'latest' questions. Omit for evergreen topics. Prefer absolute date filters when an exact window is known. | |
| search_after_date_filter | No | Only include results published after this date. Format: MM/DD/YYYY (e.g. 01/15/2024). Prefer over search_recency_filter for an absolute start. | |
| search_before_date_filter | No | Only include results published before this date. Format: MM/DD/YYYY (e.g. 12/31/2024). Prefer over search_recency_filter for an absolute end. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses return format and filter behaviors but does not mention rate limits, authentication, or potential side effects. Adequate but not comprehensive.
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?
Well-structured with front-loaded purpose, return format, and bullet-point filter guidelines. No unnecessary sentences; every part adds value.
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?
Given 9 parameters, 100% schema coverage, and existing output schema, the description covers essential aspects. Could mention authentication or rate limits, but not critical for correct invocation.
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%, baseline 3. Description adds practical usage guidance beyond schema descriptions, such as when to use recency vs date filters and domain filter modes.
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?
Clearly states it is a general web search via Perplexity Sonar, returns JSON with answer and citations. The name and description distinguish it from sibling 'perplexity_deep_research'.
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?
Provides detailed guidance on when to use each optional filter, but does not explicitly compare this tool with the sibling deep research tool. Usage context is implied for general search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
2 tool updates
v0.1.0- First observed
perplexity_deep_research - First observed
perplexity_search
TDQS
Scored across 2 tools
Both tools target web search via Perplexity with nearly identical descriptions, differing only in timeout and 'deep research' label. An agent may struggle to choose between them without clear use-case differentiation.
Both tool names follow a consistent pattern: 'perplexity_search' and 'perplexity_deep_research' use the same prefix and verb_noun structure, making them clearly identifiable.
With only 2 tools, the set is minimal but arguably covers the server's purpose (search and deep research). However, the overlap reduces the value of having two separate tools.
The set only provides two search variants, lacking any additional functionalities like result filtering, history, or configuration. Important search UX features are missing, making the surface incomplete for a comprehensive search server.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Enable AI assistants to perform web searches using Perplexity's Sonar Pro.
Real-time web search, reasoning, and research through Perplexity's API
Live AI-native web search with citations. One tool for every MCP client. Flat per-request pricing.
Scrape, crawl and search the web for AI agents via MCP.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceIntegrates the Sonar API to provide Claude with real-time web-wide research capabilities. Enables conversational web searches through Perplexity's AI-powered search engine for up-to-date information retrieval.1,514MIT
- FlicenseBqualityDmaintenanceEnables AI assistants to perform real-time web and academic searches using Perplexity's Sonar API.2-
- AlicenseBqualityDmaintenanceEnables web search using Perplexity AI's API, allowing users to search the web with optional recency filters and integration with Claude, Cursor, and other MCP clients.1MIT
- AlicenseAqualityDmaintenanceEnables AI assistants to perform web searches and retrieve real-time information using Perplexity AI's Sonar models, with support for multiple search modes and easy integration with MCP clients.51MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jujubytes-a11y/mcp_perplexity'
If you have feedback or need assistance with the MCP directory API, please join our Discord server