Provides real-time web search and academic research capabilities using Perplexity's Sonar API.
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 Web-Search MCP search for latest AI 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.
Supercharge your AI assistant with real-time web search and academic research capabilities
An MCP (Model Context Protocol) server that integrates Perplexity's powerful Sonar API, giving your AI assistant access to current information from the web and scholarly sources.
š Real-time web search - Get current information from across the internet
š Academic search - Access peer-reviewed papers and scholarly sources
š Location-aware results - Filter by city and country
ā° Time-filtered search - Get recent results (day, week, etc.)
š§ Multiple AI models - Choose from various Perplexity Sonar models
š Universal compatibility - Works with any MCP-compatible system
Related MCP server: Perplexity API Platform MCP Server
This MCP server works seamlessly with:
Claude
Amazon Q
Google Gemini
OpenAI Codex
Any MCP-compatible AI assistant
Here's how to properly integrate this MCP server with Amazon Q Developer:
~/.aws/amazonq/cli-agents/dev.json{
"$schema": "https://raw.githubusercontent.com/aws/amazon-q-developer-cli/refs/heads/main/schemas/agent-v1.json",
"name": "dev",
"description": "",
"mcpServers": {
"sonar": {
"command": "/Users/your-username/SoftwareProjects/perplexity_sonar_mcp/.venv/bin/python",
"args": ["/Users/your-username/SoftwareProjects/perplexity_sonar_mcp/main.py"],
"cwd": "/Users/your-username/SoftwareProjects/perplexity_sonar_mcp",
"env": {
"PERPLEXITY_API_KEY": "pplx-your-api-key-here"
}
}
},
"tools": [
"fs_read",
"fs_write",
"execute_bash",
"use_aws",
"@sonar"
]
}[dev] > Web search: "Is AI a bubble?"
š ļø Using tool: web_search from mcp server sonar
ā®
ā Running web_search with the param:
ā® {
ā® "name": "web_search",
ā® "arguments": {
ā® "query": "Is AI a bubble?"
ā® }
ā® }
Allow this action? Use 't' to trust (always allow) this tool for the session. [y/n/t]: y
ā®
ā Completed in 9.990s
> Based on current market analysis, AI is widely considered to be in a bubble phase...uv syncpip install -e .Add to your MCP client configuration:
With uv:
Transport Type: STDIO
Command: uv
Arguments: run main.py
With Python:
Transport Type: STDIO
Command: python
Arguments: main.py
Set your Perplexity API key:
export PERPLEXITY_API_KEY="your-api-key-here"uv run python main.pypython main.pyPython >=3.10
PERPLEXITY_API_KEY environment variable
web_searchSearch the web using Perplexity Sonar API for real-time information.
Parameters:
query (required): The search query or question
model (optional): Perplexity model - "sonar", "sonar-pro", "sonar-deep-research", "sonar-reasoning", "sonar-reasoning-pro" (default: "sonar")
recency_filter (optional): Time filter for results (e.g., 'week', 'day')
city (optional): City name for location-based search
country (optional): Two letter ISO country code
web_search_academicSearch academic sources using Perplexity Sonar API for scholarly information. Prioritizes peer-reviewed papers and academic journals.
Parameters:
query (required): The search query or question
model (optional): Perplexity model - "sonar", "sonar-pro", "sonar-deep-research", "sonar-reasoning", "sonar-reasoning-pro" (default: "sonar")
recency_filter (optional): Time filter for results (e.g., 'week', 'day')
city (optional): City name for location-based search
country (optional): Two letter ISO country code
Set your Perplexity API key:
export PERPLEXITY_API_KEY="your-api-key-here"Search the web using Perplexity Sonar API for real-time information.
Args:
query: The search query or question to ask Perplexity
model: The Perplexity model to use. Options: "sonar", "sonar-pro",
"sonar-deep-research", "sonar-reasoning", "sonar-reasoning-pro"
(default: "sonar")
recency_filter: Time filter for results (e.g., 'week', 'day')
city: City name for location-based search
country: Two letter ISO country code
Returns:
str: The search results and answer from Perplexity API
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| model | No | sonar | |
| recency_filter | No | ||
| city | No | ||
| country | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It states 'real-time information' but does not disclose rate limits, response format details, error handling, or any side effects. The tool is likely read-only but this is not confirmed.
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 with the main action. Parameters are listed clearly with brief explanations. No wasted words. However, it mixes parameter descriptions with return type in a non-standard format (Args/Returns), which is acceptable but slightly less structured than ideal.
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 5 parameters (1 required) and an output schema (string), the description covers all params minimally. It lacks usage examples, failure behaviors, or differentiation from sibling. For a simple search tool, it is adequate but not comprehensive. The lack of annotations increases the need for more context.
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 briefly explains each parameter: query, model (with enum options), recency_filter (example 'week'), city, country. For model, it list options already in schema but adds default value. Other parameters have minimal explanation; recency_filter and city/country lack examples beyond 'week' and 'day'. Adds some value but could be more detailed.
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: 'Search the web using Perplexity Sonar API for real-time information.' It uses specific verbs and resources. However, it does not differentiate from the sibling tool 'web_search_academic', leaving ambiguity about which to use for general vs. academic queries.
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 no explicit guidance on when to use this tool versus alternatives. It does not mention when to choose web_search over web_search_academic or any prerequisites. Usage context is only implied by the tool's name and general purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search academic sources using Perplexity Sonar API for scholarly information.
Args:
query: The search query or question to ask Perplexity
model: The Perplexity model to use. Options: "sonar", "sonar-pro",
"sonar-deep-research", "sonar-reasoning", "sonar-reasoning-pro"
(default: "sonar")
recency_filter: Time filter for results (e.g., 'week', 'day')
city: City name for location-based search
country: Two letter ISO country code
Returns:
str: The search results from academic sources via Perplexity API
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| model | No | sonar | |
| recency_filter | No | ||
| city | No | ||
| country | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but only states it uses an external API. It omits critical details such as rate limits, authentication requirements, cost implications, or what happens if the API fails. The mention of models is present but lacks context on how they differ behaviorally.
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 follows a clean docstring format with Args and Returns sections. It is well-organized and reasonably concise, though the Args list partially duplicates schema information. Every sentence adds value, but the structure could be slightly tighter.
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 (avoiding need to detail returns), the description covers core purpose and parameters. However, it lacks guidance on usage context versus the sibling tool and omits behavioral transparency, leaving gaps for a tool that invokes an external API.
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?
Despite 0% schema description coverage, the description meaningfully explains each parameter. It lists query, model with options, recency_filter with examples, and city/country with their purpose. However, 'recency_filter' only gives examples without specifying exact accepted values, and the role of city/country in search could be clearer.
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 it searches academic sources using the Perplexity Sonar API for scholarly information. The verb 'search' and specific resource 'academic sources' provide a concrete purpose, and the explicit mention of the API distinguishes it from the sibling tool 'web_search'.
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 no guidance on when to use this tool versus the sibling 'web_search'. It does not mention alternative tools, prerequisites, or scenarios where this tool is preferred over a general web search.
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.
v0.1.0web_searchweb_search_academicThe two tools are clearly distinct: one for general web search and one for academic sources. Their purposes do not overlap.
Both tools follow a consistent 'web_search' prefix, with '_academic' clearly indicating the variant. The naming pattern is uniform.
Only 2 tools for a web search MCP seems too few for comprehensive coverage. Most search APIs have more specialized endpoints (news, images, etc.) or additional functionalities.
The set covers only general and academic search. Missing obvious categories like news, image, or video search, and lacks any result handling or refinement tools.
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
Provides AI assistants with access to Seltz's powerful Web Search capabilities.
Search Google straight from your AI agent. Web results, images, videos, news, products, scholarly ar
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/lv042/perplexity-web-search-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
