Integrates with the Perplexity API Platform, providing AI assistants with real-time web search, reasoning, and research capabilities through tools like perplexity_search, perplexity_ask, perplexity_research, and perplexity_reason.
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 API Platform MCP Server What are the latest breakthroughs in cancer research?"
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.
The official MCP server implementation for the Perplexity API Platform, providing AI assistants with real-time web search, reasoning, and research capabilities through the Agent API and the Search API.
The remote MCP server is hosted by Perplexity and is the easiest way to get started: same tools, nothing to install or update. The Cursor and VS Code buttons at the top of this page connect to it with one click. If your MCP client does not support remote servers yet, skip to the local server setup below. Connect over Streamable HTTP with your Perplexity API key:
https://api.perplexity.ai/mcpFor Claude Code:
claude mcp add --transport http perplexity https://api.perplexity.ai/mcp --header "Authorization: Bearer YOUR_API_KEY"See the MCP integration docs for manual Cursor/VS Code configuration, usage from the Anthropic API, and setup for other clients.
Related MCP server: Perplexity Agent MCP
Get your Perplexity API Key from the API Portal
Replace your_key_here in the configurations below with your API key
(Optional) Set timeout: PERPLEXITY_TIMEOUT_MS=600000 (default: 5 minutes)
(Optional) Set custom base URL: PERPLEXITY_BASE_URL=https://your-custom-url.com (default: https://api.perplexity.ai)
(Optional) Set log level: PERPLEXITY_LOG_LEVEL=DEBUG|INFO|WARN|ERROR (default: ERROR)
claude mcp add perplexity --env PERPLEXITY_API_KEY="your_key_here" -- npx -y @perplexity-ai/mcp-serverOr install via plugin:
export PERPLEXITY_API_KEY="your_key_here"
claude
# Then run: /plugin marketplace add perplexityai/modelcontextprotocol
# Then run: /plugin install perplexitycodex mcp add perplexity --env PERPLEXITY_API_KEY="your_key_here" -- npx -y @perplexity-ai/mcp-serverMost clients can be configured manually using the same mcpServers wrapper in their client config (as shown for Cursor). If a client has a different schema, check its docs for the exact wrapper format.
For manual setup, these clients all use the same mcpServers structure:
Client | Config File |
Cursor |
|
Claude Desktop |
|
Kiro |
|
Windsurf |
|
VS Code |
|
{
"mcpServers": {
"perplexity": {
"command": "npx",
"args": ["-y", "@perplexity-ai/mcp-server"],
"env": {
"PERPLEXITY_API_KEY": "your_key_here"
}
}
}
}If you are running this server at work—especially behind a company firewall or proxy—you may need to tell the program how to send its internet traffic through your network's proxy. Follow these steps:
1. Get your proxy details
Ask your IT department for your HTTPS proxy address and port.
You may also need a username and password.
2. Set the proxy environment variable
The easiest and most reliable way for Perplexity MCP is to use PERPLEXITY_PROXY. For example:
export PERPLEXITY_PROXY=https://your-proxy-host:8080If your proxy needs a username and password, use:
export PERPLEXITY_PROXY=https://username:password@your-proxy-host:80803. Alternate: Standard environment variables
If you'd rather use the standard variables, we support HTTPS_PROXY and HTTP_PROXY.
The server checks proxy settings in this order:PERPLEXITY_PROXY → HTTPS_PROXY → HTTP_PROXY. If none are set, it connects directly to the internet.
URLs must include https://. Typical ports are 8080, 3128, and 80.
For cloud or shared deployments, run the server in HTTP mode.
Variable | Description | Default |
| Your Perplexity API key | Required |
| Custom base URL for API requests |
|
| HTTP server port |
|
| Network interface to bind to. Defaults to loopback. Set to |
|
| CORS origins (comma-separated). Defaults to empty (no cross-origin browser requests). Set to an explicit allowlist (e.g. | (empty) |
| Additional | (loopback only) |
docker build -t perplexity-mcp-server .
docker run -p 8080:8080 -e PERPLEXITY_API_KEY=your_key_here perplexity-mcp-serverexport PERPLEXITY_API_KEY=your_key_here
npm install && npm run build && npm run start:httpThe server will be accessible at http://localhost:8080/mcp
Direct web search using the Perplexity Search API. Returns ranked search results with metadata, perfect for finding current information. Supports recency filters (search_recency_filter) and domain restrictions (search_domain_filter).
General-purpose conversational AI with real-time web search, backed by the Agent API fast preset. Great for quick questions and everyday searches.
Deep, comprehensive research backed by the Agent API high preset. Ideal for thorough analysis and detailed reports. Runs can take minutes; the server streams the run and reports progress to clients that request it.
Advanced reasoning and problem-solving backed by the Agent API medium preset. Perfect for complex analytical tasks.
Presets are managed configurations (model, search setup, step budget) that Perplexity keeps tuned over time; see thepresets guide. Earlier versions of this server called the legacy sonar-pro, sonar-reasoning-pro, and sonar-deep-research models and accepted strip_thinking / reasoning_effort parameters. Those parameters are no longer part of the tool schemas and are ignored if sent; the Agent API produces no <think> tags.
The package also exports the server factory for embedding in your own Node process:
import { createPerplexityServer } from "@perplexity-ai/mcp-server";
// Single-tenant: reads PERPLEXITY_API_KEY from the environment.
const server = createPerplexityServer("my-service");
// Multi-tenant hosts resolve the key per call instead. When a provider is
// set, the environment variable is never consulted, and a provider that
// returns no key fails the call rather than falling back.
const tenantServer = createPerplexityServer("my-service", {
apiKey: () => currentRequestApiKey,
});Mount the returned server on any MCP transport (stdio, streamable HTTP, in-memory).
API Key Issues: Ensure PERPLEXITY_API_KEY is set correctly
Connection Errors: Check your internet connection and API key validity
Tool Not Found: Make sure the package is installed and the command path is correct
Timeout Errors: For very long research queries, set PERPLEXITY_TIMEOUT_MS to a higher value
Proxy Issues: Verify your PERPLEXITY_PROXY or HTTPS_PROXY setup and ensure api.perplexity.ai isn't blocked by your firewall.
EOF / Initialize Errors: Some strict MCP clients fail because npx writes installation messages to stdout. Use npx -yq instead of npx -y to suppress this output.
For support, visit community.perplexity.ai or file an issue.
Answer a question using web-grounded AI (Perplexity Agent API, fast preset). Best for: quick factual questions, summaries, explanations, and general Q&A. Returns a text response with numbered citations. Fastest and cheapest option. Supports filtering by recency (hour/day/week/month/year), domain restrictions, and search context size. For in-depth multi-source research, use perplexity_research instead. For step-by-step reasoning and analysis, use perplexity_reason instead.
| Name | Required | Description | Default |
|---|---|---|---|
| messages | Yes | Array of conversation messages | |
| search_context_size | No | Controls how much web context is retrieved. 'low' is fastest, 'high' provides more comprehensive results. | |
| search_domain_filter | No | Restrict search results to specific domains (e.g., ['wikipedia.org', 'arxiv.org']). Use '-' prefix for exclusion (e.g., ['-reddit.com']). | |
| search_recency_filter | No | Filter search results by recency. Use 'hour' for very recent news, 'day' for today's updates, 'week' for this week, etc. |
| Name | Required | Description |
|---|---|---|
| response | Yes | AI-generated text response with numbered citation references |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds meaningful context beyond annotations: it returns text with numbered citations, supports recency/domain filtering, and search context size adjustment. No contradictions; slight gap on rate limits or error behavior, but annotations cover the safety profile.
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 compact and front-loaded with the primary purpose, then usage, features, and alternatives. It is slightly longer than two sentences but every clause serves a distinct informative purpose, avoiding fluff or redundancy.
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?
For a read-only tool with rich annotations, 100% schema coverage, and an output schema, the description covers purpose, appropriate usage, alternative tools, key behavioral traits, and configuration options. Nothing essential is missing for an agent to select and invoke it 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 description coverage is 100%, so the schema already documents all parameters thoroughly. The description mentions filtering capabilities at a high level but adds no syntax or detailed semantics beyond what the schema provides. Baseline 3 is appropriate.
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 uses a specific verb ('Answer a question') and resource ('web-grounded AI – Perplexity Agent API'), and explicitly distinguishes it from siblings ('For in-depth multi-source research, use perplexity_research instead. For step-by-step reasoning and analysis, use perplexity_reason instead.'). This makes the tool's purpose unambiguous.
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 explicit 'Best for' scenarios (quick factual questions, summaries, explanations, general Q&A), the fastest/cheapest option, and directly names alternative tools for other use cases. Clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze a question using step-by-step reasoning with web grounding (Perplexity Agent API, medium preset). Best for: math, logic, comparisons, complex arguments, and tasks requiring chain-of-thought. Returns a reasoned response with numbered citations. Supports filtering by recency (hour/day/week/month/year), domain restrictions, and search context size. For quick factual questions, use perplexity_ask instead. For comprehensive multi-source research, use perplexity_research instead.
| Name | Required | Description | Default |
|---|---|---|---|
| messages | Yes | Array of conversation messages | |
| search_context_size | No | Controls how much web context is retrieved. 'low' is fastest, 'high' provides more comprehensive results. | |
| search_domain_filter | No | Restrict search results to specific domains (e.g., ['wikipedia.org', 'arxiv.org']). Use '-' prefix for exclusion (e.g., ['-reddit.com']). | |
| search_recency_filter | No | Filter search results by recency. Use 'hour' for very recent news, 'day' for today's updates, 'week' for this week, etc. |
| Name | Required | Description |
|---|---|---|
| response | Yes | AI-generated text response with numbered citation references |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and non-destructive behavior. The description adds meaningful context beyond annotations: it uses the Perplexity Agent API with a medium preset, returns numbered citations, and offers filtering options. No contradiction exists, and the added behavioral details help set expectations.
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 five sentences, each earning its place: main purpose, best-for list, output format, filter capabilities, and sibling alternatives. It is front-loaded with the core verb and stays compact without redundancy.
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?
For a tool with moderate complexity (4 params, output schema exists, annotations present), the description is complete. It covers purpose, use cases, output style (reasoned response with numbered citations), filtering options, and alternative tools, leaving no critical gaps for an agent to select and invoke 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%, so the baseline is 3. The description adds semantic value by naming the medium preset (implying a default search_context_size), listing recency filter options, and framing the filters as search capabilities. This slightly exceeds baseline by connecting parameters to the tool's reasoning workflow.
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 analyzes questions using step-by-step reasoning and web grounding, with a specific list of use cases (math, logic, comparisons, complex arguments). It explicitly distinguishes itself from siblings perplexity_ask and perplexity_research, making its unique role clear.
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 explicit 'Best for' scenarios and direct alternatives: 'For quick factual questions, use perplexity_ask instead. For comprehensive multi-source research, use perplexity_research instead.' This gives clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Conduct deep, multi-source research on a topic (Perplexity Agent API, high preset). Best for: literature reviews, comprehensive overviews, investigative queries needing many sources. Returns a detailed response with numbered citations. Significantly slower than other tools (can take minutes). For quick factual questions, use perplexity_ask instead. For logical analysis and reasoning, use perplexity_reason instead.
| Name | Required | Description | Default |
|---|---|---|---|
| messages | Yes | Array of conversation messages |
| Name | Required | Description |
|---|---|---|
| response | Yes | AI-generated text response with numbered citation references |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and non-destructive behavior. The description adds valuable behavioral context beyond annotations: 'Significantly slower than other tools (can take minutes)' and 'Returns a detailed response with numbered citations,' which are not evident from the annotations alone.
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 and well-structured: it starts with the core function, then best-for use cases, output characteristics, performance caveat, and alternatives. Every sentence serves a purpose without redundancy or fluff.
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 and the existence of an output schema, the description covers purpose, usage guidance, performance, output format (citations), and alternatives. It is fully self-contained and insufficient in no aspect, so it earns a 5.
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?
The schema covers 100% of the parameter (messages) with role/content definitions, so baseline is 3. The description does not add specific parameter-level details but contextualizes the input as a 'topic,' which is already implied by the schema. No significant added meaning beyond 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 clearly states the tool's function: 'Conduct deep, multi-source research on a topic' with a specific verb and resource. It explicitly distinguishes from siblings by mentioning 'high preset' and contrasting with perplexity_ask and perplexity_reason, making the purpose unambiguous.
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 explicit guidance on when to use this tool ('Best for: literature reviews, comprehensive overviews, investigative queries needing many sources') and when not to: 'For quick factual questions, use perplexity_ask instead. For logical analysis and reasoning, use perplexity_reason instead.' This clear alternatives/exclusion structure earns a top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the web and return a ranked list of results with titles, URLs, snippets, and dates. Best for: finding specific URLs, checking recent news, verifying facts, discovering sources. Returns formatted results (title, URL, snippet, date) with no AI synthesis. Supports recency filters and domain restrictions. For AI-generated answers with citations, use perplexity_ask instead.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query string | |
| country | No | ISO 3166-1 alpha-2 country code for regional results (e.g., 'US', 'GB') | |
| max_results | No | Maximum number of results to return (1-20, default: 10) | |
| max_tokens_per_page | No | Maximum tokens to extract per webpage (default: 1024) | |
| search_domain_filter | No | Restrict search results to specific domains (e.g., ['wikipedia.org', 'arxiv.org']). Use '-' prefix for exclusion (e.g., ['-reddit.com']). | |
| search_recency_filter | No | Filter search results by recency. Use 'hour' for very recent news, 'day' for today's updates, 'week' for this week, etc. |
| Name | Required | Description |
|---|---|---|
| results | Yes | Formatted search results, each with title, URL, snippet, and date |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal readOnlyHint=true and destructiveHint=false, so the description doesn't need to repeat safety. It adds useful behavioral context: returns formatted results with 'no AI synthesis' (raw output) and supports recency/domain filters. While it doesn't mention pagination or rate limits, the annotation coverage lowers the bar, and the description adds meaningful value.
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 and front-loaded: two sentences with the core action, a 'Best for' list, and an alternative pointer. Every sentence serves a purpose, with no redundant or filler text.
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 output schema exists and annotations cover safety, so the description doesn't need to explain return values. It covers main use cases, differentiates from a sibling, and notes key capabilities. It could also mention perplexity_research/reason for completeness, but that's not essential for this tool.
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%, so baseline is 3. The description mentions 'recency filters and domain restrictions,' which echoes the schema but adds no new syntax or constraint details. Parameters are already fully documented in the input 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 clearly states the tool's action and resource: 'Search the web and return a ranked list of results with titles, URLs, snippets, and dates.' It also distinguishes from sibling perplexity_ask by explicitly noting 'no AI synthesis' and directing AI-answer needs to perplexity_ask.
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 an explicit 'Best for' list (finding specific URLs, checking recent news, verifying facts, discovering sources) and an explicit alternative: 'For AI-generated answers with citations, use perplexity_ask instead.' This clearly guides when to use this tool versus a 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.2.0perplexity_askperplexity_reasonperplexity_researchperplexity_searchEach tool serves a clearly distinct purpose: ask for quick facts, research for deep multi-source investigation, reason for step-by-step analysis, and search for raw results. Descriptions explicitly cross-reference other tools and define boundaries, eliminating ambiguity.
All tool names follow the consistent pattern `perplexity_<action>` with clear, descriptive verbs (ask, research, reason, search). This creates a predictable and easily navigable API surface.
With exactly 4 tools, the server is tightly scoped to Perplexity's core interaction modes. Each tool adds functional value, and the count feels neither sparse nor bloated.
The tool set covers the full spectrum of Perplexity API use cases: simple queries, deep research, reasoning, and direct search. There are no obvious dead ends or missing operations within the stated purpose of the server.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Real-time web search, reasoning, and research through Perplexity's API
Enable AI assistants to perform web searches using Perplexity's Sonar Pro.
Give AI assistants access to real-time data. Search the web, compare flights, find hotels, and more.
Agent-native search engine with live web research optimized for AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/adefemi-dev/Perplexity-AI-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
