Server Quality Checklist

Tool Scores

• google_ai_modeA
  4.4/5.0
  Behavior5/5

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

  With no annotations provided, the description carries full burden and excels. It discloses unreliability, confident wrongness, the risk of false authority on Google products, the meaning of absent results (available: False vs error/schema_drift), and the slower streaming/polling behavior. This is far beyond a generic tool disclaimer.

  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 longer than necessary but every paragraph and warning earns its place. It is front-loaded with the core purpose, then structured warnings, normal-use pattern, absence behavior, and latency. Bolded headings aid scannability. Slight verbosity prevents a 5.

  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 no output schema and no annotations, the description is remarkably complete. It conveys what the response contains (answer + citations), how to interpret the answer, what absence looks like, and latency expectations. The tool's complexity is high, and the description covers the key edge cases (missing availability, unreliability, comparison to sibling tool) without needing structured output docs.

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

  Parameters2/5

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

  Schema coverage is 0%, so the description must compensate for parameter ambiguity. While 'query' is implicitly described, there is no explanation of the lang or country parameters, their allowed values, defaults, or how they affect results. The mention of region/account relates to availability, not parameter semantics, leaving optional parameters under-specified.

  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 returns Google's AI Mode answer with citations, using a specific verb ('answer') and distinct resource. It distinguishes itself from google_search by positioning AI Mode as an unreliable lead-generation tool, and it explicitly names google_search as the alternative for authoritative sources.

  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 usage guidance: use for orientation on unfamiliar topics, then follow up with google_search for primary sources, and skip for anything load-bearing. It clearly states when not to use it and names the alternative tool, satisfying the highest bar for this dimension.

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

• google_multi_searchA
  4.4/5.0
  Behavior5/5

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

  With no annotations available, the description fully carries the behavioral transparency burden. It discloses sequential execution, anti-bot reasons, approximate timing, failure isolation via an 'errors' key, and early stop on rate_limited. This is rich, non-obvious behavioral detail that goes far beyond a simple 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 front-loaded with the core purpose, then efficiently delivers rationale, behavior, performance expectations, and failure handling. Each paragraph earns its place, with no fluff or redundancy. The structure is logical and scannable.

  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 description covers purpose, usage, performance, sequencing, and error handling, which is substantial for a multi-search tool. However, it omits any description of the successful return value (e.g., result format) and leaves 'pages' and 'personalized' undefined. Given there is no output schema, these gaps slightly detract from completeness, though the overall context is strong.

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

  Parameters2/5

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

  The schema provides only names/types/defaults for 'queries', 'pages', and 'personalized', with 0% description coverage. The description mentions 'queries' only in passing and does not explain the meaning or usage of 'pages' or 'personalized'. Parameters are left ambiguous, and the description fails to compensate for the schema's lack of 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: 'Run several related queries in one call.' It clearly distinguishes from sibling google_search by stating 'Prefer this when researching a topic' and explaining the multi-query nature. This is a clear, differentiated purpose.

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

  Usage Guidelines5/5

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

  The description provides explicit guidance on when to use this tool ('Prefer this when researching a topic') and explains the benefit over repeated single searches. It also clarifies the deliberate sequential execution and its rationale, giving agents a clear decision framework and behavioral expectations.

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

• google_searchA
  4.8/5.0
  Behavior5/5

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

  With no annotations, the description bears the full burden and excels. It discloses failure kinds (auth_expired, schema_drift, rate_limited), cost of with_content (page loads), behavior of strict_dates vs query operators, empty result sets not being errors, and the neutral view for personalized=False. This is exceptionally transparent.

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

  Conciseness5/5

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

  The description is long but deliberately organized: opening summary, argument examples with syntax hints, vertical list, and performance/failure notes. Each paragraph and bullet earns its place; nothing is redundant. The most important facts (what it does, return shape) are front-loaded.

  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 18 parameters, no output schema, and no annotations, this description is remarkably complete. It covers output fields, pagination, date behavior, error kinds, cost/performance trade-offs, and even distinguishes total_matches from returned count. There is no significant missing context.

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

  Parameters5/5

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

  Schema coverage is 0%, so the description must explain all 18 parameters—and it does. It provides examples for site, filetype, exact, exclude, before/after, freshness, verbatim, strict_dates, country, lang, personalized, and details each vertical value. It also explains pages, content_chars, and content_top_n with caveats. This fully compensates for the bare schema.

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

  Purpose5/5

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

  The description opens with a specific verb ('Search Google'), names the resource, and states the output format ('results are {rank, title, url, host, snippet, date}'). It also notes ads are stripped, clearly distinguishing it from sibling tools like google_multi_search or google_fetch. This is a model of purpose clarity.

  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 gives abundant usage context: structured arguments instead of operators, recommended 'web_only' for research, 'ask for depth only when you actually need it', and budget warnings for with_content. However, it never explicitly contrasts with sibling tools (e.g., when to use google_multi_search instead), so it stops short of full exclusion guidance.

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

• google_session_statusA
  4.9/5.0
  Behavior5/5

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

  With no annotations, the description fully carries the behavioral disclosure burden. It explains that the account is read off the page rather than assumed, and that a signed-out session produces a neutral/unpersonalized view. This transparently describes key behaviors without contradiction.

  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 yet information-dense: it front-loads the purpose, then adds usage guidance, and finishes with a behavioral nuance about account detection. Every sentence earns its place without unnecessary 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?

  Despite lacking an output schema, the description effectively communicates what the tool returns: session status, account identity, and the neutral view for signed-out states. For a simple status-check tool, this is complete and actionable without needing to enumerate return fields.

  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?

  The tool takes zero parameters, so the schema is complete with 100% coverage. The description does not need to explain parameter semantics; the baseline of 4 applies.

  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 reports whether the dedicated profile has a live Google session and which account it is. This is a specific status-checking verb+resource, and it is immediately distinguishable from sibling tools that search, fetch, or modify.

  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 explicitly advises calling this tool before relying on personalization, and explains that a signed-out state still works by returning a neutral view. This provides clear when-to-use guidance and practical context, even without explicitly naming alternatives.

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

• google_fetchA
  5/5.0
  Behavior5/5

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

  No annotations are provided, so the description carries the full burden. It discloses boilerplate stripping, markdown output, 5-URL cap, sequential reading with throttling, max_chars truncation behavior (paragraph boundary, `truncated` and `chars_total` fields), and error handling (`ok: false`). This is rich behavioral detail that goes far beyond what the schema reveals.

  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 appropriately sized, with each paragraph serving a distinct purpose: purpose, usage guidance, output behavior, limits/parameters, error handling. It is front-loaded with the core purpose and every sentence contributes value. No 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 tool with no annotations, no output schema, and underspecified parameters, the description covers all essential aspects: purpose, usage boundaries, output format, limits, parameter behavior, and failure modes. It is complete enough for an agent to select and invoke the tool correctly without additional context.

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

  Parameters5/5

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

  Schema has 0% description coverage, so the description must compensate. It does: `urls` is implicitly defined as the web pages to read, and `max_chars` is fully explained (truncates on paragraph boundary, sets `truncated`/`chars_total`). The cap of 5 URLs also adds meaning to the `urls` parameter. Both parameters are semantically clarified.

  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 ('Read web pages as markdown') and immediately distinguishes itself from ordinary HTTP fetch and sibling tools by clarifying its unique value (browser-based fetching for JS-rendered, paywalled, or logged-in content). The purpose is unmistakable and distinctive.

  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 this tool instead of a plain HTTP fetch ('JS-rendered apps, soft paywalls, cookie-walled articles') and when not to ('for a static public page an ordinary fetch is cheaper'). This is a textbook example of when/when-not usage guidance with a named alternative.

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