Provides tools for web search and real-time information retrieval using Perplexity AI's Sonar models, supporting multiple search and reasoning modes with citation support.
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 What are the latest breakthroughs in AI?"
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.
A Perplexity AI MCP (Model Context Protocol) server implementation that enables AI assistants to search the web and get real-time information through Perplexity's Sonar models.
This project was created to utilize the $5 credits from Perplexity's Pro plan (free for students: perplexity link), providing an easy way to access web search capabilities through MCP-compatible AI assistants.
Related MCP server: Perplexity Web-Search MCP
š Web search capabilities through Perplexity AI
š Multiple Sonar models support (sonar, sonar-pro, sonar-deep-research, sonar-reasoning, sonar-reasoning-pro)
š Easy integration with VS Code and other MCP clients
š Citation support for sources
Python 3.12 or higher
UV package manager
Perplexity API key (Get one here)
You can run perplexity-mcp directly without any installation using uv tool run. Just install UV and configure VS Code (see Configuration section below) - uv will handle everything automatically!
# Install UV package manager first
curl -LsSf https://astral.sh/uv/install.sh | sh # macOS/Linux
# or
brew install uv # macOS with HomebrewFor development or to contribute:
# macOS (Homebrew)
brew install uv
# Windows
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"
# macOS/Linux (Direct)
curl -LsSf https://astral.sh/uv/install.sh | shgit clone https://github.com/0xHumban/perplexity-mcp.git
cd perplexity-mcpuv syncNOTE: To add it globaly: Create / Update the gloabl config file:
~/.config/Code/User/mcp.json
Create or edit .vscode/mcp.json in your workspace:
{
"inputs": [
{
"type": "promptString",
"id": "perplexity-key",
"description": "API Key for Perplexity AI",
"password": true
}
],
"servers": {
"perplexity-mcp": {
"command": "uv",
"args": [
"tool", "run", "--from",
"git+https://github.com/0xHumban/perplexity-mcp.git",
"perplexity-mcp"
],
"env": {
"PERPLEXITY_API_KEY": "${input:perplexity-key}"
}
}
}
}This method runs the tool directly from GitHub without any prior installation!
Create or edit .vscode/mcp.json in your workspace:
{
"inputs": [
{
"type": "promptString",
"id": "perplexity-key",
"description": "API Key for Perplexity AI",
"password": true
}
],
"servers": {
"perplexity-mcp": {
"command": "uv",
"args": [
"run",
"perplexity-mcp"
],
"cwd": "/path/to/perplexity-mcp",
"env": {
"PERPLEXITY_API_KEY": "${input:perplexity-key}"
}
}
}
}Replace /path/to/perplexity-mcp with the actual path to your cloned repository.
Then:
Reload VS Code window
Enter your Perplexity API key when prompted
Set the environment variable:
export PERPLEXITY_API_KEY="your-api-key-here"Then run:
uv run perplexity-mcpThe Perplexity MCP server provides four main tools to interact with the Perplexity AI API:
ask_perplexity - Standard SearchMain tool for performing web searches via Perplexity AI.
How it works:
Sends a query to Perplexity AI to get up-to-date information from the web
Returns a formatted response with cited sources
Uses the default model (sonar) unless otherwise specified
Use cases:
Search for recent or real-time information
Get answers based on multiple web sources
Verify facts or current statistics
Example:
#ask_perplexity
What are the latest AI developments in October 2024?ask_perplexity_exact_response - Unmodified ResponseReturns the exact response from Perplexity AI without any modification or reformatting.
How it works:
Similar to ask_perplexity but preserves Perplexity's original response
No additional processing is applied
Ideal when you want Perplexity's raw answer
Use cases:
When you want to see exactly what Perplexity responded
To avoid any interpretation or reformatting by the assistant
Get citations and sources exactly as Perplexity provides them
Example:
#ask_perplexity_exact_response
Search for the latest tech news in Franceask_perplexity_for_instructions - Instructions ModeDesigned to obtain detailed and executable instructions on a complex topic.
How it works:
Uses a special pedagogical preprompt that guides Perplexity to provide structured instructions
Ideal for learning or understanding technical concepts
Returns detailed steps, code examples, and clear explanations
Use cases:
Learn a new concept or technology
Get a step-by-step guide to accomplish a task
Understand complex topics with practical examples
Generate example code with detailed explanations
Example:
#ask_perplexity_for_instructions
Create a REST API server in Go for my books databaseask_perplexity_to_learn - Learning ModePedagogical tool specially designed for learning complex topics.
How it works:
Uses an advanced pedagogical preprompt that structures the response to facilitate learning
Breaks down concepts into logical steps
Provides analogies, concrete examples, and comprehension checks
Uses the reasoning model by default for more in-depth explanations
Response structure:
Simple overview of the concept
Breakdown into logical steps (3-7 steps)
For each step: simple explanation + concrete example + commented code
Checkpoints to verify understanding
Summary of key points and tips to go further
Use cases:
Learning complex computer science concepts (algorithms, data structures, etc.)
Understanding mathematical principles
Studying new technologies or frameworks
Self-directed learning on technical topics
Example:
#ask_perplexity_to_learn
Teach me arithmetic coding step by step with code examples in GoAll tools support the following models:
sonar (default for ask_perplexity and ask_perplexity_exact_response)
Fast, general-purpose search
Good balance between speed and quality
Ideal for most queries
sonar-pro
Enhanced accuracy and depth
More sources and analysis
Recommended for important searches
sonar-deep-research
Comprehensive and thorough research
Complete analysis of multiple sources
For serious research projects
sonar-reasoning (default for ask_perplexity_for_instructions and ask_perplexity_to_learn)
Advanced reasoning capabilities
Better for complex explanations
Ideal for learning and instructions
sonar-reasoning-pro
Premium reasoning with extended context
Most powerful for complex tasks
Best understanding and explanation
perplexity-mcp/
āāā perplexity_mcp/
ā āāā __init__.py
ā āāā server.py # Main MCP server implementation
ā āāā cli.py
āāā pyproject.toml # Project configuration
āāā uv.lock # Dependency lock file
āāā README.mdSee LICENSE file for details.
Contributions are welcome! Please feel free to submit a Pull Request.
For issues and questions, please open an issue on GitHub.
Send a prompt to Perplexity and return the response.
Sonar models have internet access and can perform searches.
Use this for: research, current events, comparisons, finding information online.
Examples of good prompts:
- "What are the latest developments in quantum computing in 2025?"
- "Compare Python vs Rust for web development"
- "Explain the recent changes in EU privacy laws"
- "Find the best practices for React Server Components"
If the user wants to execute or learn complex tasks, use the reasoning model (sonar-reasoning)
If the user wants development work requiring real-time documentation lookup, research-intensive coding, use the reasoning model (sonar-reasoning).
But by default, use the research model (sonar).
Args:
prompt: The prompt/question to send
model: Sonar model (sonar, sonar-pro, sonar-deep-research,
sonar-reasoning, sonar-reasoning-pro)
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | ||
| model | No | sonar |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Mentions that Sonar models have internet access and can perform searches, which is a behavioral trait. However, no annotations are provided, and the description does not disclose potential side effects, rate limits, or output format beyond what is implied.
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 bullet points and examples. Every sentence adds value. No wasted words.
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 (query tool), the description adequately covers usage, parameters, and model selection. The existence of an output schema means return values are handled externally. Minor gaps: no mention of required authentication or rate limits.
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 0%, so the description must compensate. It lists model options and their uses in the guidelines, but does not explain the 'prompt' parameter's semantics beyond being a prompt/question. The baseline is 3 with 2 parameters.
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 verb 'send a prompt to Perplexity' and the resource 'return the response'. It provides specific use cases (research, current events, comparisons) but does not directly differentiate from siblings like ask_perplexity_exact_response.
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?
Explicitly states when to use the tool (research, current events, comparisons) and when to use alternative models (reasoning for complex tasks, research by default). Provides examples of good prompts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a prompt to Perplexity and return the exact response without
changing anything (no additional metadata or suggestions).
Use this when you need the raw, unmodified output from Perplexity.
Examples of good prompts:
- "Give me the exact documentation for FastAPI's dependency injection"
- "What does the official Next.js docs say about App Router?"
- "Show me the raw API response format for OpenAI's latest models"
If the user wants to execute or learn complex tasks, use the reasoning model (sonar-reasoning)
If the user wants development work requiring real-time documentation lookup, research-intensive coding, use the reasoning model (sonar-reasoning).
But by default, use the research model (sonar).
Sonar models have internet access and can perform searches.
Args:
prompt: The prompt/question to send
model: Sonar model (sonar, sonar-pro, sonar-deep-research,
sonar-reasoning, sonar-reasoning-pro)
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | ||
| model | No | sonar |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the tool returns exact response without metadata and that Sonar models have internet access. With no annotations, the description adequately covers behavioral traits.
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?
Front-loaded with purpose, followed by usage guidance and examples. Concise but comprehensive; every sentence 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 an output schema exists and the tool is straightforward, the description covers purpose, usage, parameters, and model choices adequately.
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?
With 0% schema description coverage, the description adds value by listing model options and providing example prompts. For the 'model' parameter, it enumerates valid values 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?
Description clearly states the tool sends a prompt to Perplexity and returns the exact response unchanged. It distinguishes itself from siblings by emphasizing raw output with no modifications.
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 when-to-use guidance ('Use this when you need the raw, unmodified output') and examples. Mentions alternative models for different tasks, but does not explicitly name sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a prompt to Perplexity and get step-by-step instructions that
Copilot can execute in agent mode.
This tool is optimized for tasks that require multiple steps or actions.
The response will be formatted as executable instructions for the AI agent.
Examples of good prompts:
- "How do I set up a Python FastAPI project with Docker?"
- "Create a React app with TypeScript and Tailwind CSS"
- "Set up CI/CD pipeline for a Node.js application"
- "Configure a PostgreSQL database with Redis caching"
Sonar models have internet access and can perform searches.
Args:
prompt: The prompt/question to send
model: Sonar model (sonar, sonar-pro, sonar-deep-research,
sonar-reasoning, sonar-reasoning-pro)
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | ||
| model | No | sonar-reasoning |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It mentions that Sonar models have internet access and can search, but does not disclose potential side effects, authentication requirements, rate limits, or what happens on failure. The behavioral disclosure is minimal.
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 structured with a header, optimization note, examples, and model info. Each section serves a purpose, though it could be slightly more concise. Overall, it is well-organized and front-loaded.
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 presence of an output schema, the description covers basic purpose and examples. However, it lacks details on instruction format, limitations, or additional context needed for safe use. It is adequate but not fully comprehensive.
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 0%, yet the description only lists parameter names and a model list without explaining differences or providing validation guidance. It adds minimal value beyond the bare schema, failing to compensate for the lack of schema 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 sends a prompt to Perplexity and returns step-by-step instructions executable by the AI agent. It distinguishes itself from siblings like 'ask_perplexity' and 'ask_perplexity_exact_response' by emphasizing multi-step tasks and executable format.
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 explicit examples of good prompts (e.g., 'How do I set up a Python FastAPI project with Docker?') and states the tool is optimized for multi-step tasks. It does not explicitly exclude scenarios or name alternatives, but the context makes usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Learn complex concepts with pedagogical explanations, examples, and analogies.
This tool uses a teaching-optimized approach with:
- Simple overviews and context
- Step-by-step breakdowns
- Concrete examples and analogies
- Code snippets when relevant
- Clear summaries and next steps
Examples of good prompts:
- "Explain how async/await works in Python"
- "Teach me about Docker containers and why they're useful"
- "What are React hooks and how do I use them?"
- "Explain database indexing with practical examples"
- "How does JWT authentication work?"
Sonar models have internet access and can perform searches.
Args:
prompt: The prompt/question to send
model: Sonar model (sonar, sonar-pro, sonar-deep-research,
sonar-reasoning, sonar-reasoning-pro)
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | ||
| model | No | sonar-reasoning |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 mentions internet access and a teaching approach but does not disclose whether the tool is read-only, has rate limits, or any restrictions. As a learning tool, it is likely read-only, but this is not explicitly stated.
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 structured with bullet points and examples, making it easy to scan. It front-loads the purpose. While slightly lengthy, every sentence adds value, earning a score of 4.
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 presence of an output schema, the description does not need to detail return values. It covers purpose, usage guidelines, parameter semantics, and even mentions internet access. For a learning tool, it is comprehensive and well-rounded.
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?
With 0% schema description coverage, the description adds significant meaning by explaining the 'prompt' parameter as the question and the 'model' parameter as a Sonar model with options listed. It provides helpful context beyond the schema's basic type information.
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 purpose: 'Learn complex concepts with pedagogical explanations, examples, and analogies.' It uses a specific verb ('learn') and resource ('concepts'), and distinguishes itself from siblings like 'ask_perplexity' by emphasizing a teaching-optimized approach.
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 clear context for when to use this tool, stating it is 'teaching-optimized' and listing examples of good prompts. However, it does not explicitly state when not to use it or mention alternative tools, but the implied usage is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get examples of prompts and usage patterns for this Perplexity MCP server.
This tool helps you discover what you can do with this server and provides
concrete examples of effective prompts for each tool.
Returns:
Detailed examples and usage guide for all available tools
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 states the return value but does not disclose whether the tool is read-only, has side effects, or requires authentication. Adequate but minimal.
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?
Three concise sentences with no redundancies. The first sentence states the core purpose, the second adds context, and the third documents the return value. Well-structured and front-loaded.
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 simple tool with no parameters and no annotations, the description adequately explains what the tool does and returns. It could mention safety or that it's a discovery tool, but it is largely complete given the low complexity.
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 tool has zero parameters, so the baseline score is 4. The description appropriately adds no parameter information, as none is needed.
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 retrieves examples of prompts and usage patterns, distinguishing it from sibling tools that all perform queries. The verb 'Get' and resource 'examples' are specific and 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?
The description implies use when seeking examples or guidance on using the server. While it doesn't explicitly state when not to use it or provide alternatives, the context is clear given sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The four 'ask_perplexity_*' tools are differentiated by response style (general, exact, instructions, learning) with clear descriptions. The 'get_examples' tool is distinct. Some overlap between instructions and learning could cause minor ambiguity, but overall well-differentiated.
All primary tools follow a consistent 'ask_perplexity_<purpose>' pattern. 'get_examples' uses a different verb-noun structure, but as a utility tool, this deviation is minor and acceptable.
With 5 tools, the server is well-scoped for its purpose of querying Perplexity in different modes. Each tool earns its place without being excessive or insufficient.
The tool set covers a comprehensive range of use cases: general research, exact responses, step-by-step instructions, pedagogical learning, and an examples guide. No obvious gaps for the intended domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
Provides AI assistants with access to Seltz's powerful Web Search capabilities.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/0xHumban/perplexity-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
