Searchapi

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 behavioral context beyond annotations by specifying what the tool returns ('titles, sources, thumbnails, and publication dates') and its recency focus ('recent news coverage'), which helps the agent understand output format and use case.

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 perfectly concise with two sentences: the first states the core functionality and output, the second provides usage context. Every word earns its place, and key information is front-loaded. No wasted verbiage 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?

Given the tool's moderate complexity (5 parameters, no output schema), the description is reasonably complete. It covers purpose, output format, and use case context. With annotations providing safety/behavioral hints and 100% schema coverage, the main gap is lack of output schema documentation, but the description partially compensates by listing return fields.

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 in the schema itself. The description doesn't add any parameter-specific semantics beyond what the schema provides (e.g., it doesn't explain query formatting or market code details). Baseline 3 is appropriate when the schema carries the full parameter documentation 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 clearly states the specific action ('Search for news articles using Bing News') and resource ('news articles'), distinguishing it from siblings like bing_search (general search) and google_search_light (general web search). It explicitly mentions the domain ('Bing News') and purpose ('finding recent news coverage and trending stories').

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 for when to use this tool ('Good for finding recent news coverage and trending stories'), which implicitly differentiates it from non-news search tools. However, it doesn't explicitly state when not to use it or name specific alternatives among siblings (e.g., bing_search for general web searches).

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 provide readOnlyHint=true, openWorldHint=true, idempotentHint=false, and destructiveHint=false, covering safety and idempotency. The description adds valuable context by specifying what the tool returns ('organic results, related searches and more'), which is not covered by annotations. No contradictions with annotations exist.

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 with zero waste: the first sentence states the core function and output, and the second provides critical usage guidance. It is front-loaded with essential information and appropriately sized for the tool's 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?

Given the tool's moderate complexity (4 parameters, 1 required), rich annotations covering safety and scope, and no output schema, the description is mostly complete. It clarifies purpose, usage, and output types, but could slightly improve by mentioning pagination or result format details, though annotations help mitigate this gap.

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%, meaning all parameters are well-documented in the schema itself. The description does not add any additional meaning or clarification about parameters beyond what's in the schema, so it meets the baseline of 3 for high schema coverage without extra value.

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's purpose with specific verbs ('Search the web using Bing') and resources ('web'), and distinguishes it from siblings by mentioning it's an 'Alternative to Google for web search with different ranking algorithms and results.' This explicitly differentiates it from other search tools in the sibling list.

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 explicit guidance on when to use this tool vs. alternatives: 'Alternative to Google for web search with different ranking algorithms and results.' This directly addresses the sibling tools (e.g., google_search_light) and indicates this should be used when Bing's specific algorithms or results are preferred over Google's.

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 valuable behavioral context beyond what annotations provide. While annotations already indicate it's read-only, non-destructive, and open-world, the description adds specific behavioral traits: 'privacy-focused', 'no tracking', and 'unbiased results'. These are important operational characteristics that aren't captured in the annotations. No contradiction with annotations 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?

The description is perfectly concise and front-loaded. The first sentence establishes the core functionality, and subsequent phrases add important differentiating characteristics. Every sentence earns its place by providing distinct value: the search function, result type, privacy focus, and key differentiators from alternatives.

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's moderate complexity (search with filtering options), rich annotations, and comprehensive input schema, the description provides good contextual completeness. It explains the tool's purpose, behavioral characteristics, and differentiation. The main gap is the lack of output schema, but the description mentions 'Returns organic results' which provides some output context. It could be more complete by describing result format or limitations.

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 100% schema description coverage, the input schema already thoroughly documents all three parameters (q, locale, time_period) with clear descriptions and examples. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline expectation but doesn't provide additional semantic value.

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's purpose with specific verbs ('Search the web using DuckDuckGo') and resource ('organic results'). It distinguishes itself from sibling tools by explicitly mentioning it's a 'privacy-focused alternative to Google' and listing key differentiators like 'unbiased results and no tracking', which helps differentiate it from the many Google-based search tools in the sibling list.

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 about when to use this tool ('privacy-focused alternative to Google'), but doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools. It implies usage for privacy-conscious searches but lacks explicit exclusions or comparisons with other search tools like 'google_search_light' or 'bing_search'.

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 context by specifying it fetches 'public' information (implying no authentication needed) and listing the specific data fields returned, which helps the agent understand the scope and output format beyond the basic 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 description is efficiently structured in two sentences: the first states the purpose and detailed return values, the second specifies parameter requirements. Every element adds value with zero wasted words, making it easy to parse and understand quickly.

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 comprehensive annotations and no output schema, the description provides good completeness by detailing the returned data fields and parameter logic. It could slightly improve by mentioning rate limits or data freshness, but it adequately covers the tool's functionality given the structured context.

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%, with both parameters clearly documented in the schema. The description adds minimal value beyond the schema by restating the parameter requirement ('Provide either page_id or username') but doesn't provide additional syntax, format details, or usage nuances. This meets the baseline for high schema 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 'fetch' and resource 'public business page information from Facebook', specifying the exact data returned (name, category, address, etc.). It distinguishes this tool from sibling tools by focusing on Facebook business pages rather than search engines, social media profiles, or other services.

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 for when to use this tool ('fetch public business page information') and specifies the required input parameters ('Provide either page_id or username'). However, it doesn't explicitly state when NOT to use it or mention alternatives among sibling tools, though the distinction is implied by the Facebook-specific focus.

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, non-destructive, and open-world behavior, but the description adds valuable context: it specifies that responses are 'AI-synthesized' with 'source citations and reference links', which clarifies the output format and credibility aspects. No contradictions with annotations exist, and the description enhances understanding beyond the structured 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 description is front-loaded and efficient: two sentences convey purpose, input support, and output characteristics without redundancy. Every sentence earns its place by adding distinct value (functionality, input type, output features), making it appropriately sized for the tool's 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?

Given the tool's moderate complexity (2 parameters, no output schema), the description is mostly complete: it covers what the tool does, input types, and output features. However, it lacks details on error handling, rate limits, or authentication needs, which could be relevant for an AI agent. Annotations provide safety hints, but more behavioral context would enhance completeness.

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 input schema fully documents parameters (q and location). The description adds no additional parameter semantics beyond what the schema provides, such as query examples or location format details. Baseline 3 is appropriate as the schema carries the full 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 clearly states the tool's purpose with specific verbs ('Get', 'Supports', 'Returns') and resources ('Google's AI-generated responses', 'AI Overviews', 'text queries', 'AI-synthesized answers'). It distinguishes from sibling tools like google_search_light by focusing specifically on AI-generated responses rather than general search results.

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 context ('Supports text queries') but does not explicitly state when to use this tool versus alternatives like google_search_light or other Google tools. No guidance is provided on when-not-to-use or specific prerequisites, leaving usage decisions to inference from the purpose alone.

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, and idempotentHint=false, covering safety and idempotency. The description adds useful context about the return format ('Returns a list of dates with prices') and the tool's practical application for flexible travel planning. However, it doesn't mention rate limits, authentication needs, or data freshness, which would be valuable additions.

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 efficiently structured in two sentences: the first explains the tool's purpose and output, the second provides clear sibling differentiation. Every sentence adds value with zero wasted words, making it easy to parse and understand quickly.

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's complexity (17 parameters) and the absence of an output schema, the description does well by explaining the return format ('list of dates with prices') and practical use case. However, it could benefit from mentioning typical response structure or data limitations. The annotations provide good safety context, but more behavioral details would make it 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%, meaning all 17 parameters are well-documented in the schema itself. The description doesn't add any parameter-specific details beyond what's already in the schema descriptions. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even without parameter information in the description.

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's purpose: 'Get a price calendar showing the cheapest one-way flight price for each day in a date range.' It specifies the verb ('Get'), resource ('price calendar'), and scope ('one-way flight'), and explicitly distinguishes it from its sibling tool 'google_flights_calendar_round_trip' for round-trip searches.

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 explicit guidance on when to use this tool versus alternatives: it states it's 'useful for finding the cheapest departure day when you have flexible travel dates' and directly names the alternative tool 'google_flights_calendar_round_trip' for round-trip searches. This gives clear context for tool selection.

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 indicate this is a read-only, non-destructive, open-world tool. The description adds valuable context by explaining the output format ('grid of date pairs with prices') and the tool's utility for flexible date planning. It doesn't contradict annotations and provides behavioral insight beyond them, though it could mention rate limits or authentication needs.

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 in the first sentence, followed by utility context and a clear sibling distinction. Both sentences earn their place by providing essential information without redundancy or fluff.

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 complex tool with 18 parameters, 100% schema coverage, and annotations covering safety aspects, the description is reasonably complete. It explains the tool's purpose, usage context, and output format. However, without an output schema, it could briefly mention the structure of the returned grid (e.g., matrix format) for better completeness.

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 18 parameters. The description doesn't add any parameter-specific details beyond what's in the schema, such as explaining interactions between parameters. This meets the baseline for high schema 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 tool's purpose: 'Get a price calendar showing the cheapest round-trip flight prices for combinations of outbound and return dates.' It specifies the verb ('Get'), resource ('price calendar'), and scope ('round-trip flight prices'), and distinguishes it from its sibling 'google_flights_calendar_one_way' by explicitly mentioning it's for round trips.

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 explicit guidance on when to use this tool: 'useful for finding the best travel window when both departure and return dates are flexible.' It also clearly states an alternative: 'For one-way price calendars, use google_flights_calendar_one_way instead.' This gives clear context for tool selection.

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, open-world, non-destructive, and non-idempotent behavior. The description adds valuable context beyond annotations by explaining what types of identifiers are returned (IATA codes for airports, kgmid for cities) and the search scope ('searches all airports in that city'). It doesn't mention rate limits or auth needs, but with annotations covering safety, 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?

The description is well-structured and front-loaded with the core purpose. Each sentence adds value: the first defines the tool, the second explains outputs, the third provides usage context, and the fourth gives exclusion guidance. No wasted words 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?

Given the tool's moderate complexity, rich annotations (read-only, open-world), and full schema coverage, the description is complete. It explains the tool's role in the Google Flights ecosystem, what it returns, and when to use it. No output schema exists, but the description adequately covers return types (IATA codes and kgmid).

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 both parameters thoroughly. The description adds minimal parameter semantics beyond the schema—it implies the 'q' parameter accepts city names but doesn't detail format or constraints. With high schema coverage, 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 clearly states the tool's purpose: 'Search for airports and cities to get their identifiers for Google Flights tools.' It specifies the verb ('search'), resource ('airports and cities'), and output ('identifiers'), and distinguishes it from sibling Google Flights tools by focusing on location lookup rather than flight search or calendar functions.

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 explicit guidance on when to use this tool: 'Use this 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 specifies when NOT to use it: 'Common IATA codes like JFK, LAX, SFO, LHR, CDG, NRT can be used directly without this tool,' offering clear 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, destructiveHint=false, openWorldHint=true, and idempotentHint=false, covering safety and idempotency. The description adds useful context about the workflow (search first, then use booking_token) and mentions that it 'returns flight options,' but doesn't disclose rate limits, authentication needs, or pagination behavior. With annotations providing core behavioral traits, the description adds moderate value.

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 and front-loaded with the core purpose. The workflow section and sibling tool guidance are concise and directly relevant. Every sentence earns its place without 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?

Given the tool's complexity (19 parameters, no output schema) and rich annotations, the description is largely complete. It clarifies the tool's purpose, distinguishes it from siblings, and outlines usage. However, without an output schema, it could better explain the structure of returned flight options or error handling, though the annotations provide safety context.

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 19 parameters. The description mentions the three required parameters (departure_id, arrival_id, outbound_date) and hints at the booking_token parameter's purpose, but adds minimal semantic value beyond what the schema provides. Baseline 3 is appropriate given high schema 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 specific action ('Search for one-way flights') and resource ('using Google Flights'), and explicitly distinguishes it from sibling tools (google_flights_round_trip, google_flights_calendar_one_way). It also mentions the return content ('flight options with airlines, departure/arrival times, prices, and booking information').

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 explicit guidance on when to use this tool versus alternatives: 'For round-trip flights, use google_flights_round_trip instead. For flexible date searches, use google_flights_calendar_one_way to find the cheapest dates first.' It also outlines a workflow for usage in the context of sibling 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 provide safety information (readOnlyHint=true, destructiveHint=false), but the description adds valuable behavioral context: the multi-step workflow requiring tokens, the need to call the tool twice for complete results, and the relationship between tokens and subsequent calls. This goes beyond what annotations convey about the tool's operational behavior.

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 efficiently structured with a clear purpose statement followed by a numbered workflow and explicit sibling alternatives. Every sentence serves a distinct purpose: establishing function, explaining process, and guiding tool selection. No redundant or wasted content.

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 complex 21-parameter tool with rich annotations but no output schema, the description provides excellent contextual completeness. It explains the multi-call workflow, token usage, and sibling relationships that aren't captured in structured fields. The agent has all necessary context to use this tool correctly despite its complexity.

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 100% schema description coverage, the schema already documents all 21 parameters thoroughly. The description adds minimal parameter-specific information beyond the schema, mainly clarifying the workflow relationship between departure_token and booking_token. This meets the baseline for high schema 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 tool's purpose: 'Search for round-trip flights using Google Flights' with specific outputs listed (airlines, times, prices, booking info). It explicitly distinguishes from siblings google_flights_one_way and google_flights_calendar_round_trip, making the scope 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 description provides explicit workflow guidance (4-step process) and clear alternatives: 'For one-way flights, use google_flights_one_way instead' and 'For flexible date searches, use google_flights_calendar_round_trip'. This gives the agent precise when-to-use and when-not-to-use instructions.

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 indicate readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds context about what information is provided (pricing, ratings, etc.) and the scope (worldwide), which is useful beyond annotations. However, it does not disclose behavioral traits like rate limits, authentication needs, or pagination details (though 'next_page_token' in schema hints at pagination). No contradiction with annotations 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?

The description is a single, efficient sentence that front-loads the core purpose ('Search for hotels using Google Hotels') and lists key outputs. It avoids redundancy and waste, though it could be slightly more structured by separating scope or usage notes. Every part earns its place by informing the user about the tool's function and outputs.

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's complexity (20 parameters, no output schema) and rich annotations (readOnlyHint, openWorldHint), the description is minimally adequate. It covers the purpose and outputs but lacks details on when to use it, behavioral constraints (e.g., pagination, rate limits), or how results are structured. With no output schema, more context on return values would be helpful, but the description does not provide it.

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 20 parameters. The description mentions general aspects like 'pricing, ratings, amenities, and availability', which loosely map to some parameters (e.g., 'rating', 'amenities', 'price_max'), but adds no specific semantics beyond what the schema provides. Baseline 3 is appropriate given high schema 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 tool's purpose: 'Search for hotels using Google Hotels' with specific outputs like 'pricing, ratings, amenities, and availability'. It distinguishes the resource (hotels) and scope (worldwide), but does not explicitly differentiate from sibling tools like 'google_vacation_rentals' or 'google_flights_*', which might handle similar travel-related queries.

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 no guidance on when to use this tool versus alternatives. It mentions the tool searches for 'hotels, resorts, inns, motels, and other traditional accommodations', but does not specify when to choose it over sibling tools like 'google_vacation_rentals' (for non-traditional stays) or 'google_flights_*' (for flights). No exclusions or prerequisites are stated.

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 readOnlyHint=true, openWorldHint=true, idempotentHint=false, and destructiveHint=false, covering safety and idempotency. The description adds value by specifying the return format ('Returns image results with thumbnails, source pages, and original image URLs') and use cases, but doesn't disclose additional behavioral traits like rate limits, authentication needs, or pagination details beyond the schema's 'page' parameter.

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 concise and well-structured: two sentences that front-load the core functionality and follow with use cases. Every sentence adds value without redundancy, efficiently covering purpose, output, and utility in minimal 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?

Given the tool's moderate complexity (7 parameters, no output schema), the description is reasonably complete. It clarifies the tool's purpose, output format, and use cases. However, it lacks details on error handling, result limits, or how to interpret outputs like thumbnails, which could be helpful since there's no output schema. Annotations provide good safety context, but some behavioral gaps remain.

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 7 parameters with descriptions and enums. The description doesn't add any parameter-specific semantics beyond what's in the schema, such as explaining query formatting or default behaviors. Baseline 3 is appropriate as the schema handles parameter documentation effectively.

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's purpose: 'Search Google Images for photos and visual content.' It specifies the verb ('Search') and resource ('Google Images'), and distinguishes it from general search tools like 'google_search_light' by focusing on images. However, it doesn't explicitly differentiate from other visual tools like 'google_lens' or 'instagram_profile' beyond mentioning 'Google Images'.

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 implied usage guidance: 'Useful for finding reference images, illustrations, and visual content.' This suggests appropriate contexts but doesn't explicitly state when to use this tool versus alternatives like 'google_lens' for image analysis or 'bing_search' for broader results. No exclusions or clear 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 agent knows this is a safe read operation. The description adds useful context about what data is returned (titles, company names, locations, descriptions, apply links) and that results are aggregated from multiple sources, which goes beyond the annotations. However, it doesn't mention rate limits, authentication needs, or pagination behavior beyond what's in the schema.

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

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

The description is a single, well-structured sentence that efficiently communicates the tool's purpose and what it returns. Every word earns its place with no redundancy or unnecessary elaboration. It's front-loaded with the core action and immediately follows with the return value details.

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 comprehensive annotations (readOnly, openWorld) and 100% schema coverage, the description provides adequate context about what the tool does and returns. However, without an output schema, more detail about the structure of returned job postings would be helpful. The description mentions the types of data returned but doesn't specify format or completeness.

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 in the schema itself. The description doesn't add any additional meaning about parameters beyond what's already in the schema descriptions. The baseline score of 3 is appropriate when the schema does the heavy lifting for parameter documentation.

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 specific action ('Search for job listings on Google Jobs') and resource ('job postings'), distinguishing it from all sibling tools which focus on different domains like flights, maps, or social media. It explicitly mentions the aggregated nature of results from multiple job boards.

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?

No guidance is provided on when to use this tool versus alternatives. While it's clearly for job searches, there's no mention of when to prefer it over other search tools (like general web search) or job-specific alternatives that might exist elsewhere. The description lacks context about typical use cases or limitations.

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, and idempotentHint=false, covering safety and idempotency. The description adds some behavioral context by mentioning the types of analysis (visual matches, product identification, etc.) and support for refining results, but does not disclose rate limits, authentication needs, or detailed output behavior. With annotations providing core safety info, this is adequate but not rich.

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, followed by key features and constraints, all in two efficient sentences with zero waste. Every sentence adds value: the first states what the tool does, and the second clarifies usage nuances for text queries and search types.

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's moderate complexity (6 parameters, no output schema), the description is reasonably complete. It covers the tool's purpose, key functionalities, and some usage details. However, without an output schema, it does not describe return values or error handling, which could be helpful for an AI agent. Annotations provide safety context, but more behavioral details (e.g., response format) would enhance completeness.

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 6 parameters. The description adds minimal value beyond the schema by mentioning the 'url' parameter implicitly and noting that text queries refine results for search types 'all', 'visual_matches', and 'products', which aligns with schema details. No additional parameter semantics are provided, so 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 clearly states the tool's purpose with specific verbs ('analyze images', 'upload an image URL') and resources ('Google Lens'), and distinguishes it from sibling tools by focusing on visual analysis rather than text search, flights, or social media. It explicitly lists the types of analysis performed: visual matches, product identification, text extraction, and exact match detection.

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 for when to use this tool (for image analysis with Google Lens) and mentions refining results with text queries for specific search types. However, it does not explicitly state when not to use it or name alternatives among sibling tools (e.g., google_images_light for image search without analysis), which prevents a perfect score.

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, and openWorldHint=true, covering safety and scope. The description adds useful context about the prerequisite (needing IDs from search results) and the comprehensive nature of returned details, but doesn't disclose rate limits, authentication needs, or pagination behavior. No contradiction with annotations 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?

The description is front-loaded with the core purpose, followed by prerequisites and return details in three efficient sentences. Every sentence adds value: the first states what it does, the second specifies requirements, and the third describes output. No wasted words 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?

Given the tool's moderate complexity (3 parameters, no output schema), annotations cover safety and scope well, and the description adds necessary context about prerequisites and return content. It adequately informs the agent, though without an output schema, more detail on return structure could help. Sibling context is clear (differentiated from google_maps_search).

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%, with clear documentation for all three parameters (gl, data_id, place_id). The description reinforces that at least one of data_id or place_id is required and mentions they come from google_maps_search, adding minimal semantic value beyond the schema. Baseline 3 is appropriate given high schema 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 ('Get detailed information') and resource ('about a specific place from Google Maps'), distinguishing it from sibling tools like google_maps_search (which searches for places) and other non-Maps tools. It specifies the scope as 'comprehensive place details' including specific examples like address, phone, hours, etc.

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 for when to use this tool: after obtaining a data_id or place_id from google_maps_search results. It explicitly states 'At least one of data_id or place_id must be provided,' establishing prerequisites. However, it doesn't explicitly mention when NOT to use it or name alternatives beyond the implied google_maps_search.

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, and openWorldHint=true, covering safety and scope. The description adds useful context about the return format ('names, addresses, ratings, reviews, and contact information') and the relationship with google_maps_place, but doesn't disclose behavioral traits like rate limits, authentication needs, or pagination behavior beyond what the schema indicates.

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 perfectly concise with two sentences that each earn their place: first sentence states purpose and return format, second sentence provides usage guidance with sibling tool reference. No wasted words and front-loaded with core functionality.

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 good annotations (readOnly, openWorld) and complete schema coverage, the description provides adequate context about what the tool does and how it relates to other tools. The main gap is lack of output schema, but the description partially compensates by listing return data types. It could be more complete by mentioning pagination behavior or result limitations.

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 three parameters. The description doesn't add any parameter-specific information beyond what's in the schema, but provides context about the overall search purpose. With complete schema coverage, 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 clearly states the specific action ('Search for local businesses and places on Google Maps') and resource ('local results with names, addresses, ratings, reviews, and contact information'). It distinguishes from sibling tools like google_maps_place by specifying that this tool is for search while that one is for detailed place information.

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 provides when-to-use guidance: 'Use the data_id or place_id from results with google_maps_place to get detailed place information.' This names a specific alternative tool and clarifies the relationship between search and detailed lookup operations.

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 indicate read-only, open-world, non-idempotent, and non-destructive behavior, covering safety and scope. The description adds value by specifying the return fields (titles, IDs, etc.), which isn't in annotations, but doesn't disclose other behavioral traits like rate limits, authentication needs, or pagination. No contradiction with annotations 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?

The description is concise with two sentences: one stating the purpose and one detailing return values. It's front-loaded with the core function and avoids unnecessary details, though it could be slightly more structured by separating usage hints.

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's moderate complexity (8 parameters, no output schema), the description is somewhat complete but lacks depth. It covers purpose and return fields, but without an output schema, it doesn't fully explain the response format or error handling. Annotations provide safety context, but more behavioral details would enhance completeness.

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 well-documented in the schema. The description doesn't add any parameter-specific semantics beyond what's in the schema, such as examples or constraints, but it implies a search functionality. Baseline 3 is appropriate given high schema 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 tool searches Google Patents for patent documents and scholarly articles, specifying the verb 'search' and resource 'Google Patents'. It distinguishes from many siblings (e.g., google_search_light, google_scholar) by focusing on patents, though it doesn't explicitly differentiate from all patent-related tools that might exist elsewhere.

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 no guidance on when to use this tool versus alternatives like google_scholar or other search tools in the sibling list. It lacks context about use cases, prerequisites, or exclusions, leaving the agent to infer usage based on the tool name alone.

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, and idempotentHint=false. The description adds valuable context about the requirement for a product_token from another tool and describes the comprehensive nature of returned data (offers, specifications, reviews, pricing history), which goes beyond what 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?

Two sentences with zero waste. First sentence states purpose and prerequisite. Second sentence details what information is returned. Every word earns its place, and key information is front-loaded.

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 good annotations and full schema coverage, the description provides adequate context about prerequisites and return data scope. However, without an output schema, it could benefit from more detail about response structure (e.g., format of returned data).

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 fully documented in the schema. The description mentions the required product_token parameter's origin but doesn't add semantic meaning beyond what the schema already provides for gl or location parameters. Baseline 3 is appropriate when 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 clearly states the verb ('Get detailed product information') and resource ('from Google Shopping'), distinguishing it from sibling tools like google_shopping_search (which searches) and google_search_light (general search). It specifies the exact scope of information returned.

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 this tool: 'Requires a product_token obtained from google_shopping_search results.' This provides clear prerequisite context. However, it doesn't explicitly state when NOT to use it or mention alternatives beyond the implied sibling relationship.

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 indicate read-only and open-world hints, and the description adds valuable behavioral context beyond this: it specifies the result limit ('Returns up to 100 results per request') and details the return content ('position, title, URL, and snippet'). This enhances understanding of the tool's behavior without contradicting 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, followed by key behavioral details and usage context in just two sentences. Every sentence adds value without redundancy, making it efficient and well-structured.

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's complexity (6 parameters, no output schema) and rich annotations, the description is mostly complete. It covers purpose, behavior, and usage, but could improve by addressing potential limitations like rate limits or authentication needs, which are not mentioned in annotations or description.

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 has 100% description coverage, so the baseline score is 3. The description does not add any parameter-specific information beyond what the schema provides, such as explaining the 'q' parameter's role in rank tracking or the 'gl' parameter's impact on SEO results.

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's purpose: 'Get Google organic search results for SEO rank tracking.' It specifies the verb ('Get'), resource ('Google organic search results'), and context ('SEO rank tracking'), distinguishing it from sibling tools like google_search_light or google_scholar by focusing on rank tracking rather than general 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?

The description provides clear context for usage: 'Ideal for monitoring keyword rankings and SERP analysis.' This gives guidance on when to use it, but it does not explicitly state when not to use it or name specific alternatives among the sibling tools, such as google_search_light for general searches.

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 valuable behavioral context beyond annotations: it specifies what information is returned ('titles, authors, publication info, citation counts, and links to PDFs') and explains how to use the 'cites' and 'cluster' parameters with IDs from previous searches. This complements the annotations (readOnlyHint=true, openWorldHint=true) by detailing the search functionality and result format.

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 perfectly concise and front-loaded: the first sentence states the core purpose, the second describes the return format, and the third provides parameter guidance. Every sentence earns its place with zero wasted words, making it highly efficient for agent comprehension.

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's moderate complexity (7 parameters, no output schema) and rich annotations, the description is mostly complete. It covers purpose, return format, and key parameter usage. The main gap is lack of output structure details (since no output schema exists), but otherwise it provides sufficient context for effective tool selection and use.

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 100% schema description coverage, the schema already documents all 7 parameters thoroughly. The description adds minimal parameter semantics beyond the schema, only briefly mentioning 'cites' and 'cluster' usage. It meets the baseline of 3 since the schema carries the heavy lifting for parameter documentation.

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 specific action ('Search Google Scholar for academic papers, citations, and scholarly articles') and resource ('academic papers, citations, and scholarly articles'), distinguishing it from sibling tools like general web search or social media tools. It precisely defines the tool's scope within the academic domain.

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 for when to use specific parameters ('Use cites parameter to find papers citing a specific work, or cluster to find all versions of a paper'), but doesn't explicitly state when to choose this tool over alternatives like Google Patents Search or other academic databases. It offers good parameter-level guidance but lacks tool-level comparison.

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 provide readOnlyHint=true, openWorldHint=true, idempotentHint=false, and destructiveHint=false. The description adds useful context about the tool being 'fast' and for 'quick information retrieval', which suggests performance characteristics. It also mentions what the tool returns (organic search results, related searches, pagination), which is valuable since there's no output schema. However, it doesn't disclose rate limits, authentication needs, or other behavioral traits beyond what annotations cover.

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 and well-structured in just two sentences. The first sentence states the core functionality and outputs, while the second provides usage guidance. Every word earns its place with zero waste or redundancy. It's appropriately sized for this type of 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?

Given the tool's moderate complexity (search with 5 parameters), rich annotations, and 100% schema coverage, the description provides good contextual completeness. It explains the tool's purpose, when to use it, and what it returns. The main gap is the lack of output schema, but the description partially compensates by listing return types. For a search tool with good annotations and schema, this is reasonably 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 all parameters are well-documented in the schema itself. The description doesn't add any parameter-specific information beyond what's in the schema. With complete schema coverage, the baseline score of 3 is appropriate - the description doesn't compensate but doesn't need to since the schema handles parameter documentation adequately.

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's purpose: 'Perform fast Google web searches' with specific outputs (organic search results, related searches, pagination). It distinguishes from siblings by mentioning 'fast' and 'quick information retrieval', though it doesn't explicitly name alternatives. The purpose is specific but could be more differentiated from other 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 provides clear context on when to use this tool: 'Best for quick information retrieval when you don't need advanced filtering.' This gives positive guidance on appropriate use cases. However, it doesn't explicitly state when NOT to use it or name specific alternative tools for advanced filtering scenarios.

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, and openWorldHint=true, so the agent knows this is a safe, non-destructive search operation with open-world data. The description adds useful context about what the tool returns ('product listings with prices, sellers, ratings, and comparison shopping data'), which goes beyond the annotations. However, it doesn't mention rate limits, authentication requirements, or pagination behavior beyond the page parameter in the schema.

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

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

The description is perfectly concise with just two sentences that each serve a distinct purpose: the first explains what the tool does and what it returns, the second provides crucial sibling tool differentiation. There's zero wasted language 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 search tool with comprehensive annotations (readOnly, openWorld) and full schema coverage, the description provides good context about the return format and sibling relationship. The main gap is the lack of an output schema, but the description partially compensates by describing what's returned. It could be more complete by mentioning typical result structure or limitations.

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 100% schema description coverage, the input schema already documents all 10 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline of 3 where the schema does the heavy lifting for parameter documentation.

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's purpose with a specific verb ('Search for products') and resource ('on Google Shopping'), and distinguishes it from its sibling 'google_product' tool by explaining that this tool returns product listings while the sibling provides detailed product information. This explicit differentiation earns the highest 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 explicit guidance on when to use this tool versus alternatives by stating 'Use google_product tool with product_token to get detailed product information.' This clearly defines the boundary between this search tool and its sibling for detailed product lookup, meeting the criteria for a perfect score.

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, non-destructive, open-world, and non-idempotent behavior. The description adds useful context about the data source (Google Hotels) and global scope ('worldwide'), which helps the agent understand the tool's capabilities 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 a single, well-structured sentence that efficiently communicates the tool's core functionality without unnecessary details. Every word serves a purpose.

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 rich annotations and full schema coverage, the description provides adequate context about scope and outputs. However, without an output schema, it could benefit from more detail about result structure, but the mention of specific data types (pricing, ratings, amenities, availability) helps compensate.

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 documented in the schema. The description mentions search capabilities but doesn't add specific parameter details beyond what the schema provides. Baseline 3 is appropriate given the comprehensive 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's purpose: 'Search for vacation rentals using Google Hotels' with specific resources (apartments, villas, cabins, houses) and outputs (pricing, ratings, amenities, availability). It distinguishes from sibling tools like google_hotels by specifying vacation rentals rather than hotels.

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 vacation rental searches but doesn't explicitly state when to use this tool versus alternatives like google_hotels or other travel tools. No guidance on prerequisites or exclusions is provided.

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, non-destructive, and open-world behavior. The description adds context by specifying that it fetches 'public' profile information, which clarifies access scope beyond what annotations provide. However, it does not mention rate limits, authentication needs, or data freshness.

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 core purpose and follows with specific details about returned data. Every element serves a purpose with no wasted words, making it highly concise and well-structured.

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's simplicity (1 parameter, no output schema), annotations cover safety and scope, and the description details the returned data types. It is largely complete, though it could benefit from mentioning any limitations (e.g., data availability for private profiles) to fully contextualize usage.

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%, with the parameter 'username' clearly documented in the schema. The description does not add any additional meaning or clarification about the parameter beyond what the schema provides, so it meets the baseline for high schema 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 specific action ('Fetch public profile information from Instagram') and resource ('Instagram profile'), distinguishing it from sibling tools like tiktok_profile. It provides a comprehensive list of what information is retrieved, making the purpose explicit and distinct.

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 retrieving public Instagram profile data, but does not explicitly state when to use this tool versus alternatives like tiktok_profile or other social media tools. No guidance on prerequisites, limitations, or specific scenarios is provided.

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 context about what data is returned (bio, counts, verification status, links), which goes beyond the annotations. However, with annotations already declaring readOnlyHint=true, openWorldHint=true, and destructiveHint=false, the agent knows this is a safe, non-destructive read operation that can handle unknown usernames. The description doesn't mention rate limits, authentication needs, or error conditions.

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 perfectly concise and front-loaded. The first sentence establishes the core purpose, and the second sentence efficiently lists the specific data returned. Every word serves a clear purpose with zero 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 simple read-only tool with good annotations and complete schema coverage, the description provides adequate context. It clearly states what data is returned, which compensates for the lack of output schema. However, it doesn't mention potential limitations like rate restrictions or what happens with invalid usernames, leaving some behavioral gaps.

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 100% schema description coverage, the input schema fully documents the single required 'username' parameter. The description adds no additional parameter information beyond what's in the schema. This meets the baseline expectation when schema coverage is complete.

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 public profile information') and resource ('from TikTok'), making the purpose immediately understandable. It distinguishes from sibling tools like 'instagram_profile' by specifying the TikTok platform. However, it doesn't explicitly differentiate from other potential TikTok tools that might exist elsewhere.

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 no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, limitations, or compare it to sibling tools like 'instagram_profile' for similar social media profile fetching. The agent must infer usage context entirely from the tool name and description alone.

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