Google Search Remote MCP Server

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

Annotations already declare read-only, open-world, non-destructive behavior, lowering the disclosure burden. The description adds useful behavioral detail beyond annotations: it returns conversational response text, cited source links, subtopic breakdowns, and a subsequentRequestToken when continuable is set for multi-turn continuation.

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 first two sentences are front-loaded and earn their place by specifying the operation and return fields. The remainder is an overlong, overlapping list of use cases and examples ('person/company data enrichment', 'lead enrichment, sales research, people search, and filling in contact/attribute gaps for CRM records') that bloats the definition without adding distinct decision value.

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?

There is no output schema, so the description carries the return-value burden and mostly succeeds by naming the main response components. It does not cover error handling, authentication, or rate limits, but for a read-only scraping endpoint with fully documented parameters and clear safety annotations, this is close to complete.

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 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining the relationship between continuable and subsequentRequestToken for multi-turn AI Mode continuation, though it does not expand on q, gl, hl, uule, or location.

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: 'Get AI Mode SERP Results' and 'Captures Gemini-powered AI Mode answers from Google Search.' It clearly distinguishes the tool from generic Google SERP and AI Overview siblings by naming the AI Mode/Gemini conversational answer output.

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 usage contexts ('Use for next-gen search interfaces, AI-answer monitoring, citation tracking, content research agents...') and concrete examples like `Who is the CEO of HasData?`. It does not, however, name when-not-to-use it or explicitly route the agent to sibling alternatives such as ai_overview or regular SERP 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?

Annotations already declare readOnly/openWorld/non-destructive, so safety is covered; the description adds the lazy-loaded nature, the 1-minute token window, and the shape of the payload (answer text, source URLs, expanded subtopics). It does not describe failure behavior when the token expires, which is the one notable gap.

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 short title line followed by a dense but purposeful paragraph; every sentence carries either mechanism, timing, or use case. Slightly verbose in the final list of use cases but not wasteful.

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 no output schema, the description correctly takes on the burden of describing the return payload, and it does so at a useful level of detail. A brief note on token-expiry failure handling would make it fully complete.

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?

Only one parameter and schema coverage is 100%, so the schema already documents pageToken fully. The description repeats the token's origin and 1-minute validity rather than adding format or edge-case detail 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?

States a specific verb (fetches) and resource (the lazy-loaded Google AI Overview block) and explains the mechanism (via a pageToken from Google SERP). An agent can distinguish this from hasdata_google_serp_serp_getSearchResults because the description frames it as a dependent follow-up rather than a primary search.

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 positions the tool as a follow-up call to Google SERP and names three concrete use cases (SEO AI-citation tracking, fact-checking, LLM grounding). No explicit 'do not use when' or named sibling alternative, but the context is unambiguous.

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?

Annotations only cover the safety profile (readOnly/openWorld/non-destructive), and the description adds real behavioral value beyond them: it enumerates the returned fields (venue, map link, ticket sources with official/unofficial flags, primary ticket link) and discloses a time-sensitive constraint — the token expires a few minutes after being minted, so it must be called promptly.

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, front-loaded with the core action and then the source/expiry, with no filler. Slightly dense but each sentence carries information an agent needs.

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 no output schema, the description carries the return-value burden and does so fully, plus the expiry constraint and the token's origin. Nothing essential for a correct single-parameter lookup 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 100%, so the single parameter is already documented; baseline would be 3. The description earns above baseline by clarifying that the token can also be taken from the adjacent ready-to-call `hasdataLink`, a detail the schema does not mention.

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: 'Looks up a single Google event by the pageToken'. It also scopes the input to the `eventsResults` array of a `google/serp` response, differentiating it from the sibling search tools that return the SERP itself.

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 clear context ('Use to enrich an events search result with full venue and ticketing information') and states the prerequisite source of the token. It implicitly excludes using it for what the SERP widget already shows inline, but never names an explicit alternative tool or a when-not condition.

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?

Annotations already cover safety (readOnlyHint, non-destructive, openWorld); the description adds real behavioral value by disclosing that moreStores raises the merchant count from the default 3–5 to ~13 and that the nextPageToken paginates stores. It stops short of describing rate limits or error behavior, so a 4 rather than 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-loads the core action and expands the token context in the second sentence; the merchant-count and pagination notes are dense but relevant. The use-case list at the end is mildly padded but not wasteful.

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 no output schema, the description carries the return-value burden and does so well: multi-store offers (merchant, price, shipping, URL), specs, images, ratings, and storesNextPageToken. Missing only failure modes or how much the token payload varies, but it is otherwise sufficient to call the tool 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?

Schema description coverage is 100%, so all three parameters are already documented in the schema, including the 3–5 vs ~13 store behavior that the description repeats. The description adds no format, constraints, or edge cases beyond what the schema states, so baseline 3 applies.

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 ('Expands the Google Shopping Immersive Product pop-up given an immersiveProductPageToken'), which is concrete and actionable. It implicitly distinguishes itself from the generic sibling getProductInformation by scoping to the immersive pop-up, but never names that sibling, so the differentiation is left to inference.

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 'Use for price-comparison bots, merchant discovery, dropshipping research' list describes audiences/use cases rather than conditions for selecting this tool over alternatives like google_serp_shopping or google_serp_product. No when-not-to-use or prerequisite (e.g., where the token comes from) is stated beyond the token's origin.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavioral context by disclosing the return payload (title, snippet, source, published date, thumbnail, URL, navigation tokens) and the token-based mode switching, which annotations do not convey. It omits rate limits, pagination, and auth requirements.

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?

Well front-loaded: the lead line names the resource before the retrieval-mode detail, and the use-case sentence is placed last. It is dense but each sentence (modes, return fields, use cases) carries distinct information; only the redundant opening echo of the name is mild 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?

For an 8-parameter read tool with no output schema, the description covers the retrieval modes, the mutual-exclusion constraints among tokens, and the return contents, which is enough for an agent to invoke it correctly. Missing only secondary operational detail such as pagination or result limits, which is acceptable given rich schema coverage and safety annotations.

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 100%, so baseline is 3; the description adds a mode-selection framing by grouping the tokens into named retrieval strategies and clarifying that storyToken is a 'full-coverage cluster with sort by relevance/date' (explaining the so parameter's purpose). It repeats several schema examples rather than supplying new syntax, so it only modestly exceeds baseline.

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 ('Retrieves') and resource ('Google News results') and enumerates the five retrieval modes (free-text query, topicToken, sectionToken, publicationToken, storyToken), making the scope concrete. However, it never names or contrasts with siblings like serp_getSearchResults for non-news web results, so an agent must infer the news-only boundary from the tool name.

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 use cases ('news monitoring, brand/PR tracking, topical aggregators, publisher-specific feeds, and drilling into full story coverage'), giving clear triggering context. It stops short of when-NOT-to-use or naming an alternative sibling (e.g. general SERP search), so it does not reach the 5 bar.

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?

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description usefully notes that the returned payload varies with searchType and enumerates the returned fields, but adds no auth, rate-limit, or pagination caveats beyond what the schema's 'start' description already supplies.

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?

It is three dense sentences that front-load the core action and then summarize inputs before closing with use cases. Every sentence contributes, though the parenthetical filter gloss in sentence one is slightly redundant with the schema and could be trimmed.

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 nine-parameter read tool with full schema coverage but no output schema, the description does the necessary work of describing the return payload (title, images, price, ratings, specs, merchant offers, review text) and its dependence on searchType. What remains thin is the absence of any guidance on failure/empty cases, but overall it is sufficient 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?

With schema description coverage at 100%, the schema already documents all nine parameters thoroughly, including enum values and the filter grammar. The description echoes the searchType values and filter categories (free shipping, used-condition, sort options) but introduces no syntax or semantics beyond what the schema provides, so the baseline 3 is appropriate.

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 states a specific verb and resource: it 'pulls detailed product data from Google Shopping by productId,' which is a concrete scope. The 'by productId' phrasing implicitly distinguishes it from the search-oriented siblings like shopping_getSearchResults, but it never names those alternatives directly, so differentiation is inferred 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?

It gives clear usage context via concrete scenarios (price intelligence, catalog enrichment, review mining, competitor spec comparison, shopping assistants). However it offers no when-not conditions and never points the agent to a sibling tool, so selection between this and the shopping search tools is left to inference.

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?

Annotations already declare readOnly/openWorld/non-destructive, so the safety profile is covered. The description adds genuine behavioral context beyond annotations: the full set of returned features (ads, knowledge graph, PAA, local pack, AI Overview pageToken) and the constraint that 'num' is capped at 10 without tbm. It does not cover rate limits or auth, but it goes well beyond the safety hints.

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 first sentence is front-loaded, but the body is one extremely long run-on sentence that packs features, parameters, use cases, and a long enrichment example list together. Every clause is informative, yet the density and example enumeration make it harder to parse than necessary.

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?

There is no output schema, so the description must describe return values — and it does, listing organic results, ads, knowledge graph, related searches, PAA, local pack, featured snippets, and AI Overview token. With all parameters documented in the schema, the definition is complete enough to invoke 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?

Schema description coverage is 100%, so the schema already documents all 19 parameters in detail. The description adds marginal value by grouping parameter capabilities (location/uule, gl, hl/lr, tbs filters, tbm verticals, offset/num) and noting the num/tbm interaction. Baseline 3 is appropriate since the schema does the heavy lifting.

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 states a clear verb+resource ('Get Google Search Results', 'Full-featured Google Search scraper') and enumerates the verticals and features it covers. It implicitly contrasts with lighter siblings via 'Full-featured', but never names an alternative tool (e.g., serp_light, bing_serp), so an agent must infer the distinction.

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?

It provides explicit use-case contexts — SEO rank tracking, keyword research, SERP-feature monitoring, competitor analysis, LLM grounding, and person/company enrichment with concrete example queries. However, it offers no when-not guidance or named alternative (e.g., use bing_serp or serp_light instead).

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?

Annotations cover the safety profile (readOnly, non-destructive, open-world), and the description layers on substantial extra context: the complete set of returned blocks, the blocks explicitly excluded from this layout, the num cap, and the performance/cost tradeoff. This is far beyond what the annotations provide.

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 purpose is front-loaded and every sentence carries information (returned blocks, excluded blocks, parameters, use cases). It is dense and slightly run-on, but no sentence is filler, so it stays efficient for a tool of this complexity.

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 no output schema, the description carries the burden of describing return values and does so thoroughly, enumerating every result block returned. Combined with full parameter coverage and explicit limitations, an agent has everything needed to invoke it 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?

Schema description coverage is 100%, so parameters are already fully documented, establishing a baseline of 3. The description summarizes the supported filters (gl, hl/lr, domain, safesearch, tbs with qdr/cdr, offset/num), but it introduces a discrepancy by stating 'num capped at 10' while the schema declares num ranges from 10 to 100, which could mislead an agent on pagination.

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 ('Get Google Light Search Results') and immediately distinguishes itself from the full SERP API sibling by describing the lightweight no-JS layout and its cheaper/faster tradeoff. An agent can tell it apart from hasdata_google_serp_serp_getSearchResults 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?

Explicitly names intended use cases (high-volume keyword monitoring, bulk rank tracking, backlink discovery, AI Overview presence tracking) and, by listing the block types it does NOT serve (shopping, news, videos, jobs), implicitly signals when the full SERP API should be used instead. It stops short of naming the alternative tool explicitly or stating a hard when-not rule.

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?

Annotations already declare readOnlyHint, openWorldHint, and destructiveHint, so the safety profile is covered. The description adds real behavioral value by enumerating the returned fields (title, price, merchant, rating, reviews, thumbnail, productId, immersiveProductPageToken) and explaining the filter-chip/hasdata_link refinement loop, which is not derivable from the schema. It does not mention auth or rate limits, keeping it at a 4.

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-loads the core action in sentence one and packs filter dims and return/usage context into sentence two with no filler. It is dense but every clause carries information, so it is appropriately sized rather than merely short.

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 10 parameters, no output schema, but full annotation coverage, the description does the heavy lifting an agent needs: it enumerates the return payload and the downstream id/token handoffs. It leaves pagination mechanics and error behavior to the schema/annotations, which is acceptable given no output schema forces it to describe returns itself.

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 100%, so the schema already documents all 10 parameters in detail. The description groups them ('location/uule, country/language/domain, time/date filters, device type, shoprs filter-helper IDs, and offset pagination') but adds no syntax or format meaning beyond what the schema provides, so the baseline 3 applies.

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 ('Scrapes Google Shopping listings for a query') and the scope of filters it accepts. It also distinguishes itself from adjacent tools by naming the Product API and Immersive Product API as consumers of its output. An agent can tell it apart from the generic serp_getSearchResults sibling by the explicit 'Shopping' vertical.

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 concrete when-to-use contexts ('e-commerce price tracking, catalog building, promotion discovery') and names alternatives, explaining that productIds feed the Product API and tokens feed the Immersive Product API for deeper data. It stops short of stating explicit exclusions (e.g. when to prefer the plain SERP instead), so it is clear context without full routing rules.

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?

Annotations already establish read-only, non-destructive, open-world behavior, so the bar is lower. The description goes on to disclose the return surface (title, thumbnail, duration, source platform, channel, direct URL, platform video ID, profile handle) and the hasdataLinks follow-up capability, which is genuinely useful behavioral context. It omits rate limits and response envelope details, keeping it below 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?

The definition is front-loaded with the core action, then output, then use cases — a logical progression with no filler sentences. Length is proportionate to a 10-parameter tool with no output schema.

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 no output schema, the description takes on the burden of describing return fields, which it does thoroughly, and it covers the parameter envelope and intended use cases. An agent has everything needed to invoke it 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?

Schema description coverage is 100%, so the schema already documents all 10 parameters in detail and the baseline is 3. The description groups them (location/uule, country gl/cr, language hl/lr, device type, page pagination, tbs filters), which adds light interpretive structure but does not clarify the gl-vs-cr or hl-vs-lr distinction beyond what the schema already says.

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 states a specific verb and resource — scraping the Google Short Videos carousel (explicitly TikTok, YouTube Shorts, Instagram Reels) — which is concrete and distinguishable from the generic google_serp_serp_getSearchResults and platform-specific tiktok/youtube siblings. An agent can tell what this returns 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.

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

It gives clear context for use (short-form content discovery, viral-trend monitoring, influencer research, cross-platform aggregation, sourcing clips for LLM summarization/embedding). It does not, however, state when NOT to use it or explicitly name alternatives such as the general SERP or TikTok search tools, so routing between overlapping siblings is left to inference.

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