Perplexity Web MCP
Server Quality Checklist
Latest release: v0.14.12
- Disambiguation4/5
Most tools have distinct purposes (e.g., model-specific queries, smart routing, async research, thread management). However, pplx_query and pplx_smart_query overlap in functionality, and the many model-specific tools could cause confusion, although descriptions mitigate this.
Naming Consistency4/5Tools follow a consistent pplx_<action_or_model> pattern with snake_case. Minor inconsistencies exist like pplx_claude_sonnet_think vs other thinking suffixes, and pplx_deep_research_start/research_status break the model-naming pattern.
Tool Count3/530 tools is on the high side for an API wrapper, but justifiable given the variety of models and features. However, many model-specific query tools could be consolidated, reducing cognitive load.
Completeness4/5The set covers authentication, usage tracking, thread history, connectors, and various query modes. Missing are thread management (delete, rename) and user profile tools, but core workflows are well supported.
Average 3.2/5 across 30 of 30 tools scored. Lowest: 1.6/5.
See the Tool Scores section below for per-tool breakdowns.
- 23 of 23 community issues answered or closed in the last 6 months
- 59 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.jsonto 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?
With no annotations, the description should fully disclose behavior. It only mentions cost ('COSTS 1 PRO SEARCH QUERY'), but omits whether it is read-only, what it returns, or if it has side effects. A score of 2 due to minimal disclosure beyond 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but fails to be effectively informative. Every sentence should add value, but this one omits critical details. It is under-specified rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and there are many sibling tools, the description is severely inadequate. It does not explain the tool's output, how it differs from other model-specific tools, or how to use the parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It provides no information about any of the 3 parameters (query, source_focus, conversation_id), leaving the agent with no understanding of what values to provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only states 'Claude Sonnet 5 — Anthropic's fast model. COSTS 1 PRO SEARCH QUERY.' It does not include a verb or specify what the tool does (e.g., search, query, generate). Among many sibling tools with model names, it fails to distinguish its action or purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 like pplx_claude_opus or pplx_grok45. It does not mention use cases, prerequisites, 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?
The only behavioral trait disclosed is cost ('COSTS 1 PRO SEARCH QUERY'). No annotations exist to supplement, so the description falls short on rate limits, auth needs, or operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) but lacks substantive content. It earns no penalties for verbosity, but brevity here comes at the cost of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, an output schema, and many siblings, the description is severely incomplete. It omits the tool's purpose, parameter details, and any usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no parameter descriptions) and the description adds no meaning to the three parameters (query, source_focus, conversation_id). The agent learns nothing about argument expectations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the model as 'Grok 4.5 — xAI's most advanced model' and mentions cost, but does not state the tool's action or operation (e.g., query, generate). It fails to differentiate from sibling tools like pplx_grok45_thinking 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 Guidelines1/5Does 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. With many similar sibling tools, the agent receives no help in selecting this tool.
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 should disclose behavioral traits (e.g., whether it mutates state, triggers side effects). It only mentions cost and subscription, leaving the behavioral profile largely unknown.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it sacrifices necessary detail for brevity. It is not front-loaded with useful guidance; instead, it states basic facts that could be inferred from the name and annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the tool lacks context on how input parameters affect behavior, making it incomplete for an AI agent to use correctly among many similar sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about the parameters (query, source_focus, conversation_id). Since schema description coverage is 0%, the entire burden is on the description, which it fails to meet.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names the model but does not specify the tool's function, such as performing a search or generating a response. It reads like a label rather than a functional description, making it unclear what the tool actually does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions subscription and cost requirements but provides no guidance on when to use this tool over siblings like pplx_sonar or pplx_ask. No context on appropriate scenarios or exclusions is given.
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 bears full burden for behavioral disclosure. Only the cost ('COSTS 1 PRO SEARCH QUERY') is mentioned, but other critical traits like statelessness, streaming support, or rate limits are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, which is concise, but it lacks any structured detail about the tool's function or usage. It earns its place minimally.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and three parameters, the description provides almost no context about the tool's role, return value, or parameter handling, making it inadequate for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has three parameters with zero description coverage, and the tool description adds no information about their meaning, usage, or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'OpenAI's versatile model' does not include a specific verb or action, leaving it unclear whether the tool is for answering queries, generating text, or another purpose. It fails to distinguish from siblings with similar model names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives like pplx_gpt56_sol or pplx_sonar. The only hint is the cost mention, which is not a usage guideline.
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 mentions cost (1 PRO SEARCH QUERY) and subscription requirement, which is useful, but does not disclose other behavioral traits like rate limits, side effects, or whether it reads or writes data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (two lines). While it front-loads the model name, it is too brief to convey necessary information. Conciseness is positive, but it sacrifices completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters and exists among many model-specific siblings. The description does not explain how to use the tool, what 'thinking' entails, or how to structure queries. An output schema exists but its contents are unknown; the description still lacks context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 3 parameters with 0% description coverage, and the tool description does not mention any parameter. The meaning of 'query', 'source_focus', and 'conversation_id' remains completely unexplained, failing to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the model (GPT-5.6 Sol Thinking) but lacks a verb specifying the tool's action. It is unclear whether the tool executes a query, generates text, or performs a search. Compared to siblings like pplx_query, the purpose is vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like pplx_gpt56_sol (without thinking) or other models. The description implies it's for complex reasoning ('most powerful model with thinking') but does not state exclusions or 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 are provided, so the description carries full burden. It only mentions plan/usage counters, but does not disclose whether the tool is read-only, requires authentication, has rate limits, or what happens when limits are exceeded. Behavioral traits are largely undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences) and front-loaded with the model name, but it is under-specified. While concise in length, it lacks informative content. It earns its place minimally by noting usage constraints, but fails to convey the tool's core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters and an output schema, the description is incomplete. It does not explain what the tool does, how parameters affect behavior, or what the output represents. The reference to plan/usage counters is useful but insufficient for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain parameters, but it does not. The parameters query, source_focus, and conversation_id are not mentioned or described in the description text. No additional meaning is provided beyond the schema field names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description only identifies the model as 'Sonar 2 — Perplexity's latest in-house model' but does not specify the tool's action (e.g., search, answer, chat). The name suggests it's a query tool, but the description lacks a verb and resource, making the purpose vague. Among siblings like pplx_query and pplx_ask, no differentiation is provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions plan and usage counters with a reference to pplx_usage, but does not provide any guidance on when to use this tool versus other sibling models or tools. There is no explicit context about appropriate use cases or when to avoid 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, the description must fully explain behavior. It only notes 'thinking always enabled' and cost, omitting details like required permissions, side effects, response format, or error conditions. Insufficient for safe use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but fails to convey essential information. Conciseness should not come at the expense of completeness; here it is under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 params, no annotations, output schema present), the description is far from complete. It lacks usage context, parameter explanations, and behavioral details, making it inadequate for proper tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description provides zero information about the three parameters (query, source_focus, conversation_id). The agent gets no help beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names the model (GLM 5.2) and mentions 'advanced model with thinking always enabled', but lacks a clear verb like 'query' or 'ask'. It implies the tool is for submitting queries to this model, but doesn't explicitly state the action, making it only somewhat 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/5Does 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_ask, pplx_query, or pplx_smart_query. The only hint is the model name and cost, which is insufficient for 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?
No annotations are provided, so the description carries full burden. It only mentions the cost (1 PRO SEARCH QUERY) but does not disclose safety, side effects, read/write nature, or any other behavioral traits. Agent cannot assess risk or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short (two clauses) but wastes the opportunity to include crucial details. While concise, it sacrifices clarity and completeness. It could easily be expanded without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, some optional, with output schema) and many siblings, the description is far from complete. It omits parameter explanations, behavioral context, and usage scenarios. The output schema exists but does not compensate for the lack of operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does 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 any of the three parameters (query, source_focus, conversation_id). The agent receives no guidance on what values to provide, default behaviors, or parameter relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
Description identifies the model as 'Claude Sonnet 5 Thinking' and mentions it costs a PRO SEARCH QUERY, but lacks an action verb (e.g., 'query', 'ask'). It vaguely indicates a reasoning model but does not clearly state what the tool does or how it differs from similar siblings like pplx_claude_sonnet or pplx_claude_opus_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/5Does 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. With over 20 sibling tools offering different models, the description provides no context for selecting this particular model over others.
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 provides a behavioral note on cost ('COSTS 1 PRO SEARCH QUERY') but no other disclosures (e.g., rate limits, output format, data handling). With no annotations, more context is expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences) and front-loaded with the model name and cost. Every word serves a purpose, but the brevity sacrifices comprehensiveness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given 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 crucial details about parameter usage, return values, and how this tool differs from many similar siblings. It is insufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does 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 any of the three parameters (query, source_focus, conversation_id). The agent has no additional meaning beyond the schema names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as an advanced model (Kimi K2.6) but lacks a verb indicating the action (e.g., query, ask). It vaguely implies a query function via the sibling tools context, but does not explicitly state what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like pplx_query or pplx_ask. The description merely mentions the model name and cost without clarifying the use case or exclusions.
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 convey behavioral traits. It mentions 'extended thinking' and the cost, but does not disclose whether the tool is read-only, destructive, what happens during execution, or potential side effects. The behavioral insight is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), which is concise, but at the expense of completeness. It lacks necessary details about functionality and parameters, so conciseness trades off against clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters with no schema descriptions and an output schema exists, the description should provide context on how to use the tool and what to expect. It only mentions the model and cost, leaving users uninformed about return values, parameter usage, or any special behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any of the three parameters (query, source_focus, conversation_id). Since schema description coverage is 0%, the description must compensate, but it adds zero semantic value for parameters. No parameter meanings, formats, or examples are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the model (Gemini 3.1 Pro Thinking) and mentions it is Google's most advanced model with extended thinking, which distinguishes it from siblings. However, it does not explicitly state the action (e.g., 'perform a search' or 'generate a response'), leaving the primary function implied rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage hint is 'COSTS 1 PRO SEARCH QUERY,' which implies a premium cost but provides no direct guidance on when to use this tool over alternatives like pplx_gpt54_thinking or pplx_claude_sonnet_think. No comparisons, prerequisites, or exclusions are mentioned.
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 a cost of 1 Pro search query, which is a behavioral trait. However, no annotations are provided, and the description does not disclose other traits such as read/write nature, authentication needs, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences) and front-loaded with key info (model name and cost). While concise, it omits critical details, so it is not fully effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, no schema descriptions) and no annotations, the description is incomplete. It lacks parameter explanations and usage context, even though an output schema is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has three parameters with no descriptions, and the tool description adds no information about them. With 0% schema description coverage, the agent receives no semantic help for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as Kimi K2.6 Thinking, Moonshot's advanced model with extended thinking, which clearly indicates its purpose. However, it does not explicitly state that the tool sends a query and returns a response, making it less direct than ideal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like pplx_kimi_k26 or other thinking models. There is no context about preferred use cases 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, the description must cover behavioral traits. It mentions extended thinking (implying deeper reasoning) and cost, but lacks details on response format, side effects, permissions, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but it omits critical information. It is not a model of conciseness if it fails to adequately describe the tool; however, it does front-load the key differentiator (model and cost).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters with no schema descriptions and no annotation support, the description is insufficient for an agent to use the tool correctly. Output schema exists but is not described, and parameters are not explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds no explanation for the three parameters (query, source_focus, conversation_id). Users must infer their meaning from names alone, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool uses NVIDIA's Nemotron 3 Ultra 550B model with extended thinking and notes it costs one Pro Search query. This distinguishes it from sibling tools like pplx_query or pplx_claude_opus by specifying the model and thinking feature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like pplx_gpt55_thinking or pplx_smart_query. The only hint is the cost implication, but no exclusion criteria or context for 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 carries full burden for behavioral disclosure. It reveals that usage costs 1 Pro Search query and requires a Max subscription, which is useful. However, it does not describe what happens upon invocation (e.g., response format, latency, or whether it is read-only or mutates state). No annotation contradiction detected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loading the model identity and key constraints. No unnecessary words. However, it could be more structured (e.g., separate lines for model, cost, requirements).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of 3 parameters (1 required) and an output schema, the description should cover parameter usage and output expectations. It mentions cost and subscription but omits how the parameters affect behavior or what the response contains. 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no information about the three parameters (query, source_focus, conversation_id). The agent must infer that 'query' is the input prompt, but no guidance on valid values or defaults is given. This is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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.8 Thinking', specifying it as the most advanced reasoning model with extended thinking. This distinguishes it from sibling tools like pplx_claude_opus (non-thinking) and pplx_claude_sonnet_think (different model). However, it does not explicitly state the action (e.g., 'ask a query using this model'), relying on the tool name to imply usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs. alternatives. It mentions cost and subscription requirements but does not advise on scenarios where extended thinking is beneficial or when simpler models suffice. No alternative tools are referenced.
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 must disclose behavior. It only covers cost and subscription requirements, omitting details like return format, conversation continuity (hinted by conversation_id parameter), or any side effects. The behavioral profile is incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two brief parts), but it sacrifices essential information for brevity. It is not well-structured; the key action is missing. Adequate conciseness but poor completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 3 parameters, no schema descriptions, an output schema present but unmentioned, and a notable cost/subscription context, the description is severely incomplete. It fails to provide enough context for correct tool usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It provides no meaning for 'query', 'source_focus', or 'conversation_id'. The agent receives no guidance on parameter values or their significance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the model as 'Claude Opus 4.8 — Anthropic's most advanced reasoning model' and mentions cost and subscription, implying it is a query tool. However, it does not explicitly state the tool's action (e.g., 'Ask a question to Claude Opus'). The model name and capabilities provide sufficient clarity for a knowledgeable agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'COSTS 1 PRO SEARCH QUERY' and 'Requires Max subscription', providing context on constraints. However, it does not specify when to use this tool versus siblings like pplx_claude_sonnet or pplx_claude_opus_think, nor does it offer exclusion criteria or alternatives.
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 behavior. It only mentions cost, omitting traits like whether it's read-only, rate limits, or side effects. The 'thinking' trait is name-inferred, not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
Very short and front-loaded with model name and cost, but it sacrifices essential information. Could be expanded without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema, the description fails to explain what the tool returns or how to use its parameters. For a tool with 0% schema coverage and no annotations, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning description provides no parameter details. The three parameters (query, source_focus, conversation_id) are completely unexplained, leaving the agent with no guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as GPT-5.6 Terra with thinking, distinguishing it from the non-thinking sibling pplx_gpt56_terra. However, it lacks a verb stating what the tool does (e.g., generates, answers), relying on context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The cost hint ('COSTS 1 PRO SEARCH QUERY') implies usage when thinking is needed and budget allows, but no explicit guidance on when to choose this vs alternatives like pplx_sonar or other thinking models.
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?
The description discloses a key behavioral trait: 'COSTS 1 PRO SEARCH QUERY,' which is useful for cost-aware agents. However, with no annotations provided, additional details like idempotency, error handling, or output format are missing, leaving the behavioral profile incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), which is concise, but it sacrifices essential information. It front-loads the model name but does not structure the content to aid quick comprehension; it feels incomplete rather than efficiently minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters and an output schema, the description should provide enough context for correct invocation. It omits parameter meanings, usage scenarios, and result behavior, making it insufficient for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description offers no explanation for any of the three parameters (query, source_focus, conversation_id). The description is expected to compensate for low coverage but fails entirely, providing zero parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description names the model 'Grok 4.5 Thinking' and states it is 'xAI's most advanced model with thinking,' which conveys the tool's purpose as a reasoning-capable search model. However, it lacks an explicit verb like 'search' or 'query' to describe the action, leaving some ambiguity compared to sibling tools like pplx_grok45.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 over its many siblings (e.g., pplx_grok45, pplx_sonar, pplx_deep_research). The description does not specify contexts or alternatives, making it difficult for an agent to choose appropriately.
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 description carries full burden. It discloses the cost (1 deep research query from a limited pool) which is critical. However, it does not mention other behavioral traits like authentication needs, destructiveness, or async behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words, front-loaded with essential information (purpose and cost). Perfectly concise for the information provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool consumes a limited resource and has an output schema, the description fails to describe return values, async nature, or relation to companion tools like pplx_deep_research_start and pplx_research_status. Incomplete for a high-cost tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning no descriptions in the schema. The description does not explain the two parameters (query and source_focus) at all, leaving the agent to infer from names only. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it produces in-depth reports via deep research, and explicitly limits usage to when the user requests deep research. However, it does not differentiate from related siblings like pplx_deep_research_start or pplx_research_status, which may cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear directive 'Only use when the user explicitly requests deep research' and mentions cost constraints. Lacks explicit alternatives or when-not-to-use scenarios, but the instruction is strong enough for most cases.
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 description must cover behavioral traits. It mentions cost (1 Pro search query) and 'auto model', but does not explain auto model selection, output format, rate limits, or error behavior. Adequate for a simple tool but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose. Efficient but could be slightly more structured to include parameter hints or output details without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 3 parameters, no parameter docs, and an output schema not referenced, description is incomplete. It covers cost and usage guidance but lacks essential parameter and output explanations needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but description adds no parameter info. Does not explain 'query', 'source_focus', or 'conversation_id'. Fails to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Quick Q&A with auto model', giving a specific verb (ask) and resource (Query & Answer). It also specifies cost (1 Pro search query) and differentiates from sibling pplx_smart_query by directing to use that for simple lookups with Sonar 2 first.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Prefer pplx_smart_query(intent='quick') for simple lookups (Sonar 2 first)', providing clear when-to-use and alternative. Also implies this tool is for quick Q&A, giving context for its 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, so description must fully disclose behavior. It explains return types but does not mention read-only nature, idempotency, rate limits, or polling safety. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with purpose, no wasted words. Highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple status polling tool with one parameter and output schema present, description explains all possible return types. No gaps for its intended use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage and description does not explain the sole parameter 'task_id' beyond its name. No guidance on format or source (e.g., from start tool). Fails to add meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Check' and resource 'status of an asynchronous deep research task', with explicit return values (in_progress, report, error). It distinguishes from sibling tools like pplx_deep_research_start.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use after starting a deep research task but does not explicitly mention when to use or not use, nor name alternatives. Context is clear but lacks explicit guidance.
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 full burden. Discloses it 'Returns source IDs from the Perplexity rate-limit API' and explains output usage. Good transparency for a read-only listing 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences: first states action, second provides an example. No wasted words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Explains output and usage, but missing explanation of the 'refresh' parameter. With only one parameter, this gap reduces completeness despite existing output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has one parameter 'refresh' with 0% description coverage, yet the description does not explain it. This leaves the agent guessing about its behavior, failing to add meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List account connector source IDs' with a specific verb and resource, and explains the purpose (to be used as source_focus). It distinguishes from siblings by focusing on connector source ID listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for use (obtain source_focus values) with an example, but lacks explicit guidance on when not to use or 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses asynchronous behavior, immediate return of task_id, and cost of 1 deep research query. It does not mention error handling, permissions, or rate limits, but the core behavioral traits are covered for a simple async start 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each carrying essential information: action, cost/alternative, and follow-up. No unnecessary words. Key points are front-loaded. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, no nested objects, has output schema). The description covers purpose, async return, and cost. It lacks details on the source_focus parameter and any limits on concurrent tasks, but for an async start tool, the core information is present. Output schema existence reduces the need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has two parameters (query, source_focus) with 0% description coverage. The description does not add any meaning beyond the parameter names. The parameter names are self-explanatory, but the description fails to provide context like valid values for source_focus or example queries, leaving a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it starts a deep research task asynchronously, distinguishes from sibling pplx_deep_research by noting this avoids timeouts for complex queries, and specifies it returns a task_id immediately. The verb 'start' and resource 'deep research task' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this instead of pplx_deep_research for complex queries to avoid connection timeouts.' Provides clear guidance on when to use this tool vs the alternative. Also tells the agent to poll pplx_research_status with the task_id to get the result, which is direct usage help.
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 must convey behavioral traits. It mentions 'FREE — zero quota cost' and states it returns data, implying a read-only operation. However, it does not disclose authentication requirements, rate limits, or potential side effects. The description is adequate but lacks completeness regarding behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with clear sections: tool purpose, cost, output, slug source, and a resume pattern. Every sentence adds value, though the resume pattern could be more concise. Overall, it balances completeness with readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema exists), the description covers all necessary context: what it does, how to get the slug, and a usage pattern. The presence of an output schema reduces the need to describe return values, and the description still mentions key return elements (Q&A turns, sources, related queries).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no description for the slug parameter (0% coverage). The description compensates fully by explaining the slug's purpose, how to obtain it from other tools, and its format (UUID/slug). This adds essential meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the full conversation history for a Perplexity thread, specifying verb ('Fetch') and resource ('full conversation history'). It distinguishes from sibling tools by detailing the output content (Q&A turns, sources, related queries) and providing a usage pattern to obtain the slug.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool, including how to obtain the slug from pplx_list_threads or previous query footers. It includes a step-by-step RESUME PATTERN for continuing past conversations. However, it does not explicitly state when not to use it or name alternative tools for different needs.
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. It discloses that on success the session token is saved and all pplx_* tools will work. It does not detail failure modes or rate limits, but the behavioral outcome is sufficiently described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose, then structured with Args/Returns. It is concise overall, though the Args/Returns section is somewhat verbose but standard for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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), the description appropriately does not detail return values beyond status message and subscription tier. It covers the prerequisite, parameters, and post-condition. Slightly more detail on failure would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining each parameter: email is the account email from the prior step, code is the 6-digit verification code, totp_code is for TOTP authentication. This provides context beyond the schema's raw definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Complete') and resource ('Perplexity authentication with the verification code'), clearly distinguishing it from the sibling tool pplx_auth_request_code by referencing the prerequisite step. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: after calling pplx_auth_request_code with the received 6-digit code. It implies the alternative (requesting the code if not done), though it does not explicitly say when not to use it. The context is clear enough.
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 must carry full burden. It discloses that a 6-digit code is sent and the return is a status message. It doesn't mention rate limits or code expiration, but for a simple auth request, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear two-paragraph structure: purpose and next step, then Args and Returns. Every sentence adds value, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given 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 an output schema, the description covers all necessary aspects: what it does, how to use it (including next step), parameter explanation, and return value. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does so with an Args section that explains 'email: Your Perplexity account email address', adding meaning beyond the bare type. The parameter is well-described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool requests a verification code for Perplexity authentication and sends it to the provided email. It is a specific verb ('request') on a specific resource ('verification code'), and its role is distinct from siblings 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to check email inbox and use pplx_auth_complete with the code, providing a clear next step. However, it does not explicitly contrast with pplx_auth_status or mention when to avoid this tool, though the context makes its purpose 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, but description discloses returns and that it is a status check. No side effects mentioned; adequate for a simple read operation with no parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: action, returns, usage guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists and description explains returns. No parameters. Tool is simple and description covers all necessary context for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist (0 params, schema coverage 100%), so baseline score is 4. Description adds no extra param info, but none needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Check if Perplexity is authenticated' and specifies returns (auth status, subscription tier). Distinguishes from sibling tools like pplx_auth_complete and pplx_auth_request_code by mentioning re-authentication check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does 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.' Provides clear context for when to use, though does not mention alternatives among siblings.
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: quota-awareness, automatic model selection, intent-based routing to specific models (e.g., 'quick routes to Sonar 2'), and that responses include a metadata block with model, routing reason, and quota snapshot. Also mentions scarce monthly quota for research and that user must explicitly request it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bullet points for intent guide, front-loaded with purpose and usage recommendation. Some redundancy (e.g., repeating 'default to quick' and 'intent guide') but overall efficient. Could be slightly more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given tool complexity (quota-awareness, multiple models, intents, source_focus) and presence of an output schema, the description covers most aspects needed to use the tool correctly. It references related tools (pplx_usage, pplx_connectors). However, it omits explanation of conversation_id and does not address error handling or quota exhaustion scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the descriptions for query, intent, and source_focus add significant meaning (e.g., explaining intent levels, source_focus options including connector source ID). However, conversation_id is not explained, and there is a slight inconsistency where schema default for intent is 'standard' but the description recommends defaulting to 'quick' for most lookups. Coverage is incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'quota-aware query' that checks limits and picks the best model automatically. It is explicitly labeled as 'RECOMMENDED DEFAULT TOOL,' distinguishing it from siblings like pplx_sonar and pplx_deep_research by its automatic model selection and quota management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Very explicit about when to use: 'USE THIS FOR EVERY QUERY unless the user explicitly requests a specific model.' Provides detailed intent guide with specific criteria for each level (quick, standard, detailed, research), including when to escalate. Clearly differentiates from sibling tools by recommending this as the default.
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 are provided, so the description carries the full burden. It discloses the cost ('COSTS 1 PRO SEARCH QUERY per call'), which is a key behavioral trait. However, it does not explicitly state prerequisites like authentication or side effects beyond quota consumption. The cost warning is valuable, but more detail on authorization would improve 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a terse header with cost, then usage guidance, then parameter docs. Every sentence is meaningful with no redundancy. It is appropriately sized for a 5-parameter tool with complex model selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, 1 required, and an output schema (not shown), the description covers most aspects. It explains parameter choices and usage context. The omission of conversation_id is a minor completeness issue. Nonetheless, the description is sufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains 4 of 5 parameters (query, model, thinking, source_focus) with model lists and source focus options. It misses conversation_id entirely, which is a notable gap. The provided parameter descriptions add significant meaning beyond the enum-based schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries Perplexity AI with explicit model selection and mentions the cost. It distinguishes itself from sibling pplx_smart_query by stating when to prefer the other, making the purpose 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Prefer pplx_smart_query for automatic quota-aware routing. Use this only when you need a specific model or thinking mode.' This provides clear when-to-use and when-not-to-use guidance with a named 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, description covers behavior well: shows quotas (Pro Search weekly, Deep Research monthly), and explains refresh parameter. Could mention if calling this counts toward usage, but overall strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences plus args section, front-loaded with purpose and critical usage instruction. Every sentence adds value, no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema likely defines return values, so description need not repeat. Parameter count is 1, well explained. Siblings are many but tool is clearly distinct.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description defines the 'refresh' parameter: 'Force refresh from Perplexity (ignores cache). Default False.' Adds clear meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it checks usage limits and remaining quotas, specifying the resource and action. It distinguishes itself from siblings like pplx_ask by focusing on usage information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'CALL THIS AT THE START OF EVERY SESSION' and explains how to use results to decide about conserving Pro quota. Provides clear when-to-use and implied when-not-to-use guidance.
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 that the tool is free (zero quota cost), returns a paginated list, and lists the fields returned. While no annotations exist, the description covers key behavioral aspects without contradictions. Could have mentioned rate limits or error handling, but overall strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with a clear one-liner, followed by structured sections (primary use cases, parameters). Every sentence adds value, no redundancy. Efficient and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description covers all necessary aspects: purpose, usage, parameters, and output fields. Explains how to use results (e.g., slug for pplx_get_thread), making it self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds complete meaning for all three parameters (limit, offset, search_term) beyond the empty schema descriptions. Includes defaults, maximums, and practical usage context such as pagination and filtering. Fully compensates for 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool browses the Perplexity thread library, returns a paginated list with specific fields, and distinguishes from sibling tools like pplx_get_thread by providing use cases and alternative guidance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists primary use cases with examples: searching before spending a Pro query, finding a conversation to resume, and retrieving full history via pplx_get_thread. Provides explicit when-to-use and when-not-to-use scenarios.
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?
The description discloses behavioral traits including cost (each council model = 1 Pro Search query, plus synthesis), model-specific thinking support, and chairman implications. It also explains that the chairman defaults to sonar and non-sonar chairmen cost extra, providing transparency beyond the bare structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a title line, an 'IMPORTANT' section with bullet points, and an Args block. It is fairly concise for a complex tool, though slightly verbose. Front-loading purpose and prerequisites is good.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers all 6 parameters, usage scenario, costs, prerequisites, and model restrictions. Given the tool's complexity and many sibling tools, it is very complete and provides sufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description's 'Args:' block explains each parameter (query, source_focus, models, synthesize, thinking, chairman) in detail, including meanings, defaults, available options, and behavioral implications. This adds significant value over the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Model Council — query multiple models in parallel, get synthesized consensus.' It specifies the verb (query multiple models in parallel) and resource (council of models), and distinguishes from many single-model sibling tools like pplx_gpt56_terra and pplx_sonar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an 'IMPORTANT' section with step-by-step instructions before calling, including checking pplx_usage, asking user for models, informing cost, and getting confirmation. It also explains default council, subscription restrictions, and provides guidance on when to use alternatives.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jacob-bd/perplexity-web-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server