Perplexity Web MCP

by devdotbo

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.10.7
Disambiguation3/5
Many model-specific query tools (e.g., pplx_gpt54, pplx_sonar) and general query tools (pplx_ask, pplx_query, pplx_smart_query) have overlapping purposes. Descriptions attempt to differentiate them, but the large number of similar tools increases the chance of misselection.
Naming Consistency3/5
The 'pplx_' prefix is consistent, but naming conventions vary: some use verb_noun (pplx_ask, pplx_query), others are model names (pplx_gpt54) or descriptive (pplx_deep_research). The mix is readable but lacks a uniform pattern.
Tool Count3/5
23 tools is on the higher side for the apparent scope. While many are needed for different models and modes, the count feels slightly heavy and could be streamlined by combining model-specific tools into parameterized versions.
Completeness4/5
The tool set covers authentication, usage checking, source listing, and a variety of query types (quick, standard, deep research, council). No major gaps are apparent for interacting with Perplexity AI's capabilities.
Average 3.2/5 across 23 of 23 tools scored. Lowest: 1.3/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 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 MIT License.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose behavioral traits like safety, rate limits, or side effects. Only mentions model name and cost.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely short but wastes first sentence on a non-functional model label. Not efficient or informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists but description provides no context about return values, prerequisites, or usage. Highly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%; description adds no meaning to the two parameters (query, source_focus).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description names the model but does not explicitly state the tool's action (e.g., 'performs a search query'). It fails to distinguish from siblings like pplx_ask or pplx_smart_query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Cost is mentioned but not decision context.
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 exist. The description notes 'COSTS 1 PRO SEARCH QUERY', which is a useful behavioral detail about cost, but fails to disclose mutation, side effects, response characteristics, or safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but under-specified. It omits critical information, making it not concise in a useful sense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters, no schema descriptions, and an output schema without return details, the description is wholly inadequate for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no explanation of the two parameters (query, source_focus). An agent cannot infer parameter meaning or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description identifies the model as 'GPT-5.4 — OpenAI's versatile model' but lacks an action verb (e.g., query, generate). It does not specify what the tool does, making it vague compared to siblings like pplx_query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as pplx_gpt55 or pplx_gpt54_thinking. No mention of context or exclusion criteria.
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?
With no annotations, the description fails to disclose key behaviors such as whether the tool reads or modifies data, what the output looks like, or any side effects. The cost note is the only behavioral insight, but it does not compensate for the lack of basic action description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is very short, it sacrifices essential information for brevity. It is under-specified rather than concise, missing core functional details and parameter semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 parameters, output schema, numerous siblings), the description is severely incomplete. It does not explain the tool's operation, return values, or how it differs from similar tools, failing to provide a complete picture for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description provides no explanation of the two parameters ('query' and 'source_focus'). The agent receives no hints about what these parameters do, leaving the schema to bear the full burden. This is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as 'Claude Sonnet 4.6 — Anthropic's fast model' but does not explicitly state that the tool performs a search query. The mention 'COSTS 1 PRO SEARCH QUERY' implies a search action, but the core purpose (verb+resource) is missing, making it vague compared to siblings like pplx_ask or pplx_query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus siblings. The cost indication (1 PRO SEARCH QUERY) hints at a constraint, but there is no context-explaining preference for this model over pplx_claude_opus or pplx_claude_sonnet_think.
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?
With no annotations, the description carries the full burden. It mentions cost but does not disclose behavioral traits like response speed, output format, or limitations of extended thinking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one line), but it sacrifices necessary details. It is front-loaded with the model name and cost, but is too brief overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters, a non-empty output schema, and many siblings, the description is severely incomplete. It does not differentiate this tool from closely related ones like pplx_gpt54 or cover expected input usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the meaning or usage of 'query' or 'source_focus'. The agent receives no help beyond the parameter names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as a model with extended thinking and mentions cost, but does not explicitly state the action it performs (e.g., generate responses, answer queries). It gives a general idea but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus the many sibling tools (e.g., pplx_gpt54, pplx_gpt55_thinking). The description fails to provide selection criteria.
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?
With no annotations, the description must disclose key behaviors. It only notes usage counters and plan dependence, omitting what the tool actually does (e.g., search, return citations) and any side effects. The reference to 'pplx_usage' is helpful but incomplete.
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 extremely concise (one sentence) and front-loaded with the model name. However, the brevity sacrifices clarity; it is under-specified rather than efficiently complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters and no annotations, the description fails to cover essential aspects like query behavior, source_focus options, or return format. The output schema exists but is not referenced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 2 parameters with zero description coverage, and the tool description adds no meaning to 'query' or 'source_focus'. An agent cannot infer the expected format or effect of these parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as 'Perplexity's latest in-house model' but does not state the specific verb or resource (e.g., search, generate, answer). It fails to differentiate from siblings like 'pplx_query' or 'pplx_deep_research', which have clearer purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only mentions plan and usage counters, which is not sufficient for an agent to decide between this and other Perplexity tools.
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?
With no annotations, the description must cover behavioral traits. It only mentions cost and 'extended thinking', omitting details like output format, thinking trace presence, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences) but the first sentence nearly repeats the name. It could be more concise by front-loading core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (extended thinking, output schema), the description lacks completeness. It mentions no return values, requirements, or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds no meaning to the parameters. It does not explain 'query' or 'source_focus' beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the model and mentions 'extended thinking' but lacks an explicit verb stating the tool's action. It implies generating responses with thinking but is not as specific as needed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like pplx_kimi_k26. The description provides no context for selection criteria.
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 provided, so description carries full burden. It discloses cost (COSTS 1 PRO SEARCH QUERY) but lacks other behaviors such as response format, latency, or limitations.
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?
Two sentences, no waste. However, the first sentence could front-load the action rather than just naming the model.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (extended thinking model, many siblings, parameters), the description is too minimal. Lacks usage context, parameter details, and behavioral traits beyond cost.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 2 parameters with 0% description coverage. The tool description does not explain what 'query' or 'source_focus' mean or how to use them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description names the model and mentions 'extended thinking,' implying reasoning, but doesn't explicitly state the action (e.g., 'generate a response'). Distinction from siblings like pplx_query is unclear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives or when not to use it. With many sibling tools, this omission hinders correct selection.
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?
With no annotations provided, the description must disclose behavioral traits. It mentions 'extended thinking' but does not explain what that entails (e.g., slower responses, deeper reasoning). It fails to state output behavior or side effects, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, with no wasted words. However, it lacks necessary information, so conciseness comes at the cost of completeness. It is appropriately sized but not fully effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, multiple siblings, and absence of annotations, the description is severely incomplete. It does not explain the tool's action, output, or differentiation, leaving the agent with insufficient context to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not mention the two parameters (query, source_focus). The description must compensate but provides no parameter semantics, leaving the agent without guidance on how to fill the parameters.
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 identifies the tool as Claude Opus 4.7 Thinking, a reasoning model with extended thinking. It conveys the purpose of generating advanced responses, though it does not explicitly differentiate from sibling think tools like pplx_claude_sonnet_think.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides cost and subscription requirements but offers no guidance on when to use this tool versus alternatives such as pplx_claude_opus or pplx_claude_sonnet_think. There is no mention of when to prefer this tool or when not to use it.
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?
With no annotations provided, the description must fully convey behavioral traits. It mentions 'extended thinking' and cost but omits whether the tool is read-only, requires authentication, modifies data, or how it behaves in error cases. The output format is not described despite the presence of an output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (one sentence) but combines two distinct pieces of information (model identity, cost). It is not front-loaded with the most critical information for tool selection. A slightly more structured approach would improve clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 (not shown) and moderate complexity (2 parameters, sibling variety), the description is insufficient. It lacks parameter semantics, usage context, and behavioral details, failing to equip the agent for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameter meaning. It does not mention the `query` parameter or the `source_focus` parameter, leaving the agent without any guidance on how to set these values correctly.
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 identifies the model (Gemini 3.1 Pro Thinking) and notes its capability (extended thinking) and cost. However, it lacks a verb specifying the tool's primary action (e.g., 'answer', 'generate') and does not distinguish it from similar sibling tools like pplx_ask or pplx_smart_query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention scenarios, exclusions, or prerequisites, leaving the agent without context to decide between pplx_gemini_pro_think and other query or thinking tools.
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 provided, so description bears full burden. Only discloses cost and subscription; lacks information on behavior (e.g., what happens on success/failure, data handling, rate limits). Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, front-loaded with model name. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given tool has 2 params and output schema exists, description still misses core purpose and parameter context. Agent cannot infer what the tool actually does (e.g., generate text) or how to use parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 2 parameters with 0% description coverage, and the description adds no information about parameters. Does not explain 'query' or 'source_focus' meaning, default, or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as GPT-5.5 model and mentions cost and subscription, but does not explicitly state the verb (e.g., 'generate', 'query') or differentiate from siblings like pplx_gpt54. Purpose is implied but not clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides cost and subscription requirement, which gives some context, but no guidance on when to use this versus alternative models (e.g., pplx_claude_opus). No mention of when not to use or prerequisites beyond subscription.
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 the cost and subscription requirement, which is useful. However, it omits other critical behaviors such as rate limits, statelessness, output format details (despite output schema existing), or whether the tool has side effects beyond consuming credits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (two sentences) but at the expense of missing critical details like parameter guidance and usage context. It is front-loaded with key identity and cost info, but overall it is underestimed rather than optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of schema descriptions and annotations, the description fails to provide complete context. While an output schema exists, the absence of parameter semantics, usage guidelines, and behavioral transparency makes the tool definition inadequate for confident selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter descriptions exist. The tool description does not explain the 'query' parameter (e.g., what constitutes a valid query) nor the 'source_focus' parameter (its purpose or allowed values). This leaves the agent without sufficient semantic understanding of the inputs.
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 identifies the tool as GPT-5.5 Thinking, a model with extended thinking, and distinguishes it by noting a cost of 1 PRO SEARCH QUERY and a Max subscription requirement. However, it does not explicitly state the tool's primary function (e.g., reasoning, research) beyond 'thinking', which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The mention of 'extended thinking' implies it is for complex reasoning, but there is no mention of when not to use it or comparisons to sibling tools like pplx_gpt55, which likely offers faster or cheaper responses.
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?
The description mentions 'extended thinking' and cost, but does not detail behavioral traits like response length, rate limits, or how thinking mode affects output. With no annotations, the description carries full burden and falls short.
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 a single, focused sentence with a key cost note. It is free of redundancy, though slightly more structure (e.g., bullet points) could improve readability without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 and a complex thinking model, the description should clarify what 'extended thinking' means for output (e.g., chain-of-thought, reasoning steps). It lacks sufficient context for an agent to fully understand tool behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of the 'query' or 'source_focus' parameters. The description fails to add meaning beyond the trivial schema, leaving agents uninformed about parameter usage.
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 identifies the tool as Claude Sonnet 4.6 with extended thinking and specifies its cost. The name and title further reinforce the model identity, distinguishing it from non-thinking siblings like pplx_claude_sonnet.
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 implies use for extended thinking tasks via the 'thinking' label and cost mention, but lacks explicit guidance on when to choose this over alternatives (e.g., pplx_claude_sonnet, pplx_gpt55_thinking). No when-not-to-use or alternative references.
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?
With no annotations provided, the description carries the full burden. It discloses important behavioral traits: the tool consumes a PRO SEARCH QUERY and requires a Max subscription. This adds transparency beyond the schema, though it omits details about idempotency or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence plus a billing note. It is front-loaded with the model name and key traits, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of having many sibling tools and an output schema, the description is minimal. It does not describe the return value format, how to use the parameters, or how this tool differs from similar ones beyond the model name. It leaves the agent with significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema provides no parameter descriptions. The tool description does not explain the 'query' or 'source_focus' parameters at all. For a tool with two parameters, the description should compensate but fails to add any parameter semantics.
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 identifies the tool as using Claude Opus 4.7, a specific reasoning model from Anthropic. It differentiates from siblings by naming the model and noting the cost and subscription requirement, making the purpose clear even though it doesn't explicitly say 'ask a question'.
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 cost and subscription prerequisites ('COSTS 1 PRO SEARCH QUERY. Requires Max subscription'), which helps the agent decide when to use it. However, it does not offer guidance on when to prefer this model over alternatives like pplx_claude_sonnet or pplx_gpt55.
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?
With no annotations, the description must carry the burden. It discloses the cost behavior (limited monthly pool) and that it generates reports, but does not explain output format, side effects, or how parameters affect behavior beyond the cost.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loading the purpose and immediately following with critical usage guidance. Every sentence earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks parameter explanations and does not describe return values. For a tool with a limited resource, critical details about parameter usage and expected output are missing, making it incomplete for reliable agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter descriptions in the schema. The description fails to explain the required 'query' parameter or the optional 'source_focus' parameter, leaving the agent without guidance on how to populate these fields.
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 produces 'in-depth reports' and distinguishes it from sibling tools by noting the cost of a deep research query and the condition to use only when explicitly requested. This provides a specific verb-resource pair and inherent differentiation.
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 explicitly says 'Only use when the user explicitly requests deep research', giving clear context for when to invoke the tool. However, it does not mention specific alternatives or provide 'when-not' scenarios beyond cost constraints.
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?
No annotations provided, so the description carries the burden. It discloses the cost ('COSTS 1 PRO SEARCH QUERY') but does not detail the 'auto model' behavior. This is helpful but could be more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences, front-loaded with the core purpose. Every sentence adds value with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description omits parameter semantics entirely, leaving the agent guessing about 'source_focus' and proper query formatting. The cost disclosure is the only extra context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description does not explain the 'query' or 'source_focus' parameters beyond the tool's purpose. The agent lacks information needed to construct valid inputs.
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 explicitly states 'Quick Q&A with auto model', defining a clear verb and resource. It distinguishes from sibling pplx_smart_query by recommending that for simple lookups.
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?
It provides explicit guidance: use for quick Q&A and prefer pplx_smart_query for simple lookups, establishing clear usage context and 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?
With no annotations, description carries full burden. Mentions sending a 6-digit code to email and returning status, but lacks details like code expiration or rate limits.
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?
Well-structured with intro, steps, args, returns. Concise and no fluff, though could be slightly tighter.
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?
Simple tool with one parameter; covers needed info. Output schema exists, but description still mentions return value. Adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description compensates. States email is 'Your Perplexity account email address', adding meaning beyond type string.
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 it requests a verification code for Perplexity authentication, specifying the verb and resource. It distinguishes from sibling tools like pplx_auth_complete and pplx_auth_status.
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?
Explicitly says to call this first, then check email and use pplx_auth_complete. Provides sequential context but could be more explicit about when not to use.
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 provided, but description implies read-only behavior by stating 'list live... available.' Does not mention rate limits or authorization requirements, but output schema exists to clarify return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise two-sentence description with a clear action verb and no extraneous information. Each sentence earns its place.
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?
Output schema is present, so return values are covered. Lacks mention of pagination or limits, but for a simple list tool, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description adds value by explaining premium_only's effect (show premium sources with limits) and listing example sources.
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 lists live Perplexity sources/connectors, which distinguishes it from sibling query tools like pplx_query and pplx_ask.
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?
Explains when to use premium_only to check premium quota, but does not explicitly state when not to use the tool or provide 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 provided, so the description carries the burden. It discloses that on success the session token is saved and all pplx_* tools work, plus the subscription tier. However, it lacks details on error handling, idempotency, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main purpose, followed by a usage line, parameter breakdown, and return info. Every sentence serves a purpose with no redundancy.
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?
For a simple auth tool with 2 parameters and an output schema, the description covers the workflow, parameter meanings, and outcome (session token saved, all tools work, subscription tier). It is complete enough for an agent to execute successfully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds significant meaning: 'email' is identified as the account email matching pplx_auth_request_code, and 'code' is explained as a 6-digit verification code. This compensates fully for the lack of schema descriptions.
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 'Complete Perplexity authentication with the verification code', specifying the verb (complete) and resource (authentication). It distinguishes from siblings like pplx_auth_request_code (requests code) and pplx_auth_status (checks status).
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?
Explicitly instructs to use the code after calling pplx_auth_request_code, providing a clear prerequisite. It does not state when not to use, but the context is sufficiently clear for the intended use case.
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?
Given no annotations, the description carries full burden. It discloses quota checking, automatic model selection, and metadata output (model, routing reason, quota snapshot). The intent guide explains routing behavior. Does not mention rate limits or auth, but these are less critical for a query tool.
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?
Well-structured with front-loaded purpose and recommendation, then intent guide, then args. Every sentence adds value. Could be slightly shorter but remains clear and effective.
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?
For a query tool with output schema, the description covers usage, intent selection, and parameter semantics adequately. Does not cover error cases or edge scenarios, but for the given complexity and sibling set, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no descriptions in schema), but the description provides rich explanations: intent gets a full guide with examples, source_focus is described though briefly, and query is explained. This adds significant meaning beyond the bare schema.
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?
Clearly states it's a quota-aware query tool that auto-selects the best model, distinguishing it from many sibling query tools like pplx_ask, pplx_query, pplx_sonar, etc. The description positions it as the recommended default, providing specific verb+resource.
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?
Explicitly recommends 'USE THIS FOR EVERY QUERY unless the user explicitly requests a specific model.' Provides a detailed intent guide with specific use cases for each level. Lacks explicit when-not-to-use exclusions but context is clear.
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?
No annotations provided, so description carries the full burden. It discloses return values (status and subscription tier) but does not explicitly state it is a read-only network call without side effects. However, the context is sufficient for a simple check tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose and return, second gives usage guidance. Front-loaded and every sentence earns its place.
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?
For a tool with no parameters and an output schema (which exists), the description covers the essential purpose and usage context. No obvious gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist (0 params, 100% schema coverage). Description adds value by explaining the return values, which goes beyond the empty schema. Baseline for 0 params is 4.
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?
Description clearly states the tool checks authentication status and returns subscription tier. It specifically distinguishes from sibling auth tools by focusing on status checking, and from query tools by being a prerequisite check.
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?
Explicitly says 'Use this to check if re-authentication is needed before making queries,' providing clear when-to-use guidance and establishing a pre-query workflow.
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?
Discloses cost: 'COSTS 1 PRO SEARCH QUERY per call.' Also notes which models support thinking mode. While it doesn't explicitly state read-only or idempotency, the description provides key behavioral context for a query tool, and annotations are absent, so the description carries the burden well.
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 efficient: a cost warning, usage guidance, and a parameter list with explanatory details. Every sentence serves a purpose, though the parameter list could be slightly more compact without losing clarity.
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 presence of many sibling tools, 4 parameters, and an output schema, the description covers all essential aspects: when to use, cost, model options, thinking constraints, source_focus flexibility. No gaps remain for the agent to make informed decisions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining each parameter: query (the question), model (listing options), thinking (availability caveats), and source_focus (possible values). This adds substantial meaning beyond the schema's type/default definitions.
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?
Explicitly states 'Query Perplexity AI with explicit model selection', indicating a specific verb and resource. It distinguishes itself from siblings by emphasizing the need for explicit model choice, contrasting with pplx_smart_query's automatic routing.
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?
Provides clear guidance: 'Prefer pplx_smart_query for automatic quota-aware routing. Use this only when you need a specific model or thinking mode.' This explicitly states when to use and when not, naming an alternative.
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 of disclosing behavior. It explains that the tool checks current usage, shows remaining quotas (weekly, monthly), and supports an optional refresh parameter to ignore cache. This is sufficient for a read-only informational tool, though it could mention the absence of side effects explicitly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It opens with a clear one-line summary, follows with usage guidance, then details the tool's scope and the parameter. Every sentence adds value, with no redundancy or fluff.
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?
For a simple tool with one parameter and no complex output, the description is largely sufficient. An output schema exists (not shown) which can cover return values, so the description need not dwell on them. It covers purpose, usage, and parameter semantics adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'refresh' is fully explained in the description: 'Force refresh from Perplexity (ignores cache). Default False.' Since schema description coverage is 0%, the description compensates entirely by providing meaning beyond the raw schema.
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 explicitly states it checks Perplexity usage limits and remaining quotas, clearly distinguishing it from sibling tools like pplx_ask and pplx_query which focus on making queries. The verb 'check' and resource 'usage' 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a direct instruction: 'CALL THIS AT THE START OF EVERY SESSION before making any queries.' It also explains how to use the results to decide whether to conserve Pro quota, providing practical guidance on when to use the tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: parallel queries to multiple models, synthesis by chairman, cost per model, default settings, and parameter effects (e.g., synthesize, thinking, chairman). It covers all 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear heading, important notes, and parameter list. It is front-loaded with the purpose. Slightly verbose but every sentence adds value; could be tightened slightly.
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, the description is comprehensive: it explains the workflow, cost, available models, defaults, and parameter options. The presence of an output schema reduces the need to describe output, so completeness is excellent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description provides detailed semantics for all six parameters: query, models (with list of available values and default), source_focus, synthesize, thinking, chairman (with default and cost note). It adds meaning beyond the schema.
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: 'query multiple models in parallel, get synthesized consensus.' It distinguishes itself from sibling tools (individual model tools like pplx_gpt54, pplx_claude_opus) by being a meta-tool that aggregates responses.
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 step-by-step usage instructions, including telling the user about available models, asking for model selection and count, informing cost implications, and requiring explicit confirmation. It also gives a default council composition.
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-web-mcp MCP server](https://glama.ai/mcp/servers/devdotbo/perplexity-web-mcp/badges/card.svg)](https://glama.ai/mcp/servers/devdotbo/perplexity-web-mcp)

Score Badge

Copy to your README.md:

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

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/devdotbo/perplexity-web-mcp'

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