Perplexity MCP Server

by wysh3

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation3/5
The tools have distinct primary purposes (e.g., chat, code review, content extraction, API discovery, documentation lookup, general search), but there is some functional overlap. For instance, 'chat_perplexity' and 'search' both perform web searches, and 'find_apis' and 'get_documentation' both relate to API information, which could cause confusion for an agent in selecting the most appropriate tool for a given task.
Naming Consistency4/5
Most tool names follow a consistent verb_noun pattern (e.g., 'extract_url_content', 'find_apis', 'get_documentation', 'check_deprecated_code'), which aids readability. However, 'chat_perplexity' deviates slightly by using a noun_verb structure, and 'search' is a standalone verb without a noun, creating minor inconsistencies in the naming convention.
Tool Count5/5
With 6 tools, the count is well-scoped for a server focused on web-based information retrieval and code assistance. Each tool appears to serve a specific function within this domain, avoiding bloat while covering key areas like conversation, search, content extraction, and technical support, making the set manageable and purposeful.
Completeness4/5
The tool set covers a broad range of web interaction and code-related tasks, including conversational search, content extraction, API discovery, documentation access, and code review. A minor gap exists in lacking explicit tools for updating or managing retrieved information (e.g., saving or organizing results), but agents can likely work around this using the provided tools effectively for most workflows.
Average 3.6/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 2 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under GPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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 'real-time information' and 'maintains conversation history,' but lacks details on behavioral traits like rate limits, authentication needs, error handling, or what 'interactive' entails. This is insufficient for a tool with web search and chat capabilities.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with two sentences that efficiently convey the main purpose and key features. There's no wasted text, though it could be slightly more structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (web search with chat history), no annotations, and an output schema (which handles return values), the description is moderately complete. It covers the core functionality but misses important behavioral aspects like limitations or prerequisites, making it adequate but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 adds no additional meaning beyond what's in the schema (e.g., it doesn't explain parameter interactions or usage nuances), meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'call this tool for interactive, conversational queries' and 'leverages Perplexity's web search capabilities to provide real-time information.' It specifies the verb (call for queries) and resource (Perplexity's web search), though it doesn't explicitly distinguish from sibling tools like 'search' or 'extract_url_content'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context: 'for interactive, conversational queries' and 'maintains conversation history,' which implies when to use it (for chat-like interactions). However, it doesn't explicitly state when not to use it or mention alternatives among sibling tools, leaving gaps in guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 'compares options based on requirements', which adds some context about its behavior. However, it lacks details on how the comparison works, what sources it uses, whether it requires authentication, rate limits, or what the output looks like. For a tool that interacts with web data, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, consisting of two sentences: one stating the purpose and usage, and another providing a concrete example. Each sentence adds value without redundancy. It could be slightly improved by front-loading key information more explicitly, but overall it's efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is an output schema (which reduces the need to describe return values in the description), no annotations, and high schema coverage, the description is moderately complete. It covers the basic purpose and usage but lacks details on behavioral aspects like data sources, comparison methodology, and limitations. For a tool that fetches and compares web data, more context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for both parameters ('requirement' and 'context'), including examples. The description adds minimal value beyond the schema, as it doesn't provide additional syntax, format details, or usage nuances for the parameters. The baseline score of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to find external services or real-time data from the web by comparing options based on requirements. It provides a specific example (shopping site scenario) that illustrates the verb 'find' and resource 'APIs'. However, it doesn't explicitly distinguish this tool from sibling tools like 'search' or 'get_documentation', which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage guidance by stating 'Automatically call this tool when needing external services or real time current data' and giving an example scenario. This implies when to use it, but it doesn't explicitly differentiate it from alternatives like 'search' or 'chat_perplexity', nor does it specify when NOT to use it. The guidance is helpful but incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 performs a web search and is useful for certain purposes, but fails to disclose critical behavioral traits like whether it requires authentication, has rate limits, returns structured data, or handles errors. This leaves significant gaps for an agent to understand operational constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences that are front-loaded with the core action. The first sentence states the purpose clearly, and the second adds context without redundancy. However, the second sentence could be slightly more precise, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which covers return values), no annotations, and high schema coverage, the description is moderately complete. It explains the basic purpose and usage context but lacks behavioral details like authentication needs or error handling, which are important for a search tool with no annotation support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 (query, detail_level, stream) thoroughly. The description adds minimal value beyond the schema by mentioning 'desired detail level' and implying the query's purpose, but doesn't provide additional syntax, format, or usage details. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a 'web search using Perplexity AI' with a specific query and detail level, which distinguishes it from siblings like 'chat_perplexity' or 'extract_url_content'. However, it doesn't explicitly differentiate from 'find_apis' or 'get_documentation' for information-finding tasks, keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidelines by stating it's 'useful for general knowledge questions, finding information, or getting different perspectives', which suggests when to use it. However, it lacks explicit when-not-to-use guidance or named alternatives among siblings, such as when to prefer 'chat_perplexity' for conversational queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 'real time web access,' hinting at external data fetching, but doesn't disclose key behavioral traits such as whether it's read-only, if it makes network calls, potential rate limits, or what the output looks like. This is inadequate for a tool that likely interacts with external sources.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences that directly address usage and purpose. It's front-loaded with key scenarios, though the second sentence could be more tightly integrated to avoid slight redundancy in examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, 100% schema coverage, and an output schema exists), the description is reasonably complete. It covers usage contexts well, and since an output schema is present, it doesn't need to explain return values, though it could benefit from more behavioral details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 ('code' and 'technology') with descriptions and examples. The description doesn't add any meaning beyond what the schema provides, such as explaining how parameters interact or their impact on results, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Helps identify technical debt' through checking deprecated code. It specifies the action ('identify') and resource ('technical debt'), though it doesn't explicitly differentiate from sibling tools like 'find_apis' or 'get_documentation' which might also relate to code analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'when reviewing legacy code, planning upgrades, or encountering warnings with real time web access.' It includes specific scenarios like 'During code reviews or before upgrading dependencies,' which clearly defines the context without mentioning alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 that the tool 'can access web,' which is a useful behavioral trait. However, it doesn't mention other important aspects like rate limits, authentication needs, response format, or potential costs. The description adds some value but leaves significant behavioral gaps uncovered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences. The first sentence front-loads the purpose and usage guidelines, and the second provides a concrete example. There's minimal waste, though the phrasing could be slightly more concise (e.g., 'Automatically call this tool' is redundant with the tool name).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no annotations, but has an output schema), the description is reasonably complete. It covers purpose and usage well, and the output schema exists, so the description doesn't need to explain return values. However, it lacks details on behavioral traits like web access limitations or error handling, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 ('query' and 'context') with descriptions and examples. The description doesn't add any parameter-specific semantics beyond what the schema provides. According to the rules, with high schema coverage, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Automatically call this tool when working with unfamiliar APIs/libraries, needing usage examples, or checking version specifics as this can access web.' It specifies the verb ('get documentation') and resource ('APIs/libraries'), but doesn't explicitly differentiate from sibling tools like 'find_apis' or 'search' which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines: 'when working with unfamiliar APIs/libraries, needing usage examples, or checking version specifics.' It includes a concrete example ('When adding a payment gateway, ask "Get Stripe API documentation for creating charges"') that illustrates when to use this tool. No explicit alternatives are named, but the context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so effectively. It discloses key behavioral traits: uses browser automation and Readability library, handles JavaScript rendering, includes fallback logic, special handling for GitHub URLs, performs pre-checks for content types and HTTP status, and notes limitations with complex pages. This covers technical implementation, error handling, and edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose in the first sentence. Each subsequent sentence adds valuable information (technologies, special cases, checks, ideal use, limitations). There is minimal waste, though it could be slightly more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (dynamic content extraction, fallback logic, GitHub handling) and the presence of an output schema (which means return values are documented elsewhere), the description is complete enough. It covers purpose, technology, behavior, use cases, and limitations without needing to repeat structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 (url and depth) thoroughly. The description does not add any additional meaning about parameters beyond what the schema provides, such as explaining how depth affects recursive exploration in practice. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'extract the main article text content from a given URL' using specific technologies (Puppeteer and Mozilla's Readability). It distinguishes from siblings by focusing on content extraction rather than chat, code analysis, API discovery, documentation retrieval, or general search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 it ('Ideal for getting clean text from articles/blog posts') and includes a note about limitations ('May struggle... on complex homepages or dashboards'). However, it does not explicitly mention when NOT to use it or name specific alternatives among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![perplexity-mcp-zerver MCP server](https://glama.ai/mcp/servers/wysh3/perplexity-mcp-zerver/badges/card.svg)](https://glama.ai/mcp/servers/wysh3/perplexity-mcp-zerver)

Score Badge

Copy to your README.md:

[![perplexity-mcp-zerver MCP server](https://glama.ai/mcp/servers/wysh3/perplexity-mcp-zerver/badges/score.svg)](https://glama.ai/mcp/servers/wysh3/perplexity-mcp-zerver)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/wysh3/perplexity-mcp-zerver'

If you have feedback or need assistance with the MCP directory API, please join our Discord server