Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden, and it delivers two non-obvious behaviors: the per-call cost (1 Pro Search Query) and the source_focus resolution chain (saved default from `pwm config`, then web). It omits return shape and whether conversation_id threads state, but the cost and fallback precedence are exactly the kind of context annotations would otherwise supply.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The cost warning is front-loaded, the alternative is given next, and the source_focus default rule follows. Three short lines with no filler; every sentence carries decision-relevant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described. The description covers purpose, cost, the preferred alternative, and the source_focus fallback; the only meaningful gap is conversation_id semantics (whether the Q&A continues an existing thread).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for 3 parameters, so the description must compensate. It does so for source_focus (a genuinely non-obvious default-resolution rule) while query is self-evident from the Q&A framing, but conversation_id is left entirely undefined in both schema and description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Quick Q&A') plus the model-selection behavior ('auto model'), and it names the sibling pplx_smart_query as the preferred path for simple lookups. It is clearly distinguishable from the deep-research and single-model siblings, though it doesn't fully contrast against pplx_query/pplx_sonar.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent: 'Prefer pplx_smart_query(intent='quick') for simple lookups (Sonar 2 first)', with a concrete cost signal ('COSTS 1 PRO SEARCH QUERY') to shape selection. It gives when-to-use and a named alternative, but no explicit when-not or prerequisite conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

Is 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.

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), 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.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It 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.

Does 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.

Does 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.

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.

Is 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.

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 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.

Does 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.

Does 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.

Does 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.

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.

Is 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.

Given 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.

Does 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.

Does 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.

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.' 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.

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.

Is 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.

Given 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.

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 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.

Does 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.

Does 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.

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.

Is 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.

Given 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.

Does 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.

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.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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool 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.

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.

Is 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.

Given 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.

Does 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.

Does 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.

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 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.

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.

Is 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.

Given 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.

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 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.

Does 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.

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. 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.

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.

Is 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.

Given 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.

Does 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.

Does 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.

Does 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does well: it discloses the cost model (each council member = 1 Pro Search query, synthesis an extra Sonar 2 call), the Max-only model restrictions tied to subscription tier, the per-model chairman surcharge, and which models support the thinking toggle. It does not spell out rate limits or return shape, and the read-only nature is only implied, keeping it short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded and well-organized with an IMPORTANT block, but there is real redundancy: the 16-model list appears three times (step 1, the models arg, and elsewhere) and the cost rule is restated. The Args section also repeats schema content the agent can already read, so a nontrivial share of the text does not earn its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values needn't be described. Combined with the cost/subscription gating, required confirmation workflow, and per-parameter notes, this is close to complete for a 6-parameter orchestration tool; only the missing guidance on choosing council vs. sibling research tools leaves a small gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate — and it largely does, explaining models (full list, default, Max-only exclusions), synthesize (false skips synthesis and saves a Sonar 2 call), thinking (which models toggle vs. always-on), chairman (default sonar, surcharge for non-sonar), and source_focus. Gaps remain: the chairman enum's 'auto' and 'deep_research' values are undocumented, and source_focus values are only parenthetically listed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The opening line states a specific verb+resource+mechanism: 'query multiple models in parallel, get synthesized consensus.' That cleanly distinguishes it from siblings like pplx_sonar, pplx_smart_query, and the single-model pplx_<model> tools, which return one model's answer rather than a synthesized council.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an unusually explicit precondition workflow (list models, check pplx_usage for subscription gating, confirm model count, disclose cost, get confirmation) and names the dependency tool pplx_usage. It is weaker on positional guidance against sibling alternatives (e.g., when to prefer pplx_deep_research or pplx_smart_query over a council), but the multi-model-consensus context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

Is 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.

Given 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.

Does 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.

Does 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.

Does 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.

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.

Is 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.

Given 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.

Does 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.

Does 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.

Does 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.

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.

Is 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.

Given 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.

Does 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.

Does 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.

Does 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.

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.

Is 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.

Given 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.

Does 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.

Does 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use 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.

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.

Is 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.

Given 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.

Does 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.

Does 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.

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_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.

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.

Is 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.

Given 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.

Does 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.

Does 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.

Does 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.

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.

Is 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.

Given 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.

Does 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.

Does 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.

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 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.

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.

Is 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.

Given 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.

Does 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.

Does 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.

Does 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.

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.

Is 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.

Given 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.

Does 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.

Does 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.

Does 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.

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.

Is 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.

Given 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.

Does 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.

Does 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.

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. 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.

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.

Is 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.

Given 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.

Does 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.

Does 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.

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 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.

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.

Is 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.

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 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.

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 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.

Does 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.

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 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.

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.

Is 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.

Given 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.

Does 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.

Does 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus 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.

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.

Is 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.

Given 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.

Does 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.

Does 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.

Does 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.

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.

Is 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.

Given 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.

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 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.

Does 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.

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 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden and does well: it discloses per-call cost ('COSTS 1 PRO SEARCH QUERY'), that Free-tier attachments can upgrade a query to Pro Search, that omitted params fall back to saved defaults then auto/web/off, and that unknown model names return an error with close-match suggestions. It omits auth/permission requirements, but cost, defaults, and error behavior are strong disclosures beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and the cost warning before routing guidance and the arg list. The Args block is long but each line carries information not present in the schema, so it is justified rather than padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described. For a 6-param tool the description covers cost, routing, defaults, error behavior, and most parameters; the only missing piece is any meaning for conversation_id.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it largely does: model enum values are annotated with which ones support thinking, source_focus options are explained semantically ('none (model only, no search), web, academic...'), and files notes accepted types and tier effects. conversation_id, however, is left entirely undocumented, which is the one gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Query Perplexity AI') plus the differentiating scope ('with explicit model selection'). It explicitly separates itself from pplx_smart_query, so an agent can choose between them without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit alternative ('Prefer pplx_smart_query for automatic quota-aware routing') and the precise condition that selects this tool instead ('only when you need a specific model or thinking mode'). When-to-use and when-not-to-use are both covered.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

Is 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.

Given 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.

Does 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.

Does 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.

Does 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries the full burden, and it does disclose notable behavior: automatic quota checks and model selection, a response metadata block with model/routing reason/quota snapshot, and a tier-dependent side effect ('On Free-tier accounts an attachment can make the query count as a Pro Search'). Minor inconsistency: it instructs 'Default to intent=quick' while the schema default is 'standard', which adds a small amount of ambiguity about actual default behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded and sectioned with a clear intent guide, and the argument list is scannable. There is some redundancy ('RECOMMENDED DEFAULT TOOL' / 'USE THIS FOR EVERY QUERY' / 'default for most' repeat the same point), so it is slightly longer than strictly necessary, but every section still earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 5-parameter routing tool with an output schema (so return values need no explanation), the definition covers the gaps that matter: routing policy, quota scarcity per intent level, enum semantics for the two string params, conversation continuation, and tier side effects. Nothing an agent needs to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate and does: it documents all five parameters including enum values absent from the schema (intent: quick/standard/detailed/research with routing targets; source_focus: none/web/academic/social/finance/all/connector IDs), the default-resolution chain for source_focus ('omit it to use your saved default, then web'), conversation_id threading behavior, and accepted file types plus tier consequences.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource framing ('Quota-aware query — checks limits and picks the best model automatically') and explicitly positions itself as the default against the many model-specific siblings ('RECOMMENDED DEFAULT TOOL', 'USE THIS FOR EVERY QUERY unless the user explicitly requests a specific model'). An agent can distinguish this from pplx_query, pplx_sonar, or pplx_claude_opus without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use ('USE THIS FOR EVERY QUERY unless the user explicitly requests a specific model'), when-to-escalate ('Only escalate intent when the question genuinely requires it'), and a per-level intent guide tied to concrete question types. The 'choose the LOWEST sufficient level' rule and the 'user must request' gate on research are exactly the routing guidance an agent needs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

Is 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.

Given 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.

Does 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.

Does 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.

Does 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.

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.

Is 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.

Given 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.

Does 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.

Does 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.

Does 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.