MCP-researcher Server
The MCP-researcher Server acts as an intelligent research assistant powered by Perplexity AI models, offering various specialized tools for:
Quick information retrieval through
searchandget_documentationtoolsComplex reasoning tasks like comparisons and problem-solving via the
reasontoolIn-depth research on multifaceted topics using the
deep_researchtoolOngoing conversations with Perplexity AI through the
chat_perplexitytool with context awarenessAPI discovery and evaluation for project integration using the
find_apistoolCode maintenance by checking for deprecated code or dependencies
The server intelligently routes queries to appropriate models (Sonar Pro, Sonar Reasoning Pro, Sonar Deep Research) based on complexity, with search capabilities available across all tasks.
Utilizes Perplexity's Sonar Pro API to perform searches, get documentation, find APIs, and check deprecated code
Provides capabilities to retrieve React documentation and check for deprecated React patterns like class components
Uses SQLite for local chat history storage
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., "@MCP-researcher Serverresearch the latest developments in quantum computing and summarize the key breakthroughs"
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
An intelligent research assistant powered by Perplexity's specialized AI models. Features automatic query complexity detection to route requests to the most appropriate model for optimal results. Unlike the Official server, it has search capabilities FOR EVERY TASK, essentially
It also forces the agent using the MCP to be specific
Tools
1. Search (Sonar Pro)
Quick search for simple queries and basic information lookup. Best for straightforward questions that need concise, direct answers.
const result = await use_mcp_tool({
server_name: "perplexity",
tool_name: "search",
arguments: {
query: "What is the capital of France?",
force_model: false // Optional: force using this model even if query seems complex
}
});2. Reason (Sonar Reasoning Pro)
Handles complex, multi-step tasks requiring detailed analysis. Perfect for explanations, comparisons, and problem-solving.
const result = await use_mcp_tool({
server_name: "perplexity",
tool_name: "reason",
arguments: {
query: "Compare and contrast REST and GraphQL APIs, explaining their pros and cons",
force_model: false // Optional: force using this model even if query seems simple
}
});3. Deep Research (Sonar Deep Research)
Conducts comprehensive research and generates detailed reports. Ideal for in-depth analysis of complex topics.
const result = await use_mcp_tool({
server_name: "perplexity",
tool_name: "deep_research",
arguments: {
query: "The impact of quantum computing on cryptography",
focus_areas: [
"Post-quantum cryptographic algorithms",
"Timeline for quantum threats",
"Practical mitigation strategies"
],
force_model: false // Optional: force using this model even if query seems simple
}
});Related MCP server: github-manager MCP Server
Setup
Prerequisites
Node.js (from nodejs.org)
Perplexity API key (from perplexity.ai/settings/api)
clone the repo somewhere
Configure MCP Settings
Add to your MCP settings file (location varies by platform):
{
"mcpServers": {
"perplexity": {
"command": "node",
"args": ["/path/to/perplexity-server/build/index.js"],
"env": {
"PERPLEXITY_API_KEY": "YOUR_API_KEY_HERE"
},
"disabled": false,
"autoApprove": []
}
}
}Or use NPX to not have to install it locally (recommended for macos):
{
"mcpServers": {
"perplexity": {
"command": "npx",
"args": [
"-y",
"perplexity-mcp"
],
"env": {
"PERPLEXITY_API_KEY": "your_api_key"
}
}
}
}In case the MCP Client is not able to parse the Perplexity API Key from the
environment using methods like "${env:PERPLEXITY_API_KEY}" common in modern
AI Coding Agents (e.g. Kiro), there are two fallback solutions:
Command-Line Argument: Pass the API key directly as a command-line argument, and you can even try to see whether "${env:PERPLEXITY_API_KEY}" works in there.
{
"mcpServers": {
"perplexity": {
"command": "node",
"args": [
"/path/to/perplexity-server/build/index.js",
"--api-key",
"your_api_key_here"
],
"disabled": false,
"autoApprove": []
}
}
}Read an explicit .env File: specify the location of the project .env file with the environment variables and API keys for your current project with the --cwd command-line argument, and the MCP Server will read the .env file from the directory finding the Perplexity API Key from there.
{
"mcpServers": {
"perplexity": {
"command": "node",
"args": [
"/path/to/perplexity-server/build/index.js",
"--cwd",
"/path/to/your/project"
],
"disabled": false,
"autoApprove": []
}
}
}Priority Order: Command-line argument > Environment variable > .env file with --cwd (path needed)
Star History
Available Tools
3 toolsdeep_researchB
Conducts in-depth analysis and generates detailed reports using Perplexity's Sonar Deep Research model. Best for comprehensive research topics.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The research topic or question to investigate in depth. IMPORTANT: Be extremely specific and include all relevant details: - Include exact error messages, logs, and stack traces if applicable - Provide exact terminology, function names, API names, version numbers - Include relevant code snippets showing the problem or context - Specify platform, OS, framework versions, and environment details - Mention any attempted solutions or workarounds - Provide context about what you're trying to achieve - Include relevant data structures, configurations, or inputs - Specify the scope, constraints, or specific requirements The more specific details you include, the more accurate and helpful the answer will be. If you don't have enough specific information, prompt the user to provide it before using this tool. | |
| focus_areas | No | Optional: Specific aspects or areas to focus on | |
| force_model | No | Optional: Force using this model even if query seems simple |
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 of behavioral disclosure. It mentions the tool uses 'Perplexity's Sonar Deep Research model' and is for 'comprehensive research topics,' but it lacks details on behavioral traits such as response format, potential rate limits, authentication needs, or whether it's a read-only or mutative operation. The description doesn't contradict annotations, but it's insufficient for a tool with no annotation coverage.
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 appropriately sized and front-loaded, consisting of two concise sentences that directly state the tool's purpose and usage context. There's no wasted text, and it efficiently conveys key information without unnecessary elaboration.
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 (3 parameters, no annotations, no output schema), the description is moderately complete. It covers the purpose and hints at usage but lacks details on behavioral traits, output format, and differentiation from siblings. The high schema coverage helps, but for a research tool with no output schema, more context on what to expect from results would be beneficial.
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 description coverage is 100%, so the input schema already documents all parameters thoroughly. The description adds no additional meaning beyond what the schema provides—it doesn't explain parameter interactions or usage nuances. With high schema coverage, the baseline score is 3, as the description doesn't compensate but also doesn't detract.
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: 'Conducts in-depth analysis and generates detailed reports using Perplexity's Sonar Deep Research model.' It specifies the verb ('conducts analysis and generates reports'), resource ('Perplexity's Sonar Deep Research model'), and scope ('comprehensive research topics'). However, it doesn't explicitly differentiate from sibling tools 'reason' and 'search' beyond mentioning it's 'best for comprehensive research topics,' which is somewhat vague.
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 some guidance: 'Best for comprehensive research topics.' This implies usage for complex or broad inquiries, but it doesn't explicitly state when to use this tool versus alternatives like 'reason' or 'search,' nor does it mention any exclusions or prerequisites. The input schema hints at usage context by emphasizing specificity, but this isn't part of the description itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reasonA
Handles complex, multi-step tasks using Perplexity's Sonar Reasoning Pro model. Best for explanations, comparisons, and problem-solving.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The complex query or task to reason about. IMPORTANT: Be extremely specific and include all relevant details: - Include exact error messages, logs, and stack traces if applicable - Provide exact terminology, function names, API names, version numbers - Include relevant code snippets showing the problem or context - Specify platform, OS, framework versions, and environment details - Mention any attempted solutions or workarounds - Provide context about what you're trying to achieve - Include relevant data structures, configurations, or inputs The more specific details you include, the more accurate and helpful the answer will be. If you don't have enough specific information, prompt the user to provide it before using this tool. | |
| force_model | No | Optional: Force using this model even if query seems simple/research-oriented |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions using 'Perplexity's Sonar Reasoning Pro model' and hints at complexity handling, but lacks details on performance traits (e.g., latency, rate limits), error handling, or output format. It adds some context but falls short of fully describing behavioral aspects for a tool with no annotations.
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 extremely concise and front-loaded, consisting of two sentences that directly state the tool's purpose and best-use cases. Every sentence earns its place by providing essential information without waste, making it easy to parse and understand quickly.
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 has no annotations and no output schema, the description is incomplete. It covers purpose and usage well but lacks details on behavioral traits, output format, or error handling. For a tool with 2 parameters and no structured metadata, the description should do more to compensate, leaving gaps in contextual understanding.
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 both parameters thoroughly. The description does not add specific parameter semantics beyond what's in the schema, but since coverage is high, the baseline is 3. It earns a 4 because the description implicitly reinforces the importance of the 'query' parameter by emphasizing complex tasks, adding slight contextual value without redundancy.
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 'handles complex, multi-step tasks' using a specific reasoning model, with examples of use cases (explanations, comparisons, problem-solving). It distinguishes from 'deep_research' and 'search' by emphasizing reasoning over research or simple search, though not explicitly naming alternatives. The purpose is specific but could be more explicit about sibling differentiation.
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 ('Best for explanations, comparisons, and problem-solving'), implying it's suited for complex reasoning tasks. However, it does not explicitly state when not to use it or name alternatives like 'deep_research' or 'search', missing explicit exclusions or comparisons. The guidance is strong but not fully comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchA
Quick search for simple queries using Perplexity's Sonar Pro model. Best for straightforward questions and basic information lookup.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search query or question. IMPORTANT: Be extremely specific and include all relevant details: - Include exact error messages, logs, and stack traces if applicable - Provide exact terminology, function names, API names, version numbers - Include relevant code snippets showing the problem or context - Specify platform, OS, framework versions, and environment details - Mention any attempted solutions or workarounds - Provide context about what you're trying to achieve The more specific details you include, the more accurate and helpful the answer will be. If you don't have enough specific information, prompt the user to provide it before using this tool. | |
| force_model | No | Optional: Force using this model even if query seems complex |
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 of behavioral disclosure. It mentions the model (Sonar Pro) and that it's for 'quick search,' but lacks details on rate limits, authentication needs, response format, or error handling. For a search tool with zero annotation coverage, this is a significant gap in transparency.
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 two sentences, front-loaded with the core purpose and usage guidelines. Every word earns its place, with no redundancy or fluff. It's appropriately sized for a simple search tool.
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 low complexity (2 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers purpose and usage but lacks behavioral details (e.g., response format, limitations). Without annotations or output schema, the description should do more to compensate, but it's minimally viable.
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 fully documents the two parameters. The description doesn't add any parameter-specific information beyond what's in the schema. According to the rules, with high schema coverage (>80%), the baseline is 3 even with no param info in the description.
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: 'Quick search for simple queries using Perplexity's Sonar Pro model.' It specifies the action (search), the resource (information via Sonar Pro model), and the scope (simple queries, basic information lookup). However, it doesn't explicitly differentiate from its siblings 'deep_research' and 'reason' beyond implying simplicity vs. complexity.
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 usage context: 'Best for straightforward questions and basic information lookup.' This implies when to use it (simple queries) and when not to use it (complex queries, which might be handled by siblings like 'deep_research' or 'reason'). However, it doesn't explicitly name alternatives or state exclusions, keeping it at a 4.
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.
3 tool updates
v1.0.0- First observed
deep_research - First observed
reason - First observed
search
TDQS
Each tool has a clearly distinct purpose: deep_research for comprehensive analysis, reason for multi-step reasoning tasks, and search for basic queries. The descriptions explicitly differentiate their use cases, eliminating any ambiguity or overlap in functionality.
All tool names follow a consistent snake_case pattern with clear, descriptive verbs (deep_research, reason, search). There are no deviations in naming style, making the set predictable and easy to understand.
With only 3 tools, the set feels thin for a research server, potentially limiting coverage of common research workflows like summarization, citation management, or data extraction. However, the tools are well-scoped to core research tasks, avoiding bloat.
The tools cover basic research functions (deep analysis, reasoning, quick search), but there are notable gaps such as no tools for summarizing, filtering results, or handling citations. This may cause agents to work around missing operations in complex research scenarios.
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
Google Keep-style notes app with an MCP server for AI agents to read/write notes.
Markdown-based note-taking with a hosted MCP server. Your notes serve you and your AI.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
An MCP server that used to create notes
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceThis TypeScript-based MCP server enables users to manage and summarize text notes, providing tools for note creation and summarization prompts.4,78510MIT
- AlicenseNot gradedqualityNot gradedmaintenanceThis TypeScript-based MCP server enables users to manage a simple notes system with capabilities to create and summarize notes through structured prompts and resources.1-
- AlicenseNot gradedqualityDmaintenanceThis TypeScript-based server implements a simple notes system, allowing users to create and manage text notes and generate summaries, showcasing core MCP concepts.2016Apache 2.0
- AlicenseNot gradedqualityDmaintenanceThis TypeScript-based MCP server allows users to manage a simple notes system through creating and summarizing text notes using Model Context Protocol (MCP).2,0138MIT
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/DaInfernalCoder/perplexity-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server