FastAF

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

Annotations already declare readOnly=true, non-destructive, open-world. The description adds useful context beyond them: results are 'current' only, no historical pricing, and a separate REST resource exists for offers/bestsellers. It stops short of mentioning rate limits, auth, or result freshness windows.

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 with no padding. The final sentence ('use REST amazon with resource') is slightly cryptic and relies on outside knowledge of a REST surface an agent may not have a tool for.

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 4-parameter read-only lookup with full schema coverage and no output schema, the description covers purpose, input constraint, and alternatives. Only minor gaps remain: no note on what a result object roughly contains or how asin vs query results differ in shape.

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 a constraint the schema does not formalize: 'Required: asin or query,' plus the implicit exactly-one relationship that is only partially hinted at by the query description. It does not add anything about results or marketplace beyond the schema.

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

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

States a specific verb and resource ('Return current Amazon products by ASIN or keyword') and immediately names the sibling it is not (google_shopping_prices). An agent can distinguish it from search_walmart, search_ebay, and google_shopping_prices without opening any schema.

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

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

Explicitly gives when-to-use ('Amazon lookups'), when-not ('not price history or other merchants'), and two named alternatives (google_shopping_prices, REST amazon for offers/bestsellers). Routing is unambiguous.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the 'public profile only' scoping constraint, a real hidden limitation, but says nothing about failure modes for private/deleted profiles or rate limits on an open-world scrape.

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, front-loaded with purpose, then exclusions, then the required parameter. Zero 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 one-parameter read tool with full schema coverage and annotations, the description covers purpose, scope, and the key exclusion. No output schema exists, so the mention of headline and summary is a helpful partial return preview, though error behavior on profile_id misses is unaddressed.

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% and the schema explains profile_id as the identifier from the profile URL. The description only restates 'Required: profile_id', adding no format, URL-shape, or vanity-handle detail beyond the schema. 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 (Return) and resource (public LinkedIn person profile) plus what fields come back (headline, summary). It also explicitly excludes company pages and people search, which no sibling name alone would clarify.

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

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

Explicitly names the exclusion (company pages, people search) and routes people search to google_search. It stops short of saying when *not* to use it entirely (e.g., use x_profile for X/Twitter, scrape_url as a fallback), but the negative 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety and reach profile is covered structurally. The description adds that results come with sources, which is useful, but says nothing about latency, cost, rate limits, or whether an AI answer might be absent for some queries. With annotations carrying the main burden, this is adequate but thin.

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 sentences, zero filler, with the core capability front-loaded before the sibling disambiguation and the required-parameter note. Every clause 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?

Annotations cover safety, the schema fully covers all three parameters, and there is no output schema to explain. The description hints at the return shape ("answer with sources"), which is enough for a simple three-parameter read tool, though a note about answer unavailability or localization effects would close the last 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%, and the country/language enums are fully self-documenting, so the schema does the heavy lifting. The description only restates "Required: query," which duplicates the schema's required array and adds no new meaning about how query phrasing affects the answer.

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 ("Return a Google AI Mode answer with sources") and immediately distinguishes it from the nearest sibling, google_search, by output type. An agent can pick between the two without opening either schema.

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

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

Explicitly names the alternative tool and the condition that selects it: "For organic result lists use google_search." That is a concrete when/when-not routing rule rather than implied usage.

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 safety is covered. The description adds value by disclosing the returned fields (address, rating, reviews, place ID), which matters because there is no output schema. It omits rate limits or API-key prerequisites, keeping it below a 5.

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

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

Two short sentences, front-loaded with the purpose and immediately followed by the sibling exclusion and parameter summary. Zero 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?

With no output schema, the description compensates by listing the returned fields, and the open-world nature is captured by annotations. Minor gap: it never mentions the results cap (max 20) or language filtering, which affect how an agent shapes a request.

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

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

Schema description coverage is 100%, so parameters are already documented in the schema. The description only restates required/optional status for query and location while ignoring the results and language parameters, adding no semantics beyond the schema. 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 ('Find local businesses') plus the data returned (address, rating, reviews, place ID), and explicitly excludes the sibling it is not ('Not general web pages (use google_search)'). An agent can distinguish it from google_search 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?

Explicitly names the alternative (google_search) and the condition that selects it (general web pages vs local businesses). No guidance on when to prefer other place-adjacent siblings like search_zillow or search_walmart, but the primary routing decision is covered.

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 useful context by naming the result fields, which matters because there is no output schema. It says nothing about result caps, pagination depth, or rate/credit costs.

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 compact sentences: scope and return shape first, the scrape_url routing second, parameter summary last. No filler and nothing buried behind preamble.

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, naming the returned fields is the right compensating move, and the scrape_url exclusion closes the main ambiguity. The remaining gap is pagination and result-count behavior, which the description leaves entirely to 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 coverage is 100%, so the schema fully documents all five parameters including the enum sets, page, and results. The description's 'Required: query. Optional: country, language' recaps only three of the five and silently omits page and results, so it adds no meaning beyond the schema and is mildly incomplete as a summary.

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 ('Find pages with Google organic results') and enumerates the returned fields (title, URL, snippet, position), which separates it from content-fetch tools. It does not distinguish itself from adjacent search siblings like search_news or google_ai_answer, so an agent must still reason about which search variant fits.

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

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

Explicitly carves out the boundary 'Not page contents (use scrape_url)' and names the alternative, which is the most likely confusion for a search tool. It stops short of saying when to prefer this over google_ai_answer or the other vertical search tools.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety and openness profile is covered. The description adds only that results span multiple merchants, and says nothing about result shape, pagination depth, or whether results can be empty — modest added value against a lower bar.

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 sentences with the capability statement front-loaded and the alternative routing second. 'Required: query' is mildly redundant with the schema's required list, a small amount of waste in an otherwise tight definition.

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 five-parameter read-only search with no output schema, the description covers what is returned at a high level (product prices and merchant offers) and how to route elsewhere. It omits result format and default country/language behavior, but those are minor for a simple search call.

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 query, page, results, country, and language are all documented in the schema itself. The description's only parameter information is 'Required: query', which restates the schema's required array, 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 — 'Compare product prices and merchants from Google Shopping' — and explicitly names the sibling it is not (amazon_product). An agent can distinguish this from search_walmart/search_ebay without opening any schema, since the scope is Google Shopping price comparison.

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 alternative and the condition that selects it: 'For Amazon-only product details use amazon_product.' However, it is silent on the other commerce siblings (search_walmart, search_ebay), leaving the agent to infer how this tool relates to them.

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

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

Annotations already declare readOnlyHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds the return format (markdown) and the fallback routing, but says nothing about paywalls/blocks, credit cost of premium or challenge_mode, or what happens on failure — all of that lives only in schema field descriptions.

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 sentences with the core capability front-loaded and routing details packed tightly into the second sentence. 'Required: url' is the one wasted clause since the schema already marks it required.

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?

Five parameters, 100% schema coverage, no output schema — the description correctly tells the agent what comes back (markdown) and which sibling to pick instead. The only gap is that cost implications of premium/challenge_mode are left entirely to 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 every parameter (url, premium, max_chars, render_js, challenge_mode) is already documented with defaults and credit costs. The description adds only 'Required: url', which merely restates the schema's required list, so the baseline 3 applies.

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

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

States a specific verb and resource ('Read one public URL as markdown') plus the output format, which is the key fact an agent needs. It also names the sibling tools it is not (google_search, and the Amazon/eBay/Zillow domain tools), so it is distinguishable without opening any 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?

Explicit routing: use for a known page, not discovery (google_search), not marketplace/real-estate data (their tools), and not for raw HTML/links/summaries (REST scrape). Both when-to-use and when-not-to-use are stated with the alternative named in each case.

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 safety and external-search behavior are covered. The description adds that results include prices, condition, and shipping, but does not describe rate limits, pagination, or other behavioral constraints 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 purpose and alternative routing are front-loaded and easy to scan. The final sentence partly repeats the REST eBay distinction, but overall the description is compact and appropriately sized.

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 three-parameter search tool with full schema coverage and safety annotations, the description is sufficiently complete. It explains the main purpose, required input, returned fields, and the item-search alternative, though it could say more about result 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?

Schema description coverage is 100%, and all three parameters are documented there, so the schema carries parameter semantics. The description reinforces that query is required and keyword-based, but adds little about domain or results beyond what the schema already states.

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: find eBay listings by keyword, with prices, condition, and shipping. It also distinguishes this search behavior from using the item-oriented REST eBay tool, so an agent can identify the intended operation.

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 routes single-item lookups to REST eBay with an item URL, and clarifies that REST eBay needs a site URL rather than a keyword. It does not discuss when to choose this over sibling shopping search tools such as search_walmart or google_shopping_prices, but it gives clear usage context.

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 safety and external-scope traits are covered. The description adds useful output context (company, location, apply links) but says nothing about result quality, pagination, or rate limits beyond the default the schema shows.

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, zero filler, with the core purpose and the sibling exclusion front-loaded before the requirement note. Every clause carries 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?

With no output schema, the description helpfully names the returned fields and the annotations cover the safety profile. Minor gap: no mention of pagination or how many results are typical, but the results parameter covers that at the schema level.

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 both the query and country/language/results semantics are already documented in the schema. The description only restates that query is required and hints at location filtering — no syntax or format detail beyond the schema, 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 (find) and resource (jobs) and names the key returned fields (company, location, apply links). It also carves out scope against a sibling (not company profiles), so the agent can distinguish it from google_search and search_news.

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

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

Explicitly names the alternative (google_search) and the case it covers (company profiles), plus notes the required query. Lacks guidance on when to use country/language localization or how this compares to the other search_* siblings (ebay, zillow, etc.).

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

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

Annotations already declare readOnlyHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds value by disclosing the shape of the results (titles, links, snippets), which matters since there is no output schema. It does not mention pagination behavior or result freshness limits.

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 sentences, all front-loaded: purpose first, then the disambiguation constraint, then the hard requirement. No sentence is 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 read-only search tool with full schema coverage and a clear safety annotation set, the description covers purpose, differentiation and return shape. Minor gaps remain around pagination semantics (zero-based page is only in the schema) and how country/language defaults resolve, but nothing blocks a correct invocation.

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

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

Schema description coverage is 100%, so all five parameters including page, country, language and results are already documented in the schema. The description only restates that query is required, which duplicates the required array, and adds no syntax or enum guidance. Baseline 3 applies when 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 and resource ("Find current news articles"), lists the returned fields (titles, links, snippets), and explicitly names the sibling it is not (google_search). An agent can distinguish this from general web search without opening either schema.

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

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

Provides an explicit exclusion plus the alternative to use instead ("Not general web search (use google_search)") and flags the required parameter. It stops short of spelling out the positive trigger conditions, e.g. that this is for recent/current events rather than research literature (search_scholar) or video (search_youtube).

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 safety and external-reach behavior are covered structurally. The description adds only marginally by implying citations are returned; it says nothing about result volume defaults, pagination exhaustion, or ranking behavior beyond what the schema already encodes.

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 with the capability first and the routing constraint second. No filler, no repetition of the title.

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 six parameters fully described in schema and annotations covering safety, the description supplies the only missing piece an agent needs: what domain of content this searches and where to go instead. No output schema exists, but 'citation details' gives a rough return-content signal; a note on result volume or pagination 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%, so every parameter (year_from/year_to, language, results, page) is already documented with ranges and an enum. The description adds no syntax or formatting guidance beyond restating 'Required: query', which the schema's required array already declares. 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+resource ('Find scholarly publications and citation details') and scopes it to 'by topic', which is enough to distinguish it from generic web search. It also names the sibling it is not (google_search), so an agent can route with confidence.

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

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

Explicitly gives the exclusion and the alternative: 'Not general pages (use google_search)'. Combined with the required-parameter callout, the when/when-not pair is unambiguous.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that results include prices and availability, but it does not discuss result ordering, pagination, or other behavioral details 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 short and front-loads the core purpose and alternative. The final REST walmart note is somewhat tangential but still concise and potentially clarifying.

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 two-parameter search tool with full schema coverage and annotations, the description covers purpose, alternative, and required input adequately. It does not explain return structure in detail, but no output schema exists and the tool is straightforward.

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 query and results parameters. The description only repeats that query is required and does not add semantics beyond what the schema 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 states a specific verb and resource: find Walmart products by keyword, including prices and availability. It also explicitly distinguishes the tool from google_shopping_prices, so an agent can identify its scope without inspecting 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 names the alternative for other merchants and the condition that selects it: use google_shopping_prices for other merchants. It also clarifies the required query input and distinguishes this from the REST API's URL-based requirement.

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 safety is covered. The description adds value annotations cannot: it discloses the shape of the response (titles, URLs, channels, durations) in the absence of an output schema. It omits the 20-result cap and rate-limit behavior, which the schema partially covers.

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 fragments, zero filler, with the primary purpose front-loaded ahead of the exclusion and the required parameter. Nothing could be removed without losing routing 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 four-parameter search tool with annotations and rich schema coverage, the definition covers purpose, the key alternative, and the return shape. The only gap is the absence of any hint about result limits or result ordering, which is minor given the schema constrains 'results' to 1–20.

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% — query, country, results and language are all documented in the schema with enums and bounds. "Required: query" merely restates the schema's required list and adds no syntax or format meaning. Baseline 3 is appropriate when 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 and resource ("Find YouTube videos by keyword") and previews the returned fields (titles, URLs, channels, durations). It explicitly names the sibling it is not (youtube_transcript), so an agent can distinguish the two without opening either schema.

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

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

"Not transcripts (use youtube_transcript)" is an explicit exclusion paired with the correct alternative, which is exactly the routing decision an agent needs. It does not discuss when to prefer this over general web search siblings like google_search, so it falls short of full when/when-not coverage.

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

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

Annotations already cover the read-only, non-destructive, open-world safety profile. The description adds useful return-content context (address, price, beds, baths), though it does not discuss rate limits, data freshness, or failure 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 short and front-loaded, with the core output described first, then the input constraint and alternative. Every sentence contributes directly to correct tool selection or invocation.

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 two-parameter read-only tool with full schema coverage and no output schema, the description provides enough context: purpose, returned fields, URL-vs-keyword constraint, required parameter, and an alternative 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 coverage is 100%, so the schema already documents both url and results, including examples and bounds. The description only reinforces that url is required and that it is a site URL rather than a keyword, adding limited meaning 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 states a specific verb and resource: returning home listings from a Zillow search URL, including the key returned fields. It also explicitly distinguishes the tool from keyword-based general search and from google_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?

It clearly says the input must be a Zillow site URL rather than a keyword and directs general search use to google_search. This gives the agent an explicit alternative and condition for choosing 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 readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only the 'public' qualifier, which hints that private/suspended accounts may not resolve, but it says nothing about rate limits, failure behavior for missing users, 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?

Three short sentences with the capability front-loaded and the exclusion immediately after; nothing is buried. The trailing 'Required: username' is redundant with the schema's required array and is the only sentence that doesn't fully 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?

For a one-parameter read tool with no output schema, the description covers what it returns (profile fields plus follower counts) and which platform it targets, which is sufficient to call it correctly. Only the missing/private-account edge case remains undocumented.

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?

There is a single required parameter with 100% schema description coverage, including the at-sign pattern and length bounds. 'Required: username' merely restates the schema and adds no format or syntax detail beyond it, so the baseline 3 applies.

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

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

States a specific verb and resource ('Return a public X profile and follower counts') and names the scope ('by username'). It also rules out the most likely confusion by saying it is not posts or keyword search, so an agent can distinguish it from google_search and get_linkedin_profile (different platform) 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?

Provides an explicit exclusion ('Not posts or keyword search') with the correct alternative ('use google_search for indexed pages'). The positive 'when to use' case (wanting a profile or follower counts) is only implied rather than stated, which is the one gap.

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 safety profile is covered. The description adds the output shape ('timestamped transcript text') and the precondition of a known video ID, but is silent on failure modes such as videos with transcripts disabled or language fallback behavior, which matter for an open-world fetch.

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, zero padding, with the primary action stated first and the disambiguation and required input following. 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?

With no output schema, the description correctly characterizes the return value as timestamped transcript text, and it names the required input. It leaves out edge-case behavior (unavailable transcripts, default language/country), which is the only material gap for a simple 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 coverage is 100%, so all three parameters including the enum values for language and country are fully documented in the schema. The description only reiterates that video_id is required and adds nothing about how language/country affect retrieval, 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+resource (return timestamped transcript for a YouTube video ID) and explicitly distinguishes itself from the sibling search_youtube by naming it. An agent can select this vs. discovery tools 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?

Explicitly says it is 'Not video discovery (use search_youtube)' and flags the required video_id, giving a clear when-to-use and a named alternative. It stops short of guidance on the optional language/country parameters or what to do when no transcript exists in the requested language.

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