Server Quality Checklist

Tool Scores

• perplexity_askA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds meaningful context beyond annotations: it returns text with numbered citations, supports recency/domain filtering, and search context size adjustment. No contradictions; slight gap on rate limits or error behavior, but annotations cover the safety profile.

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

  Conciseness4/5

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

  The description is compact and front-loaded with the primary purpose, then usage, features, and alternatives. It is slightly longer than two sentences but every clause serves a distinct informative purpose, avoiding fluff or redundancy.

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

  Completeness5/5

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

  For a read-only tool with rich annotations, 100% schema coverage, and an output schema, the description covers purpose, appropriate usage, alternative tools, key behavioral traits, and configuration options. Nothing essential is missing for an agent to select and invoke it correctly.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description mentions filtering capabilities at a high level but adds no syntax or detailed semantics beyond what the schema provides. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description uses a specific verb ('Answer a question') and resource ('web-grounded AI – Perplexity Agent API'), and explicitly distinguishes it from siblings ('For in-depth multi-source research, use perplexity_research instead. For step-by-step reasoning and analysis, use perplexity_reason instead.'). This makes the tool's purpose unambiguous.

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

  Usage Guidelines5/5

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

  Provides explicit 'Best for' scenarios (quick factual questions, summaries, explanations, general Q&A), the fastest/cheapest option, and directly names alternative tools for other use cases. Clear when-to-use and 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.

• perplexity_searchA
  4.4/5.0
  Behavior4/5

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

  Annotations already signal readOnlyHint=true and destructiveHint=false, so the description doesn't need to repeat safety. It adds useful behavioral context: returns formatted results with 'no AI synthesis' (raw output) and supports recency/domain filters. While it doesn't mention pagination or rate limits, the annotation coverage lowers the bar, and the description adds meaningful value.

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

  Conciseness5/5

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

  The description is concise and front-loaded: two sentences with the core action, a 'Best for' list, and an alternative pointer. Every sentence serves a purpose, with no redundant or filler text.

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

  Completeness4/5

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

  The output schema exists and annotations cover safety, so the description doesn't need to explain return values. It covers main use cases, differentiates from a sibling, and notes key capabilities. It could also mention perplexity_research/reason for completeness, but that's not essential for this tool.

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

  Parameters3/5

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

  Schema coverage is 100%, so baseline is 3. The description mentions 'recency filters and domain restrictions,' which echoes the schema but adds no new syntax or constraint details. Parameters are already fully documented in the input schema.

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

  Purpose5/5

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

  The description clearly states the tool's action and resource: 'Search the web and return a ranked list of results with titles, URLs, snippets, and dates.' It also distinguishes from sibling perplexity_ask by explicitly noting 'no AI synthesis' and directing AI-answer needs to perplexity_ask.

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

  Usage Guidelines5/5

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

  Provides an explicit 'Best for' list (finding specific URLs, checking recent news, verifying facts, discovering sources) and an explicit alternative: 'For AI-generated answers with citations, use perplexity_ask instead.' This clearly guides when to use this tool versus a sibling.

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

• perplexity_reasonA
  4.7/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint and non-destructive behavior. The description adds meaningful context beyond annotations: it uses the Perplexity Agent API with a medium preset, returns numbered citations, and offers filtering options. No contradiction exists, and the added behavioral details help set expectations.

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

  Conciseness5/5

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

  The description is five sentences, each earning its place: main purpose, best-for list, output format, filter capabilities, and sibling alternatives. It is front-loaded with the core verb and stays compact without redundancy.

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

  Completeness5/5

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

  For a tool with moderate complexity (4 params, output schema exists, annotations present), the description is complete. It covers purpose, use cases, output style (reasoned response with numbered citations), filtering options, and alternative tools, leaving no critical gaps for an agent to select and invoke correctly.

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

  Parameters4/5

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

  Schema coverage is 100%, so the baseline is 3. The description adds semantic value by naming the medium preset (implying a default search_context_size), listing recency filter options, and framing the filters as search capabilities. This slightly exceeds baseline by connecting parameters to the tool's reasoning workflow.

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

  Purpose5/5

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

  The description clearly states the tool analyzes questions using step-by-step reasoning and web grounding, with a specific list of use cases (math, logic, comparisons, complex arguments). It explicitly distinguishes itself from siblings perplexity_ask and perplexity_research, making its unique role clear.

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

  Usage Guidelines5/5

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

  Provides explicit 'Best for' scenarios and direct alternatives: 'For quick factual questions, use perplexity_ask instead. For comprehensive multi-source research, use perplexity_research instead.' This gives clear when-to-use and 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.

• perplexity_researchA
  4.7/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint, openWorldHint, and non-destructive behavior. The description adds valuable behavioral context beyond annotations: 'Significantly slower than other tools (can take minutes)' and 'Returns a detailed response with numbered citations,' which are not evident from the annotations alone.

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

  Conciseness5/5

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

  The description is concise and well-structured: it starts with the core function, then best-for use cases, output characteristics, performance caveat, and alternatives. Every sentence serves a purpose without redundancy or fluff.

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

  Completeness5/5

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

  Given the tool's complexity and the existence of an output schema, the description covers purpose, usage guidance, performance, output format (citations), and alternatives. It is fully self-contained and insufficient in no aspect, so it earns a 5.

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

  Parameters3/5

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

  The schema covers 100% of the parameter (messages) with role/content definitions, so baseline is 3. The description does not add specific parameter-level details but contextualizes the input as a 'topic,' which is already implied by the schema. No significant added meaning beyond the schema.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'Conduct deep, multi-source research on a topic' with a specific verb and resource. It explicitly distinguishes from siblings by mentioning 'high preset' and contrasting with perplexity_ask and perplexity_reason, making the purpose unambiguous.

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

  Usage Guidelines5/5

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

  Provides explicit guidance on when to use this tool ('Best for: literature reviews, comprehensive overviews, investigative queries needing many sources') and when not to: 'For quick factual questions, use perplexity_ask instead. For logical analysis and reasoning, use perplexity_reason instead.' This clear alternatives/exclusion structure earns a top score.

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