Server Quality Checklist

Tool Scores

• hasdata_google_serp_news_getGoogleNewsA
  3.8/5.0
  Behavior3/5

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

  Annotations are absent, so the description carries the full burden. It discloses the return payload (article title, snippet, source publisher, published date, thumbnail, URL) and navigation tokens, but does not explicitly state it is a read-only operation, nor mention pagination or rate limits. Adequate but incomplete.

  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 front-loaded with 'Get Google News Results' and then concisely explains query modes and return fields. It is well-structured and free of fluff, though slightly long due to the enumeration of use cases.

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

  Completeness3/5

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

  With 8 parameters, no output schema, and no annotations, the description covers the primary use cases and token navigation, but omits pagination, error handling, and explicit read-only behavior. It is sufficient for basic usage but leaves gaps for deeper agent planning.

  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% and each parameter has a detailed description. The description adds a summary of token usage and examples (e.g., World, Business, CNN, BBC), but largely restates schema info. It does not significantly deepen parameter understanding beyond what the schema already provides.

  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?

  States the specific verb 'Get' and resource 'Google News Results', then elaborates on the many query modes (free-text, topicToken, sectionToken, publicationToken, storyToken) and the return fields. This clearly distinguishes it from siblings like shopping, product, and general SERP 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?

  Explicitly lists use cases (news monitoring, brand/PR tracking, topical aggregators, publisher-specific feeds, story coverage) and explains when to use each token type. It does not explicitly exclude alternatives, but the domain-specific purpose makes the appropriate context clear.

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

• hasdata_google_serp_ai_overview_getAiOverviewResponseA
  3.9/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It does mention the token's 4-minute validity and that the content is lazy-loaded, which adds useful context. However, it does not explicitly state that the operation is read-only or that it has no side effects, nor does it address error handling for expired tokens. The 'fetches' verb implies a GET, but for a tool with zero annotation coverage, this is a moderate gap, earning a 3.

  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 front-loaded with the purpose and then provides necessary detail. It is about three sentences long and each sentence adds value—how it works, what it returns, and when to use it. The use-case list is slightly verbose but still relevant for agent decision-making. It earns a 4 for being well-structured without unnecessary fluff.

  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 simple tool with one parameter, the description covers the essential context: the source of the token, its validity, the output contents, and typical use cases. It does not explain error behavior or pagination, but given the low complexity and absence of an output schema, it is sufficiently complete for an agent to call it correctly. A score of 4 reflects this adequacy.

  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 input schema covers the only parameter (pageToken) with a description that already states its origin and validity. The tool description repeats this information without adding new meaning or providing additional guidance on how to obtain or handle the token. With schema description coverage at 100%, the baseline is 3, and the description does not exceed it.

  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 ('fetches') and resource ('lazy-loaded Google AI Overview block'), and clearly distinguishes this from sibling tools by focusing on the follow-up nature. It explicitly states what it returns (AI-generated answer text, referenced source URLs, expanded subtopic sections), so an agent can understand its unique purpose without ambiguity.

  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 'Use as a follow-up call to Google SERP', which gives a clear context for when to invoke it. It does not explicitly name alternatives or provide exclusions, but it makes the usage pattern (follow-up after obtaining a pageToken) explicit enough to differentiate from initial search calls. A score of 5 would require explicit alternatives, so 4 is appropriate.

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

• hasdata_google_serp_events_getEventInformationA
  3.9/5.0
  Behavior3/5

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

  With no annotations provided, the description must carry the full burden of behavioral disclosure. It mentions pagination and the types of data returned (event title, date/time, venue, links), implying a read-only scraping operation. However, it does not explicitly state that the operation is non‑destructive, nor does it cover error behavior, rate limits, or authentication requirements. The disclosed behavior is sufficient for basic understanding but lacks depth.

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

  Conciseness4/5

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

  The description is structured with a clear opening statement followed by a detailed list of capabilities and use cases. It is front-loaded with the core purpose and efficiently conveys the tool's scope. The use case list adds value without being overly verbose, though a slightly tighter structure could improve conciseness.

  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?

  Given the tool has 8 parameters and no output schema, the description is quite complete. It explains the purpose, the parameters in a summarized way, the return fields, and the intended use cases. It lacks explicit notes on limitations (e.g., rate limits, authentication) but covers the essential information an agent needs to decide when to use the tool and what to expect. The presence of a comprehensive parameter schema also contributes to completeness.

  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 all parameters are already well documented in the input schema. The description adds context by grouping parameters (e.g., date filters, virtual-event toggle) but does not introduce meaning beyond what the schema provides. It reinforces the purpose of the htichips parameter but does not compensate for any missing parameter details. 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 clearly states the tool scrapes the Google Events vertical for a query and location, listing specific filters and return fields. It explicitly names the resource (Google Events results) and distinguishes from siblings by focusing on events. The title reinforces the purpose.

  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 provides explicit use cases such as event-discovery chatbots, local aggregators, calendar sync, and competitive monitoring, giving clear context for when to use this tool. It does not explicitly mention alternatives or when not to use it, but the strong focus on events implicitly distinguishes it from sibling tools like general SERP or shopping searches.

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

• hasdata_google_serp_product_getProductInformationA
  3.9/5.0
  Behavior3/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 describes what it does and what it returns (depending on searchType) but does not mention error conditions, rate limits, authentication needs, or any side effects. It is a GET operation, but lacks disclosure of potential limitations or response formats beyond the stated content.

  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 reasonably concise, starting with a redundant header line but then providing useful details. It is structured into purpose, output, and use cases. The first sentence is slightly redundant with the title, but the rest is efficient.

  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?

  Given 9 parameters and no output schema, the description explains return content well ('product title, images, price, ratings, specs, merchant offers... review text'). It does not mention pagination nuances beyond what the schema covers, but is generally complete for an agent to invoke 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 coverage is 100%, so the baseline is 3. The description mentions searchType and filters, but the schema already describes the filter parameter in detail. The description adds context about use cases but does not significantly enhance parameter understanding beyond what the schema already provides.

  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 specific verb ('Pulls') and resource ('product data from Google Shopping'), and explicitly differentiates by productId and searchType. It clearly distinguishes from sibling tools like shopping search or AI mode by focusing on product-level details.

  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 provides explicit use cases ('price intelligence, catalog enrichment, review mining, competitor spec comparison, building shopping assistants'). It does not explicitly mention when not to use it or name alternative tools, but the use cases imply the appropriate context.

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

• hasdata_google_serp_short_videos_getShortVideosSearchResultsA
  3.9/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'scrapes' (indicating a read-only external fetch), pagination, and the returned fields. However, it omits potential behavioral specifics such as rate limits, authentication requirements, or whether results are cached or live. While not misleading, it lacks depth on operational constraints.

  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 well-structured and front-loaded with the core action and scope. The first sentence is direct, followed by a concise list of parameters and use cases. It is slightly verbose with the five-item use-case list, but overall it is efficient and avoids unnecessary fluff.

  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?

  Given the tool has 9 parameters and no output schema, the description is sufficiently detailed. It names the output fields (title, thumbnail, duration, etc.) and covers the main parameter groups. It does not mention pagination limits or size, but these are minor and likely not required for an agent to invoke it correctly. Overall, it provides enough context for effective use.

  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 input schema has 100% coverage with detailed descriptions for every parameter. The description adds only high-level categorization (location/uule, country gl/cr, language hl/lr, device type, page), which is useful for grouping but does not explain nuances like the difference between gl and cr or hl and lr beyond what the schema already provides. Since the schema carries the load, the description adds marginal semantic value.

  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 explicitly states what the tool does: it scrapes the Google Short Videos carousel for a query, listing the specific content sources (TikTok, YouTube Shorts, Instagram Reels) and the types of results returned. The name and title reinforce this, but the description adds detail that distinguishes it from sibling tools focused on products, shopping, news, or standard search results.

  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 lists concrete use cases (short-form content discovery, viral-trend monitoring, influencer research, cross-platform aggregation, and sourcing clips for LLM responses), making the intended usage clear. It does not explicitly mention alternatives, but the sibling tools are semantically distinct (e.g., news, products), so the usage context is unambiguous. Lacks explicit 'when not to use' guidance, but the purpose is narrowly defined.

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

• hasdata_google_serp_ai_mode_getAiModeResponseA
  4.1/5.0
  Behavior4/5

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

  Without annotations, the description carries the full burden. It transparently lists the response components (conversational text, cited links, subtopic breakdowns, follow-up suggestions, subsequentRequestToken) and mentions multi-turn continuation via the token. It implies a read-only GET operation, which is reasonable for a SERP tool. However, it does not disclose potential rate limits, authentication requirements, or error behavior, which would be expected from a tool with no annotations.

  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 a single, well-structured paragraph that starts with the core purpose, then details return fields, and ends with use cases and examples. It is informative but not overly verbose—the examples serve a practical purpose. It earns its place by providing both high-level intent and concrete invocation examples, though it could be slightly tightened without losing value.

  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?

  Given no output schema and no annotations, the description compensates by enumerating the expected response fields (conversational text, cited source links, subtopic breakdowns, follow-up suggestions, subsequentRequestToken) and giving example queries. It does not cover every parameter's nuances or error handling, but it gives an agent enough context to decide when to use the tool and what to expect. The lack of an output schema but clear return list supports a 4.

  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 baseline is 3. The tool description does not add detailed parameter semantics beyond the schema, but it does provide example queries for 'q' (e.g., 'Who is the CEO of HasData?') and indirectly references 'subsequentRequestToken' and 'continuable' via the 'multi-turn continuation' phrase. This adds some value, but it does not fully compensate for the schema's already-complete coverage, so a 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 opens with a clear verb+resource ('Get AI Mode SERP Results') and elaborates on what it captures ('Gemini-powered AI Mode answers from Google Search') and what it returns (conversational text, source links, subtopic breakdowns, follow-up suggestions, subsequentRequestToken). This distinguishes it from siblings like ai_overview_getAiOverviewResponse by emphasizing 'AI Mode' and 'Gemini-powered', making the tool's niche unambiguous.

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

  Usage Guidelines4/5

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

  The description provides explicit use cases such as 'AI-answer monitoring', 'citation tracking', 'content research agents', and 'person/company data enrichment', with concrete example queries. While it does not list alternative sibling tools or explicitly state when not to use it, the context is clear enough for an agent to infer appropriate usage. The absence of exclusions lowers it slightly from a 5.

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

• hasdata_google_serp_immersive_product_getImmersive_e29f691177A
  4.1/5.0
  Behavior3/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 what is returned (offers, specs, images, ratings, nextPageToken) and the moreStores expansion behavior, which is useful. However, it does not mention pagination mechanics, error cases, response size, or any limits, leaving behavioral gaps for a tool with zero annotation coverage.

  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?

  A single information-dense paragraph that front-loads the core action and parameter semantics. No wasted sentences, though it packs many return fields into one long clause that could be lightly restructured for scanability.

  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?

  With no output schema and no annotations, the description lists the return content and parameter behavior, covering the essential call context. It is reasonably complete for a read-style tool, though it omits error handling and prerequisite clarification beyond the token requirement.

  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%, which sets a baseline of 3, but the description adds real value on top: it quantifies moreStores ('up to ~13 merchants instead of 3-5') and explains nextPageToken's role in paginating stores. This enriches the schema's terse definitions meaningfully.

  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 names a specific verb ('Expands the Google Shopping Immersive Product pop-up') and resource, clearly distinct from the siblings (search results, AI mode, events, news). An agent can tell this tool apart immediately because it is the only one tied to the immersiveProductPageToken pop-up expansion.

  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?

  Lists concrete use cases ('price-comparison bots, merchant discovery, dropshipping research, aggregating full offer lists'), giving clear context on when to call it. It stops short of explicit exclusions or 'when not to use' routing to alternatives, which would make it fully complete.

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

• hasdata_google_serp_serp_light_getSearchResultsA
  4.1/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden, and it does disclose key traits: it omits rich blocks, returns only organic results, and supports specific filters. However, it doesn't mention error handling, rate limits, or potential staleness of data—common concerns for scraping tools. It adds value but isn't exhaustive.

  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 well-structured and front-loaded: it states the core purpose, then omissions, capabilities, return format, and use cases. Every sentence contributes value, but it's slightly long given the detailed schema already available. Still, no fluff.

  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?

  Given the 12 parameters, detailed schema, and no output schema, the description covers the essential decision-making info: what it returns, key filtering options, and typical use cases. It doesn't explicitly explain pagination mechanics (though schema does) or edge cases, but the provided context is sufficient 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.

  Parameters4/5

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

  Schema coverage is 100%, so baseline is 3, but the description groups parameters into meaningful categories (location/uule, country, language, filters, pagination), giving agents a high-level understanding of how they combine. It adds conceptual clarity beyond the schema's individual 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 clearly states the tool is a lightweight Google Search scraper that returns only organic results, explicitly listing what it omits (AI Overview, knowledge graph, PAA, etc.) and what it returns (title, link, snippet, position). This makes it readily distinguishable from siblings like serp_getSearchResults or news/shopping 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?

  Explicit use cases are given: high-volume keyword monitoring, bulk rank tracking, backlink discovery, and any workflow where only the ten blue links matter. This implies when not to use it (when rich SERP blocks are needed), though it doesn't explicitly name the alternative tool like hasdata_google_serp_serp_getSearchResults. Clear context but no formal exclusion.

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

• hasdata_google_serp_shopping_getSearchResultsA
  4.1/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It discloses the response fields (product title, price, merchant/source, rating, etc.), the filtering mechanism via shoprs and hasdata_link, and pagination via start. It also mentions that tokens can be fed into the Immersive Product API. It does not mention rate limits or auth, but those are often outside tool descriptions. The GET method in the title implies read-only, and the description aligns. It adds substantial behavioral context 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.

  Conciseness4/5

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

  The description is two paragraphs, efficiently front-loading the purpose and then detailing output fields and use cases. It avoids redundancy and keeps each sentence informative. Slightly longer than necessary but still well-organized and 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?

  Given the tool's complexity (10 parameters, nested filter structure, pagination), the description covers the essential information: what it returns, how to use filters, and how to connect to downstream APIs. It lacks explicit error handling or rate limit info, but for an agent selecting and invoking the tool, the provided context is sufficient for correct usage.

  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 each parameter is already well-documented in the schema. The tool description adds some high-level context (e.g., 'offset pagination' for start, 'shoprs filter-helper IDs' for shoprs, 'location/uule' for location), but it does not significantly deepen the meaning beyond what the schema already provides. It meets the baseline for high coverage.

  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 it scrapes Google Shopping listings for a query, and lists specific filters and return fields. It distinguishes itself from sibling tools by explicitly focusing on 'Shopping Search Results' as opposed to general SERP, news, events, etc. The verb 'Get' and resource 'Shopping Search Results' are specific and unambiguous.

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

  Usage Guidelines4/5

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

  The description provides clear use cases: e-commerce price tracking, catalog building, promotion discovery, and feeding productIds into the Product API or tokens into the Immersive Product API. It does not explicitly state when NOT to use it or compare to alternatives, but the use cases are sufficiently contextual to guide an agent. It lacks explicit exclusions or mention of sibling tools, so it stops short of a 5.

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

• hasdata_google_serp_serp_getSearchResultsA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It clearly states what the tool returns (organic results, ads, knowledge graph, related searches, People Also Ask, local pack, featured snippets, AI Overview pageToken) and examples of query patterns. It does not mention rate limits, error handling, or side effects, but for a read-only search scraper it is sufficiently transparent about its behavior.

  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 long but dense, front-loaded with the core purpose and then expanding into features and use cases. It uses a single flowing paragraph without bullet points, but each clause adds information. It is not excessively verbose and every sentence earns its place, though a more structured layout would improve scannability.

  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 tool with 19 parameters and no output schema, the description covers a lot: use cases, return types, and example queries. It does not explicitly address edge cases, error responses, or limitations, and it does not differentiate clearly from sibling tools, but the core functionality is well documented and the schema fills in parameter details.

  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, but the description adds meaning beyond the schema by grouping parameters (location/uule, country, language, domain, device type, safesearch, time/date filters, tbm verticals) and illustrating with real-world queries like 'Roman Milyushkevich LinkedIn' and 'HasData CEO'. This adds semantic value that helps an agent map parameters to use cases.

  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 clear verb-resource pair ('Get Google Search Results') and then enumerates a vast feature set that distinguishes it from siblings. Phrases like 'Full-featured Google Search scraper' and the list of supported filters and result types (organic, ads, knowledge graph, People Also Ask, AI Overview) make it immediately obvious this is the comprehensive SERP tool compared to niche siblings such as serp_light.

  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?

  It provides explicit use cases: SEO rank tracking, keyword research, SERP-feature monitoring, competitor analysis, grounding LLMs, and especially person/company data enrichment with concrete examples. However, it never contrasts itself with the sibling serp_light or states when to choose this over other SERP tools, so it lacks explicit when-not guidance and alternatives.

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