Searchapi

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

Annotations already provide readOnlyHint=true and destructiveHint=false. The description adds that the tool returns titles, sources, thumbnails, and publication dates, which is useful behavioral context beyond the annotations. It does not mention pagination behavior or rate limits, but the read-only nature is covered.

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 description is three sentences with no fluff. It front-loads the core purpose, then lists return fields, and gives a brief usage hint. Every sentence earns its place.

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?

Given there is no output schema, the description partially describes the return structure (titles, sources, thumbnails, dates) but not the exact shape. The parameter schema is comprehensive, covering market codes, time periods, etc. The description is adequate for a simple read-only search tool, though it could be slightly more explicit about the result format.

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 parameters (q, page, sort_by, market_code, time_period) are documented in the schema. The description adds no parameter-specific details beyond the schema, aligning with the baseline of 3 for full coverage.

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 clearly states the verb ('Search') and resource ('news articles using Bing News'), and specifies what is returned. It is distinctly a news-specific search, differentiating it from sibling tools like bing_search (general web search) and the google_* search variants.

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 description gives a usage context ('Good for finding recent news coverage and trending stories') but does not explicitly name alternatives or conditions for when not to use it. It implies the use case but does not mention bing_search as a fallback for general web queries.

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, idempotentHint=false, destructiveHint=false, so the safety profile is fully covered. The description adds only that results include organic results and related searches, which is modest extra context beyond the structured fields.

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?

Two short sentences, front-loaded with the core action, with no redundancy. The trailing 'and more' is mild filler but the overall sizing is appropriate for a simple search tool.

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 single-required-parameter read-only search tool with 100% schema coverage and no output schema, the description plus structured fields give the agent enough to invoke correctly. It could be stronger on result format and pagination expectations, but nothing essential 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 description coverage is 100%, including a detailed next_page_token precedence note, so the schema carries parameter meaning. The description adds no syntax, format, or interaction detail beyond what the schema already documents; 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 ('Search the web using Bing') and names the return content ('organic results, related searches'). The 'Alternative to Google' line gestures at differentiation from search siblings like google_search_light, but never names which sibling to prefer when.

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 'alternative to Google... with different ranking algorithms' line implies the choice condition (use this when you want Bing's ranking) but never states explicit when-to-use or when-not guidance, nor names the competing sibling tools directly.

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 and destructiveHint=false, covering the safety profile. The description adds that it returns organic results, which is a useful behavioral trait beyond annotations. It does not discuss pagination, result count, or any quirks, but the annotation coverage lowers the burden. No contradiction with annotations.

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 description is two concise sentences with zero wasted words. The core purpose is front-loaded, and the privacy differentiation follows immediately. Every sentence earns its place.

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 simple search tool with fully documented parameters, the description adequately states what it does and the nature of results (organic). Given there is no output schema, it could mention more about the return format or any 'light' limitations, but it is sufficient for an agent to decide whether to call it. Slightly more detail on output would push it to a 5.

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 (q, locale, time_period) are fully documented in the schema itself. The description adds no additional parameter-specific meaning, so the baseline score of 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: 'Search the web using DuckDuckGo' and notes 'Returns organic results.' It differentiates from Google by calling itself a 'Privacy-focused alternative to Google,' which helps distinguish it from google_search_light. However, it does not explicitly differentiate from other search engines like bing_search, so it falls short of a perfect score.

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 description provides clear context by positioning the tool as a privacy-focused alternative to Google, implying it should be used when privacy or unbiased results matter. It does not explicitly state when not to use it or list alternative tools, but the privacy angle is a meaningful usage signal for an agent.

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 adds valuable behavioral context beyond annotations: it discloses that the tool resolves mobile share links and canonicalizes URLs automatically, and that it returns public information only. It doesn't mention rate limits or pagination, but for a read-only fetch tool the key behaviors are disclosed.

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 description is two sentences: the first states the core function and return data, the second gives the parameter selection rule. Every sentence earns its place, and the most important operational guidance (prefer url) is front-loaded in the second sentence. No filler or redundancy.

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 read-only tool with 3 optional parameters, 100% schema coverage, and no output schema, the description covers the essential context: what it fetches, what it returns, and how to choose parameters. The only minor gap is that it doesn't explicitly state what happens if multiple parameters are provided or if none are provided, though 'exactly one' implies the constraint. Overall it's complete enough 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.

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 three parameters thoroughly. The description adds value by prioritizing url over the others and explaining the resolution behavior, which complements the schema's per-parameter descriptions. It doesn't add much beyond the schema, but the baseline of 3 is exceeded by the explicit preference rule and the 'exactly one' constraint.

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 ('Fetch') and resource ('public business page information from Facebook'), and enumerates the exact data returned (name, category, address, phone, website, ratings, reviews, followers, photos). It clearly distinguishes itself from sibling tools like instagram_profile and tiktok_profile by focusing on Facebook business pages.

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 description gives explicit selection guidance: 'Provide exactly one of page_id, username, or url — prefer url when the user pasted any Facebook link (including mobile share links), since the tool resolves the canonical page automatically.' This tells the agent when to use each parameter and why url is preferred, which is actionable routing guidance.

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 read-only, non-destructive, open-world behavior. The description adds useful behavioral context beyond that: responses include source citations and reference links, and conversation_token preserves prior-turn context. It does not address rate limits or failure modes, but it meaningfully supplements the annotations.

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 description is front-loaded with the core purpose, then organized into clear call modes and follow-up behavior. Every sentence contributes directly to correct invocation, with no filler.

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 four-parameter tool with no output schema and rich annotations, the description covers the essential calling patterns and follow-up behavior. It could add a bit more about error handling or constraints, but nothing critical for correct invocation 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 baseline is 3, but the description adds synthesis beyond individual field descriptions: it groups q and url into distinct call modes and explains that conversation_token is used with a follow-up question in q. That combination guidance is useful and not fully redundant.

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: 'Get Google's AI-generated responses (AI Overviews) with source citations and reference links.' This distinguishes it from ordinary search siblings such as google_search_light, though it does not explicitly name them or state exclusions.

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 clearly explains two invocation modes — text search requiring q and image analysis requiring url — and explains how to continue a conversation. It does not compare against sibling alternatives like google_lens or google_search_light, so it is clear but lacks explicit alternative routing.

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 and destructiveHint=false, so safety is covered. The description adds behavioral context beyond annotations by stating that it returns a price-per-day list and that it shows the cheapest price. It doesn't mention potential quirks like date range limits or response format details, but given the strong annotation coverage and the clear scope, this is sufficient.

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?

Two sentences with zero fluff. The core action and return are front-loaded in the first sentence; the sibling differentiator occupies the second. Every word earns its place.

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?

Given the tool has 18 parameters, 3 required, no output schema, and moderate complexity, the description provides sufficient high-level context: what it returns (list of dates with prices), when to use it, and how it differs from the round-trip sibling. For a read-only calendar lookup, this is complete enough for an agent to invoke it without misunderstanding.

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 fully documents all parameters and their defaults. The description adds no parameter-level semantics beyond what the schema already provides (e.g., outbound_date's role as the start date). Baseline 3 applies because structured data carries the burden.

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 ('Get a price calendar') with a precise resource ('cheapest one-way flight price for each day'). It clearly distinguishes itself from the sibling google_flights_calendar_round_trip by naming it explicitly. An agent can identify this tool's unique purpose 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?

The description gives an explicit use case: 'useful for finding the cheapest departure day when you have flexible travel dates.' It also explicitly names the round-trip alternative and the condition for choosing it ('For round-trip price calendars... use google_flights_calendar_round_trip instead'). No inference is required.

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 indicate read-only and open-world, so the description doesn't need to repeat that. The description adds that it returns a grid of date pairs, which is useful. It doesn't disclose details like rate limits, but the open-world hint covers some of that.

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 description is two sentences, front-loaded with the core purpose and includes a clear pointer to the sibling tool. No wasted words.

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?

Given the complexity (19 params, 2 enums, no output schema), the description doesn't explain the return structure in detail, but it's not critical since the tool is read-only. It provides the key context: flexible date ranges and the grid output. Could mention that the calendar expands on the dates provided, but that's already in the schema.

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 parameters are well-documented. The description itself doesn't add much beyond what the schema already provides. The baseline is 3, and there's no additional meaning added.

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 clearly states it provides a price calendar for round-trip flights, specifically a grid of date pairs with prices. It distinguishes itself by mentioning the one-way alternative.

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 explicitly states when to use it (when both departure and return dates are flexible) and names the one-way tool as an alternative. It doesn't explicitly mention other flight tools like google_flights_round_trip, but the context is clear.

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 and destructiveHint=false, so the tool's safety profile is covered. The description adds behavioral context beyond annotations: it explains that for cities it 'searches all airports in that city' and returns kgmid, which is not in the schema. It also discloses the output format. This enriches the behavioral picture, though it could mention potential multiple results or no-match scenarios.

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 description is well-structured with a bulleted list of return types, a clear required-parameter note, and a usage tip. It is concise, front-loads the purpose, and every sentence adds value. The note about common IATA codes is a useful addition without bloating the text.

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 must explain return formats, which it does (IATA and kgmid). It also clarifies the required parameter and provides a usage example. For a simple two-parameter search tool, this is largely complete, though it doesn't cover edge cases like multiple matches or empty results. The overall complexity is low, so this is sufficient.

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?

The schema description coverage is 100%, so both parameters (q and search_type) are already documented in the input schema. The description adds an example for q and clarifies the output behavior for cities, but these are largely redundant with the schema descriptions. The note about common IATA codes is a usage guideline rather than parameter semantics, so the description adds marginal value 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?

The description clearly states the tool searches for airports and cities to return identifiers for Google Flights tools. It specifies the exact outputs (IATA codes for airports, kgmid for cities) and gives concrete examples, making its purpose unmistakable and distinct from the sibling flight tools that consume these identifiers.

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 description explicitly says when to use the tool: 'when you have a city name like 'New York' or 'Paris' and need to convert it to codes that the flight tools accept.' It also provides an exclusion by noting that common IATA codes like JFK can be used directly without this tool, giving clear guidance on alternatives.

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, idempotentHint=false, and destructiveHint=false. The description adds valuable behavior beyond those annotations: the booking_token follow-up workflow, the requirement to preserve original search options, and the need to repeat required parameters on follow-up calls. It does not describe response format or pagination, but it is substantially more informative than the annotations alone.

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

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

The description is front-loaded with the core purpose, then moves through required parameters, workflow, and sibling alternatives. Every sentence carries actionable information, and the bullet structure makes the two-step workflow easy to scan.

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 20-parameter search tool with full schema coverage, rich annotations, and no output schema, the description supplies the essential missing context: workflow, required-parameter persistence, token follow-up behavior, and alternative-tool routing. Return intent is indicated through 'flight options' and 'booking details', which is sufficient here.

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 semantic guidance beyond the schema by explaining that departure_id, arrival_id, and outbound_date are required even on token follow-ups and that all original search options should be preserved when retrieving booking details.

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 uses a specific verb and resource: 'Search one-way Google Flights', and it distinguishes the tool from round-trip and flexible-date siblings by naming them. An agent can identify the tool's scope 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 a clear two-step workflow, states required parameters on every call including token follow-ups, and explicitly routes round-trip searches to google_flights_round_trip and flexible-date searches to google_flights_calendar_one_way. This tells the agent when to use this tool versus the main alternatives.

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 the genuinely useful behavioral fact that this is a stateful three-phase token chain where every original argument must be re-sent. It does not mention result-set size, pagination, or rate limits, which keeps it a step below the top score.

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 the one-sentence purpose, then required-argument constraints, then a numbered workflow, then sibling routing. No sentence is redundant and the ordering matches how an agent would need the information.

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 22-parameter, no-output-schema tool the description covers the hard part — the multi-call token chaining and parameter persistence — and the workflow steps implicitly describe what each phase returns (outbound flights, then return options, then booking details). It stops short of describing result shape or a concrete example of a token round-trip.

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 baseline is 3; the description goes beyond it by explaining the runtime contract that all search options (travel_class, passenger counts, currency, filters) must be preserved across token calls, and by framing departure_token vs booking_token as mutually replacing rather than additive.

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 ('Search round-trip Google Flights') and enumerates what the results include (airline, time, price, booking details). It also explicitly names the two sibling variants it is not (google_flights_one_way, google_flights_calendar_round_trip), so the agent can disambiguate without opening schemas.

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 an explicit three-step workflow and names the alternative tools for one-way and flexible-date searches with the condition that selects each. The line 'Required on every call, including token follow-ups' preempts the most likely invocation error.

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 and openWorldHint=true, covering the safety and external-data aspects. The description adds the scope (worldwide) and the requirement of date parameters, but does not disclose any additional behavioral nuances (e.g., pagination via next_page_token or result variability). Since annotations carry the main burden, a 3 is appropriate.

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 description is extremely concise: two sentences plus a compact list of required fields and two usage tips. It front-loads the primary purpose and avoids fluff, earning its place with no 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?

Given 20 parameters and no output schema, the description effectively highlights the essentials (required params and key tips) while relying on the comprehensive schema for the rest. It lacks a full example of a typical call, but the schema plus description covers what an agent needs to make a valid request. A 4 reflects a near-complete guidance.

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 all parameters are documented. The description adds a few usage pointers (sort_by='lowest_price', children_ages format) that reinforce but do not extend beyond the schema's own descriptions. Baseline 3 applies when schema is complete and the description adds only marginal clarification.

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 clearly states a specific action ('Search for hotels') and a specific resource ('Google Hotels'), and specifies what it provides (pricing, ratings, amenities, availability). It distinguishes itself from sibling search tools like google_flights_* or google_maps_search by being explicitly about traditional hotel accommodations worldwide.

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 explicitly lists the required parameters (q, check_in_date, check_out_date) and provides a practical hint for using sort_by='lowest_price' and formatting children_ages. However, it does not explicitly compare to alternatives like google_vacation_rentals or state when not to use this tool, though the hotel-specific focus makes the context clear.

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 indicate this is read-only and non-destructive. The description adds detail about what it returns (thumbnails, source pages, original URLs), which is useful. However, it does not mention rate limits, pagination behavior, or the meaning of the 'light' variant in the name, so it provides only moderate extra context beyond the annotations.

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 description is two sentences and every piece of information earns its place: the search intent, the output, and the use case. No filler or repetition, front-loaded with the main action.

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 search tool with 7 parameters and a fully described schema, the description covers the purpose, output shape, and typical use. The only real gap is the unspecified 'light' naming and any limitations it might imply, which could matter for an agent deciding between multiple search tools. It still feels sufficiently complete for routine calls.

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 does not delve into any parameter semantics beyond saying 'Search Google Images,' which aligns with the `q` parameter. It adds no new information about `gl`, `size`, `color`, etc., relying entirely on 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?

The description clearly states the verb+resource: 'Search Google Images for photos and visual content.' It explicitly differentiates from sibling tools like google_search_light and bing_search by focusing on image search. The return format (thumbnails, source pages, original URLs) makes it unambiguous.

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 phrase 'Useful for finding reference images, illustrations, and visual content' provides clear context for when to use this tool. It implies it is the right choice for visual search but does not explicitly compare with alternatives or give negative exclusions, so it falls 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.

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

Annotations already establish read-only and non-destructive behavior, so the description only needs to add useful context. It adds that results are aggregated from multiple job boards and lists returned fields, but it does not disclose pagination behavior or variable result availability. This is acceptable for a safe read-only search but the behavioral disclosure is modest.

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?

A single front-loaded sentence gives the purpose and output fields without any filler or repetition. It is appropriately sized for a search tool with a well-documented 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 supplies the main return contract (titles, companies, locations, descriptions, apply links). Parameter semantics are fully covered by the schema, including pagination via next_page_token, leaving only minor gaps such as result-count or error behavior.

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?

The schema covers all seven parameters with descriptions, so the parameter burden is already fully met. The tool description adds no parameter-specific semantics beyond the schema, which is fine given the 100% coverage 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-resource pair ('Search for job listings on Google Jobs') and enumerates the returned data (titles, company names, locations, descriptions, apply links). The vertical scope clearly separates it from generic siblings like bing_search, google_search_light, and other vertical search tools.

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 description gives a clear usage context: use it when job listings are needed, and it is explicitly scoped to Google Jobs and aggregated boards. It does not name an alternative or provide an explicit when-not, so it falls just 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.

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 adds real value beyond them by disclosing the kinds of results returned (matches, web results, product ID, OCR-style text extraction) and the constraint that q only works with certain search types.

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 purpose, then capabilities, then the query-refinement caveat. Efficient overall, though the trailing 'Required: url' sentence duplicates what the schema already marks as required and does not earn its place.

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 must carry the return-value burden, and it does so by naming the result categories. Combined with 100% schema coverage for the six parameters, an agent has enough to call the tool correctly; only result format/pagination detail is absent, which is minor for an open-world read tool.

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 six parameters, both enums, and the crop format are already documented in the schema. The description only restates that url is required and repeats the q/search_type interaction, adding little beyond the structured fields. 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?

States a specific verb (analyze) and resource (images via Google Lens), and enumerates the concrete outputs: visual matches, web results, product identification, text extraction, exact match detection. Clear on its own, but never contrasts itself with the closest sibling, google_images_light, leaving the agent to infer the difference.

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?

Implies usage through the capability list and notes that the text-query refinement only applies to search_type 'all' or 'visual_matches', which is a genuine usage constraint. However, there is no explicit when-to-use-this vs google_images_light or google_search_light guidance, and no prerequisites beyond the required url.

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 read-only, open-world, non-destructive behavior, and the description adds substantial context: what fields are returned (address, phone, hours, holiday_hours with YYYY-MM-DD dates, reviews) and a current limitation that photos and popular times are often missing. Minor gaps remain, such as how reviews are limited or how invalid IDs behave, but the description adds clear value beyond the annotations.

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 front-loaded with the core purpose, then requirements, return details, and alternative routing. Every sentence contributes useful selection or invocation information with no wasted text.

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 does a good job describing the returned fields and the holiday_hours format. It could be slightly more complete by explaining review limits or error behavior for invalid IDs, but it is sufficient for an agent 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 the parameters are already documented. The description adds meaning by stating where data_id and place_id must come from (google_maps_search results) and reinforcing that at least one is required, which helps an agent prepare valid inputs.

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 uses a specific verb+resource ('Get detailed information about a specific place from Google Maps') and explicitly differentiates this detail lookup from the sibling google_maps_search by requiring IDs from those results. An agent can readily distinguish it from search and other Google tools.

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 states the prerequisite (data_id or place_id from google_maps_search) and the at-least-one constraint. It also explicitly routes agents to google_maps_photos for photos and google_place with kgmid for popular times, naming the exact alternatives and conditions.

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 read-only, open-world, non-destructive, and non-idempotent behavior. The description adds useful result-shape context, including names, addresses, ratings, reviews, hours, holiday_hours with date format, and identifiers for follow-up detail calls.

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?

Two tightly written sentences: the first covers purpose and return contents, and the second covers the follow-up workflow. The important scoping and routing information is front-loaded with no wasted text.

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 burden of explaining return values, which it does by listing the key result fields and the holiday_hours format. It also explains how to continue to detailed place lookup, making it complete for this search tool.

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 q, gl, and page are already documented in the input schema. The description does not add parameter-specific guidance beyond what the schema provides, so the baseline of 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?

States a specific verb and resource: searching local businesses and places on Google Maps. It also distinguishes itself from google_maps_place by explicitly saying detailed place information comes from the sibling tool using data_id or place_id.

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 usage context for local place searches and explicitly names the follow-up tool for detailed place information. It does not explain when to choose this over other search siblings such as bing_search or google_search_light, but the local-business scope is clear.

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?

The description adds value beyond the annotations by specifying the exact fields returned (titles, IDs, inventors, assignees, filing dates, abstracts). It does not contradict the readOnlyHint or openWorldHint, and it provides useful context about output without delving into rate limits or pagination, which is acceptable given the annotations.

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 description is a single, front-loaded sentence that immediately states the action and resource, then lists the return fields with no filler. Every word contributes to understanding the tool's purpose and output.

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 read-only search tool with fully documented parameters and annotations covering safety, the description is sufficient. It explains what the tool returns and the domain, and the schema covers parameter usage. It does not mention potential pagination or result limits, but these are not critical for a simple search tool.

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 eight parameters are already documented in the input schema. The description does not add any additional meaning or examples for parameters beyond what the schema provides, so it does not go above the baseline of 3.

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 clearly states a specific verb ('Search'), a specific resource ('Google Patents'), and the scope ('patent documents and scholarly articles'). It also lists the return fields (titles, IDs, inventors, assignees, filing dates, abstracts), distinguishing it from general web search tools like google_search_light and from google_scholar by the patent focus.

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 description implies usage for patent searches and scholarly articles but does not explicitly compare to sibling tools like google_scholar or explain when to choose this over them. No exclusions or alternative recommendations are provided, so the guidance is only implied by the resource name and description.

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?

The description adds useful behavioral detail beyond the readOnlyHint annotation by specifying what the response contains: offers from multiple sellers, specifications, reviews, and pricing history. It also discloses the token dependency. It does not cover error cases or rate limits, but for a read-only lookup tool the key behavior is communicated.

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 description is three sentences with no filler. It front-loads the main purpose, then gives the prerequisite and the key return contents. Every sentence earns its place.

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 simple read-only tool with one required parameter and no output schema, the description is complete: it explains what the tool does, how to get the required token, and what the response will contain. The annotations cover safety, and the schema covers parameters, so nothing essential 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 description coverage is 100%, so the parameters are already well documented. The description reinforces that product_token comes from google_shopping_search results, matching the schema, but adds no new semantic details for gl or location beyond what the schema already provides.

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 gives a specific verb and resource: 'Get detailed product information from Google Shopping.' It clearly differentiates itself from the sibling google_shopping_search by requiring a product_token from that search, so an agent can understand this tool as the detail-fetching follow-up rather than a search tool.

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 description explicitly states the prerequisite: the tool requires a product_token obtained from google_shopping_search results. This tells the agent when it is appropriate to call the tool, though it does not explicitly name alternative tools or state when not to use it.

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 the safety profile (readOnly, non-destructive, open-world), so the bar is lower. The description adds genuinely useful context not covered there: the 100-result cap per request and the returned fields (position, title, URL, snippet), which matters because no output schema exists.

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 tight sentences with zero redundancy: purpose first, then return shape, then use case. Nothing could be removed without losing information.

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-only search tool with no output schema, the description covers purpose, return fields, and result limit sufficiently. It omits any localization/geotargeting nuance (latitude/longitude vs location), but the schema handles those constraints fully.

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 eight parameters are already documented with defaults, ranges, and mutual exclusions. The description only echoes the 'up to 100 results' cap tied to num, adding no new syntax or format meaning, 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 ('Get Google organic search results') and frames the intent ('for SEO rank tracking'), which is unambiguous. It does not differentiate itself from near-identical siblings like google_search_light or bing_search, so it stops short of a 5.

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?

'Ideal for monitoring keyword rankings and SERP analysis' implies when the tool is appropriate but offers no explicit when-not guidance and names no alternative. With several sibling search tools available, the agent must infer the routing decision itself.

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 and openWorldHint, so the safety profile is known. The description adds useful behavioral context by listing returned fields (titles, authors, publication info, citation counts, PDF links) and clarifying the cites/cluster modes, which goes beyond the annotations without contradicting them.

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 succinct sentences with no filler. The core purpose comes first, return content is stated next, and the cites/cluster/case-law guidance is packed into the final sentence efficiently.

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 read-only search tool with 100% schema coverage and open-world annotations, the description is largely complete. It names the output fields and points to the correct alternative for case law; the only minor gap is that it does not describe pagination behavior, but num/page are already fully documented in the schema.

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 7 parameters. The description mentions cites and cluster at a high level, but doesn't add meaningful parameter semantics beyond the schema descriptions; this is the expected baseline 3.

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?

Description specifies a clear action (Search Google Scholar), a precise resource (academic papers, citations, scholarly articles), and differentiates from the sibling google_scholar_cases. It also distinguishes this tool's scholarly focus from patent and news-oriented siblings.

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 explicit guidance for special modes: 'Use cites parameter to find papers citing a specific work, or cluster to find all versions of a paper.' It also names an alternative tool for court opinions and case law, telling the agent exactly 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.

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so no need to repeat. The description adds value by specifying return contents (organic results, related searches, pagination) and the 'fast' nature, which are not covered by annotations. No contradictions.

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?

Two sentences with zero fluff. Purpose, return summary, and usage condition are front-loaded and each sentence earns its place. Perfectly concise for the information conveyed.

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 read-only search tool with full schema coverage and no output schema, the description gives a high-level return summary and usage context. It does not detail the output structure, but given the simplicity and annotations covering safety, it is sufficiently complete. Could mention rate limits or output format, but not critical.

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 all parameters are already documented in the input schema. The description only reinforces the requirement for 'q' and does not add extra semantic meaning beyond what the schema provides. Baseline 3 applies because 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?

States a specific verb+resource ('Perform fast Google web searches') and clarifies what is returned (organic results, related searches, pagination). The name 'light' and mention of 'advanced filtering not needed' help differentiate from more specialized search siblings like google_scholar or google_images_light, even without naming them explicitly.

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 a clear usage condition: 'Suitable for quick information retrieval when advanced filtering is not needed.' This implies when to use it, but it does not explicitly name alternatives or exclusions. It also notes the required parameter, adding practical guidance. Slightly better than average but lacks explicit routing to siblings.

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 flag this as read-only and open-world; the description adds observable behavior: it returns listing-level pricing, seller, rating, and comparison data)Skip and indicates a follow-up path. No hidden side effects or destructive behavior need disclosure.

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 short front-loaded sentences cover scope, return type, and next step, with no repetition of schema content or filler.

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 tool with eight parameters and no output schema, the description provides adequate return-shape and follow-up guidance. Minor details like pagination behavior or regional result variations are left to the schema, which covers the parameter side.

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?

The input schema already documents all parameter meanings fully (100% coverage), so the description adds no new parameter-level semantics. The product_token pointer is useful but not a parameter of this tool.

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 opens with a specific verb + resource ('Search for products on Google Shopping'), states exactly what is returned (prices, sellers, ratings, comparison shopping data), and explicitly routes follow-up work to google_product with product_token.

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 using this tool and tells the agent when to switch to google_product for detailed results. It does not explicitly contrast with every sibling search tool, but the product-shopping scope is unambiguous enough.

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?

The description's 'Search' and 'Provides pricing, ratings, amenities, and availability' align with annotations readOnlyHint=true and destructiveHint=false. It adds some behavioral context about the kind of results returned, but it does not disclose pagination behavior, data freshness, Google Hotels inventory caveats, or any rate-limiting details. No contradiction with annotations.

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 description is a single front-loaded sentence that states the action first and then lists relevant output aspects and property types. There is no filler, and the property examples earn their place by reinforcing the vacation-rental scope.

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?

Given 100% schema coverage for all 16 parameters, the agent has what it needs to construct a correct call. The description also covers the main output dimensions: pricing, ratings, amenities, and availability. A small gap is that no output schema exists and the description does not mention pagination tokens, though the schema itself documents next_page_token.

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% across 16 parameters, so the baseline is 3. The description does not add parameter-level meaning, but it does not need to since every parameter already has a clear description in 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?

The description uses a specific verb and resource: 'Search for vacation rentals using Google Hotels.' It further clarifies scope by listing property types like apartments, villas, cabins, and houses, which helps distinguish it from general hotel search. However, it never explicitly contrasts itself with the sibling tool google_hotels, so full sibling 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?

Usage context is implied: the description indicates this tool is for vacation rental searches, and the property-type list hints at when it would apply. There is no explicit guidance about when to use this tool versus google_hotels or other search tools, and no alternatives are named.

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 and destructiveHint=false, so the safety profile is covered. The description adds the fact that it fetches public information and that post IDs are shortcodes, but does not disclose edge cases (e.g., private profiles, rate limits) or behavioral traits beyond what annotations provide. It adds minimal value beyond the annotations.

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 description is two concise sentences with no redundant wording. The primary purpose is front-loaded, and the cross-reference to instagram_post is a useful addition without bloat.

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 simple read-only tool with one parameter and no output schema, the description is largely complete: it lists returned fields and explains the shortcode relationship. It could mention that the profile must be public, but that is implied by 'public profile information' and the annotations. Minor gaps like error handling are not critical for this simplicity.

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 username parameter is fully documented in the schema. The description does not add any additional semantic meaning about the parameter beyond what the schema provides, maintaining the baseline of 3.

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 explicitly states the tool fetches public profile information from Instagram, lists the returned fields (bio, counts, posts, etc.), and clearly distinguishes the resource from the sibling tiktok_profile by naming the platform. It is a specific verb+resource with no ambiguity.

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 description gives clear guidance on how to use the returned post IDs (pass to instagram_post) but does not explicitly state when to choose this tool over alternatives like tiktok_profile. It implies usage for Instagram profile data but lacks explicit exclusions or when-not-to-use conditions.

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 and destructiveHint=false, so the safety profile is covered. The description adds value by specifying the exact return fields (bio, counts, verification, etc.), which is not in the annotations. It does not mention rate limits or authentication, but for a public read-only fetch, the added field list justifies 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?

The description is a single, efficient sentence that front-loads the action and resource, then lists the returned fields. Every clause earns its place; there is no redundancy or filler.

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 simple one-parameter, read-only tool with complete schema documentation and no output schema, the description is sufficiently complete. It states exactly what data will be returned, and the annotations cover the operational safety. No critical information an agent needs to invoke it correctly 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 description coverage is 100%, and the single parameter 'username' is fully documented in the schema with format ('with or without @') and requiredness. The description does not add any additional parameter semantics beyond what the schema already provides, so the baseline of 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 clearly states the action ('Fetch') and the resource ('public profile information from TikTok'), and enumerates the specific data returned (bio, counts, likes, video count, verification, links). It is distinct from siblings like instagram_profile by explicitly naming TikTok, so an agent can distinguish it without ambiguity.

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 usage is implied by the description: use it when you need TikTok profile data. However, it does not explicitly contrast with alternatives such as instagram_profile or mention conditions when this tool is not appropriate. No when-not guidance is provided, so it falls at the 'implied usage' level.

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