Server Quality Checklist

Tool Scores

• video_searchA
  4.1/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond that: it is in Beta, requires beta access to be requested, and returns ranked results with a specific set of fields. It does not cover rate limits, failure behavior, or authentication, but with annotations present the added detail is solid.

  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 mostly tight and front-loaded: purpose, result fields, beta access, and usage guidance appear in the first four sentences. The trailing keyword list is somewhat redundant, but it is short and does not seriously bloat the definition.

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

  Completeness4/5

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

  For a read-only search tool with seven fully documented parameters, the description covers the essential invocation (text query), the return shape (ranked results with fields), and an access caveat (Beta). It does not explain interactions like `time_range` versus `start_time`/`end_time`, but those are handled in the schema, and the return-field list is valuable because no output schema exists.

  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%, and all parameters already have descriptive text, enums, ranges, and defaults. The description only repeats the `query` parameter ('Pass a text `query`'), which adds no meaning beyond what the schema already provides. This matches the baseline for fully-documented schemas.

  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 opens with a specific verb and resource: 'Find videos on the web by text query.' It also lists the concrete result fields, making the tool's scope unmistakable. It explicitly distinguishes itself from general text web search, which differentiates it from sibling `search`-style tools.

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

  Usage Guidelines4/5

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

  The description clearly states when to use the tool: when the user wants videos, clips, footage, tutorials, or a specific moment inside a video. It also gives a clear exclusion ('not for general text web search'), but it does not explicitly name sibling alternatives such as `search` or `news_search`, so it stops short of full guidance.

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

• news_searchA
  4.3/5.0
  Behavior4/5

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

  Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false), and the description adds useful behavioral context beyond that: it returns ranked articles with title/url/snippet and behaves like `search` with a fixed topic. This is meaningful context, especially since there is no output schema.

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

  Conciseness4/5

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

  The core purpose is front-loaded and the relationship to siblings is clearly stated. The keyword block at the end is slightly redundant but still useful for search/disambiguation, and the whole description remains easy to scan.

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

  Completeness4/5

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

  For a 17-parameter tool with no output schema, the description covers the essential behavioral contract: what it returns, how it relates to `search`, and when to prefer `broad_search`. Remaining gaps like authentication or rate limits are not critical given the readOnly annotations and fully documented schema.

  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 every parameter. The description reinforces that options like domain/text filters, language, time window, and highlight/full_content exist, but it does not add new meaning beyond what the schema provides. The baseline of 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 states a precise verb and resource: "Search recent news and return ranked articles (title, url, snippet)". It also explicitly distinguishes the tool from siblings by framing it as `search` locked to `topic: news`, so an agent can tell it apart without inspecting schemas.

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

  Usage Guidelines5/5

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

  The description gives explicit when-to-use guidance: "For a single news lookup this is the right tool". It also names the alternative for multi-angle questions (`broad_search` with topic=news) and explains why, which fully covers when not to use this tool.

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

• searchA
  4.7/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint and openWorldHint, and the description aligns with them. It adds useful behavioral context beyond the schema: the result shape, real-time freshness, and the context-cost warning that full_content is 'heavier — costs more context'.

  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 definition is dense and front-loaded: core behavior first, then feature guidance, then usage routing. The keyword block is slightly redundant but not bloat, and every functional sentence earns its place given the tool's 18 parameters.

  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 high-complexity tool with 18 parameters and no output schema, the description is complete: it states the return composition, supported features, filtering capabilities, and cost implications. Sibling routing and keyword aliases further reduce the chance an agent will misuse the tool.

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

  Parameters4/5

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

  Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining how parameters work together—highlight vs full_content trade-off, domain/text filters, language filter, and time-window options—which helps an agent choose the right knobs without merely repeating schema text.

  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 opens with a concrete verb and resource: 'Search the live web and return ranked results (title, url, snippet)' and scopes the tool to 'one focused lookup'. It explicitly differentiates from the main siblings by directing multi-subtopic questions to broad_search and URL reads to extract.

  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?

  'USE FOR a single focused lookup: one fact, one entity, one document' is an explicit when-to-use statement. It also gives when-not-to-use guidance and named alternatives: broad_search for questions spanning independent subtopics and extract for pages where the URL is already known.

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

• image_searchA
  4.8/5.0
  Behavior5/5

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

  The description goes well beyond annotations by disclosing that the tool is in Beta and requires access, that results are ranked, and what fields are returned. It also clarifies the design-topic behavior (structured style summary and html_snippet) and the accepted image formats and size limit, giving the agent a realistic operational picture.

  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 dense and well front-loaded, with the core function, key constraints, and usage guidance near the top. The trailing keyword list is somewhat redundant with the prose, but for a tool with 10 parameters and multiple modes, the length is justified and each section earns its place.

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

  Completeness5/5

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

  There is no output schema, but the description compensates by enumerating the returned fields: title, source page, dimensions, thumbnail, description, summary, and html_snippet in design mode. It also covers access requirements, input modes, and the suggestion to use it for visual references, making the tool callable end-to-end without missing critical context.

  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 meaning on top of the schema by explaining the `topic=design` effect on result structure, the 'pass exactly one' exclusivity rule, and the practical distinction between `image_url` and `image_data`. It does not need to restate every schema detail.

  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 opens with a specific verb and resource — 'Find images on the web by text query OR by a reference image' — and lists the returned result fields. It clearly distinguishes image search from general text web search and from the sibling tools by stating exactly what kind of content it retrieves.

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

  Usage Guidelines5/5

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

  It explicitly states when to use the tool: 'Use this when the user wants pictures, photos, diagrams, screenshots, or visual references — not for general text web search.' It also gives mode-specific guidance for `topic=design`, and explains the mutual-exclusivity rule for `query`, `image_url`, and `image_data` so an agent knows how to choose among them.

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

• broad_searchA
  4.9/5.0
  Behavior5/5

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

  Annotations only declare read-only, open-world, and non-destructive hints. The description adds material behavioral context: cost/latency fan-out proportional to max_queries, results grouped per sub-query and NOT deduplicated, per-sub-query options applying uniformly to all sub-queries, and explicit advice not to loop on disappointing results. This goes well beyond what the annotations provide and sets correct expectations for a high-cost search operation.

  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 long but tightly organized: purpose, use-when, do-not-use, cost, query guidance, results behavior, max_queries scaling, and final routing. Every section earns its place and is front-loaded with the most decision-relevant information first. There is no filler or repetition; the length is justified by the tool's 19-parameter complexity.

  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 complex tool with 19 parameters, nested objects, and no output schema, the description is remarkably complete. It covers the call pattern, cost/latency tradeoffs, query construction rules, result grouping and deduplication behavior, parameter option semantics relative to `search`, and an explicit scale for max_queries. It even addresses the news edge case and tells the agent not to loop news_search. Nothing an agent needs to decide whether and how to call this tool is missing.

  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 still adds value. It warns that query must be one natural-language question (not pre-split), advises resolving pronouns/references first, recommends raising max_queries instead of repeated calls, provides a max_queries scale (3-5 focused comparison, 5-10 multi-facet, 10-20 landscape, 20-30 exhaustive), and tells the agent to raise timeout for large surveys. This is genuinely useful beyond the schema's per-parameter descriptions.

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

  Purpose5/5

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

  The description leads with a specific mechanism: expands the user's question into multiple sub-queries and runs them concurrently. It clearly distinguishes itself from siblings by targeting comparisons, research, surveys, and multi-part questions, and it names exactly what it is not for (single facts, reading pages, A-vs-B). An agent can tell broad_search apart from search, news_search, and extract without opening the schema.

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

  Usage Guidelines5/5

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

  The description provides an explicit USE WHEN list with concrete cases (vendor comparisons, literature reviews, options questions, 3+ independent sub-questions, multi-angle news) and a DO NOT USE list naming alternatives: use `search` for single facts, `extract` for a known URL, and targeted follow-ups instead of re-running broad_search. It also tells the agent when to route to news_search via topic=news. This is comprehensive routing guidance.

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

• extractA
  4.9/5.0
  Behavior5/5

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

  Annotations already mark it read-only, open-world, and non-destructive, and the description adds meaningful behavioral details: query mode returns highlights instead of full body, bare hosts are auto-normalized to https, content is cached when fresh, and results include category and page_structure classifications.

  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 front-loaded with the core purpose and default behavior, then the critical query warning, then routing guidance. Each sentence contributes a distinct fact; the keyword list is slightly redundant but aids discoverability.

  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?

  With no output schema, the description appropriately conveys the return shape by mentioning full_content, highlights, category, and page_structure. It also covers caching, URL handling, and sibling alternatives, giving an agent enough context to invoke the tool 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 description coverage is 100%, so the baseline is 3. The description adds useful operational semantics beyond the schema, especially the query/full-content trade-off and bare-host normalization, though some parameter guidance duplicates the schema's own descriptions.

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

  Purpose5/5

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

  Opens with a specific verb and resource: 'Read one or more web pages by URL and return clean, LLM-ready content (markdown or text).' It also distinguishes itself from search siblings by saying 'Use this when you already have the URL(s).'

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

  Usage Guidelines5/5

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

  Explicitly states when to use the tool and when not to: 'Use this when you already have the URL(s). To find pages first, use search or broad_search.' It also specifies the only condition for passing query and warns that doing so returns partial content.

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