Vee3

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

No annotations provided, but the description discloses the return format (JSON object mapping domains to booleans) and token cost (5 API tokens). This adds behavioral context beyond the schema, though it does not detail error behavior or rate 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 concise sentences: first states the action, second explains the output, third mentions token cost. No wasted words, front-loaded with key 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?

Given a simple single-parameter tool with output schema indicated, the description covers main functionality, return format, and token cost. It lacks error handling details but is sufficient for most use cases.

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% with clear description for the single parameter 'domains'. The description reinforces the max 10 domains and adds context about the return format and token usage, adding value beyond the schema.

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

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

The description clearly states the tool checks domain name availability for up to ten domains, returning a JSON object with booleans. This is distinct from sibling tools like domains.dns_records, domains.lookup, and domains.whois.

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 checking availability but provides no explicit guidance on when to use this tool versus alternatives, nor does it mention when not to use it.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool is read-only by nature, returns an array of records with specific fields, and mentions the API token cost (2 tokens). It does not discuss error handling, rate limits, or pagination, but for a simple fetch tool, this is adequate.

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

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

The description is three sentences, each earning its place. The first sentence states the action, the second describes the return format, and the third explains the optional parameter with an example. No fluff or redundant 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?

Given the tool's simplicity, the description covers the return format, parameter usage, and token cost. An output schema exists, so deep return value documentation is unnecessary. It lacks mention of error conditions or edge cases, but for a straightforward fetch tool, it is nearly 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?

The input schema provides descriptions for both parameters (100% coverage), so the baseline is 3. The description adds value by including an example usage for the subdomain parameter ('blog for blog.example.com'), clarifying the relationship between domain and subdomain. This enhances the schema's meaning.

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 starts with 'Fetch DNS records for a domain,' clearly stating the action and resource. It explains the returned record fields. While the name itself is descriptive, it does not explicitly differentiate from sibling tools like 'domains.lookup', but the purpose is still clear.

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 states when to use (to fetch DNS records) and notes optional subdomain usage. However, it does not provide explicit guidance on when not to use this tool or mention alternatives among siblings. The context is clear but lacks exclusions.

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?

With no annotations provided, the description fully discloses behavioral details: token cost (2 API tokens), default limit (100), explanation of availability values, and response fields. This compensates for missing annotations and clearly informs the agent about side effects and expectations.

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, well-structured, and front-loaded with the primary purpose. Every sentence adds value: purpose, filtering options, defaults, token cost, and response contents. No redundant or unnecessary 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?

Given the presence of an output schema and no annotations, the description provides complete context: explains filtering, pagination, defaults, token usage, and response fields. It covers all necessary aspects for an agent to use the tool effectively.

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 description adds value beyond the schema by explaining the default value for limit (100) and the meaning of availability values ('general-availability', 'sunrise'). This augments the parameter definitions with contextual information.

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

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

The description explicitly states 'List or search top-level domains (TLDs) with registry metadata,' which clearly identifies the action (list/search) and resource (TLDs). This distinguishes it from sibling tools like domains.tld_details, which is for a single TLD.

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 criteria for use: 'Filter by substring search, availability phase, TLD category, and paginate with limit and page.' It implies when to use (listing/searching multiple TLDs) versus alternatives (e.g., tld_details for a specific TLD), but does not explicitly state when not to use or name 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?

With no annotations, the description carries full burden. It describes data sources (registry/registrar RDAP+WHOIS), normalization, returned fields, and token cost. Missing details about rate limits, idempotency, or error behavior, but overall transparent.

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

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

Three sentences, 60 words, front-loaded with the core action, followed by details and usage guidance. No fluff 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 simple one-parameter input, existence of an output schema, and clear description covering purpose, usage, and returned fields, the description is complete for an agent to select and invoke the tool correctly.

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

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

Schema coverage is 100% for the single 'domain' parameter, so the description adds little beyond the schema's own description. The schema already provides an example, so no additional semantics are needed. Baseline score of 3 is appropriate.

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

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

The description clearly states the verb 'look up' and resource 'domain', and distinguishes itself from sibling tools like domains.whois and domains.rdap by emphasizing normalized registration details from combined sources. It also lists the specific fields returned, making the purpose very clear.

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 'Use this when you need registrant-oriented summary data rather than raw WHOIS or RDAP payloads', providing both when-to-use and alternatives. Also mentions token cost, aiding decision-making.

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?

No annotations are provided, so the description carries the full burden. It discloses token cost (40 API tokens) and lists returned data, but does not mention error behavior, rate limits, or what happens for invalid domains. This is adequate but not comprehensive.

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

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

The description is well-structured with a clear first sentence followed by a bullet-like list of metric categories and token cost. It is front-loaded but could be more concise by reducing the detailed enumeration.

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 simple input schema, presence of output schema, and disclosure of token cost, the description is fairly complete. However, it lacks details on error handling or constraints, which would improve 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 coverage is 100% with a single parameter 'domain' described as 'Domain name to analyze (for example example.com).' The tool description adds no additional semantic meaning beyond the schema, earning the baseline score.

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 analyzes a domain with comprehensive SEO metrics, backlink data, and social signals. It specifies the verb 'analyze' and lists specific metric categories, distinguishing it from sibling tools like domains.whois or domains.dns_records.

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 does not provide explicit guidance on when to use this tool versus alternatives. While it implies usage for obtaining domain metrics, it omits conditions or exclusions, such as when to prefer other tools like seo.basic_metrics or domains.lookup.

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?

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only mentions token cost (3 API tokens) but does not state whether the operation is read-only, idempotent, or if any side effects occur. This is insufficient for an agent to assess safety.

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 brief (three sentences) and front-loaded with the core purpose. Every sentence contributes meaningful information—purpose, return data, and token cost. No wasted words.

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

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

Given the tool's simplicity (single parameter, output schema exists), the description covers the main aspects: purpose, returned data, and token cost. It lacks usage guidelines and is slightly thin on behavioral transparency, but overall it is sufficient for a basic lookup tool.

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

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

Schema description coverage is 100%, with the single 'domain' parameter already described in the schema as 'Domain name to look up (for example example.com).' The tool description adds nothing beyond that, so the baseline score of 3 is appropriate.

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

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

The description clearly states 'Look up raw RDAP data for a domain' and lists the returned data types. This provides a specific verb+resource. However, it does not explicitly distinguish this tool from sibling tools like 'domains.lookup' or 'domains.whois', leaving some ambiguity for the agent.

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 offers no guidance on when to use this tool versus alternatives. It does not mention scenarios where RDAP is preferred over WHOIS or other lookup tools, nor does it exclude any cases.

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?

No annotations are provided, so the description carries the full burden. It discloses important behavior: the tool returns a detailed set of fields (status, type, servers, etc.) and that 'Successful calls use 1 API token.' This adds context about token cost and indicates it is a read-only operation, though permission requirements are not mentioned.

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: four sentences that respectively state the purpose, list return fields, provide usage instructions, and note the API token cost. Every sentence adds value, with no repetitive or extraneous 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?

Given the tool's simplicity (one parameter) and the presence of an output schema (not shown), the description provides sufficient context: what it does, what it returns, how to call it, and cost. It could be improved by noting that it is read-only or mentioning error scenarios, but overall it is adequately 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?

The input schema has one parameter with 100% description coverage. The description repeats the format requirement ('without a leading dot') and provides examples ('io or com'), which adds marginal value beyond the schema. With complete schema coverage, a baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Look up detailed registry information for a single top-level domain (TLD).' It lists specific return fields, distinguishing it from sibling tools like domains.list_tlds (which lists all TLDs) and domains.whois/domains.rdap (which operate on domain names, not TLDs).

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 usage guidance: 'Pass the TLD suffix without a leading dot (for example io or com).' However, it does not explicitly state when to use this tool versus alternatives like domains.whois or domains.rdap, nor does it mention when not to use it. The context is implied but not explicit.

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?

With no annotations provided, the description effectively discloses the return format (JSON object keyed by server, parsed fields, raw text), the effect of include_registrar on speed/completeness, and token cost (4 tokens). No contradictions.

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

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

Four sentences with zero waste: first states purpose, second describes return, third explains parameter, fourth notes cost. Efficient and 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?

Given a simple tool with 2 parameters, 100% schema coverage, and existence of output schema (per context), the description covers purpose, return format, parameter effect, and cost. Missing only error handling or edge cases, but overall 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 coverage is 100%, so baseline is 3. The description adds value by mentioning the 'slower' trade-off for include_registrar beyond the schema's description, and clarifies the default behavior. This justifies a 4.

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 the specific verb 'Fetch' and resource 'WHOIS registration data for a domain'. It clearly differentiates from sibling tools like domains.lookup (DNS) and domains.rdap (RDAP) by focusing on WHOIS data.

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 explains the trade-off of the include_registrar parameter ('slower, more complete') but does not explicitly compare WHOIS to alternatives like RDAP or when to choose this tool over others, leaving the agent to infer 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?

No annotations, so description adds value by stating successful calls use 1 API token. Non-destructive read operation implied, but not explicitly stated.

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 concise sentences with front-loaded purpose, followed by token usage note. No unnecessary 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?

For a zero-parameter tool with output schema, description explains output and use case completely. No missing information.

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?

No parameters, so schema coverage is 100%. Description adds meaning by explaining output format and usage, beyond what schema (empty) 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?

Clear verb 'List' with specific resource 'supported language codes for Google Maps place endpoints'. Distinguishes from sibling tools like place_details or search by being a supporting utility.

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 to use these codes with language parameter on other calls. No when-not-to or alternatives, but simplicity of tool and lack of similar siblings compensates.

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?

No annotations provided, but the description thoroughly discloses behavior: default radius (1000m when sort_by Relevance), token cost (10 API tokens), pagination via cursor, and that additional upstream fields may appear. No contradictions.

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

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

Well-structured with main purpose first, followed by parameter details and usage notes. Relatively concise given the number of parameters, but could be slightly shortened without losing information.

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

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

Given 11 parameters (1 required) and existence of output schema, the description covers essential usage patterns, return fields (places), pagination, and cost. It is complete for an agent to use correctly.

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

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

Schema description coverage is 100%, but the description adds value by explaining default radius behavior, parameter interdependencies (sort_by and radius/keyword), and pagination cursor usage, going 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?

Clearly states it searches for places near a location. The verb 'search' and resource 'places' are specific, but it doesn't explicitly differentiate from sibling search tools like 'google-maps.search'. However, the name 'nearby_search' implies the scope, and the description adds location requirement.

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 conditional usage: when sort_by is Distance, omit radius and provide keyword or place_type. Mentions cursor for pagination. Does not explicitly state when to use alternatives, but gives clear context for parameter interactions.

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?

With no annotations, the description fully addresses transparency by listing returned fields, noting that additional upstream fields may appear, and disclosing the API token cost (4 tokens per successful call). It does not mention auth or rate limits, but the read-only nature is clear.

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?

Four concise, front-loaded sentences. First states purpose, second gives input guidance, third lists output fields, fourth mentions token cost. No redundant or vague language.

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 presence of an output schema, the description competently lists major fields and warns of extra fields. It covers token cost and input options. Minor omission: no mention of error handling or pagination (not applicable). Adequate for a simple detail fetch 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% with each parameter fully described (place_id examples, region/language formats). The description adds minimal semantic value beyond the schema, such as the context of obtaining place_id from search results, but it's already implied.

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 'Get detailed information for a Google Maps place' with a specific verb and resource. It distinguishes itself from sibling tools like search, photos, and reviews by requiring a place_id from search results and providing detailed fields.

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 instructs to provide place_id from search results, notes the alternative business identifier form, and mentions optional region/language. It implicitly guides when to use (after search) but does not explicitly state when not to use or list alternatives, though siblings are distinct.

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?

With no annotations, the description carries full burden. It discloses API token cost (3 tokens), pagination behavior, return structure (photos array, metadata, cursor_next), and mentions additional upstream fields. Could note error conditions or idempotency, but currently informative.

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?

Description is moderately concise with 6 sentences, each contributing: purpose, required input, optional params, pagination, return details, cost. Well structured and front-loaded, though minor redundancy (e.g., place_id mentioned twice).

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?

Output schema exists, so description doesn't need to detail return values. It covers purpose, input, pagination, and cost. 'Additional upstream fields' is vague but acceptable. For a 4-param tool with output schema, this is sufficiently 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 coverage is 100%, so baseline is 3. The description adds value by explaining cursor usage (pass from previous response), place_id formats (business identifier form), and purpose of region/language. This enriches parameter understanding beyond 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 'Get photos for a Google Maps place', specifying the exact resource and action. It distinguishes from sibling tools like place_details or place_reviews by focusing on photos, making selection 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?

Provides clear context: use place_id from search results, optional cursor/region/language, and pagination with cursor_next. Lacks explicit 'when not to use' alternatives, but context is sufficient given sibling tool names.

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?

No annotations provided, so description carries the burden. It discloses token cost (3 API tokens), pagination behavior (cursor_next condition), and return structure (reviews array with specific fields). No contradictions.

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

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

Well-structured with clear front-loading of purpose. A few sentences could be merged, but overall each sentence adds meaningful information. Not excessively verbose for the amount of detail.

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 output schema exists, description appropriately covers pagination, token cost, and key return fields. Could mention that it does not include place details (those are in place_details), but otherwise complete for the tool's function.

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 covers all parameters with descriptions. Description adds value by explaining the business identifier form for place_id, listing sort_by options, and clarifying cursor usage. Exceeds schema-only info.

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 'Get reviews for a Google Maps place' and distinguishes from sibling tools like place_details and place_photos. However, it does not explicitly differentiate from review_details, which might overlap.

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 basic usage guidance: provide place_id from search results and use cursor for pagination. But lacks explicit when to use vs alternatives (e.g., review_details) and does not state when not to use.

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?

No annotations provided, so description carries full burden. It discloses that successful calls use 1 API token and returns a string array, adding behavioral context beyond the null 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?

Three sentences, each earning its place: first states purpose, second explains usage, third provides API token cost. No waste, 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?

Given zero parameters and existence of output schema, description covers purpose, usage, and cost. It could mention if the list is static or dynamic, but is otherwise 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?

No parameters exist, so baseline is 4. Description adds value by explaining that the output is a list of place_type values for use in other tools.

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

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

Description clearly states verb 'List' and resource 'supported Google Maps place type values', and distinguishes from siblings like google-maps.search and google-maps.nearby_search by specifying its role as a source of filter values.

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 tells when to use the output: 'Use a value with place_type on google-maps.search or google-maps.nearby_search.' It lacks explicit when-not-to-use or alternatives, but the guidance 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?

No annotations are present, so the description carries full burden. It discloses that the tool returns one review object with specific fields, notes that additional upstream fields may appear, and specifies token usage: 'Successful calls use 2 API tokens.' This is transparent about what to expect, including potential extra fields.

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

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

The description is three sentences: first states purpose, second gives guidance, third mentions token cost and extra fields. It is front-loaded, no wasted words, and each sentence earns its place.

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

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

Given an output schema exists (from context signals), the description need not detail return values but still mentions key fields and potential extras. It covers the input source, token cost, and expectations. For a single-parameter tool, this is complete and informative.

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% (the parameter 'review_id' has a description in the schema). The description adds useful context: 'Provide review_id from a place reviews response', which tells the agent where to obtain the value. This adds value beyond the schema's 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 states 'Get details for one Google Maps review' which is a specific verb and resource. It clearly distinguishes from sibling tools like place_reviews which list reviews, and explains the input is a review_id from a place reviews response.

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

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

The description explicitly says 'Provide review_id from a place reviews response', guiding the agent to use this after obtaining a review_id via another tool. It does not explicitly state when not to use it or name alternatives, but the context is clear and sufficient for a straightforward detail retrieval tool.

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

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

With no annotations, the description bears full burden for disclosing behavioral traits. It mentions token cost (10 tokens per successful search), pagination cursor availability, and that additional upstream fields may appear. It omits rate limits, error handling, or behavior on empty results.

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: first sentence states purpose, then filter list, pagination, return fields, follow-up, cursor notes, upstream fields, and token cost. Every sentence adds useful information 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 has 10 parameters and an output schema, the description covers input, pagination, output fields, and cost. It explains how to use results with other endpoints. It does not mention sorting or ordering, but overall is fairly complete for a 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 description's parameter summary adds marginal value. It lists the optional filters and mentions radius default (1000 meters), which is not explicit in the schema (schema shows default null). This adds some value but not significant.

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 Maps by text query, which is a specific verb and resource. It lists return fields and follow-up actions, but does not explicitly differentiate from sibling tool nearby_search, which also searches by location-based criteria.

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 explains optional filters, pagination via cursor, and how to use place_id for further endpoints. However, it lacks explicit guidance on when to use this tool versus alternatives like nearby_search, and does not mention prerequisites or constraints.

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?

No annotations are provided, but the description includes token cost information ('5 API tokens') and the return structure (normalized query, suggestions). This adds useful behavioral context beyond the basic functionality.

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 with two sentences: the first states the purpose, the second adds return details and cost. No superfluous words.

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

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

Given the simplicity (1 param, output schema exists), the description covers the return structure and token cost. It could mention that suggestions are for Google Search only, but overall it is 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 coverage is 100% with a clear description for the single parameter. The tool description does not add new semantic meaning beyond what the schema already provides, earning a baseline score of 3.

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

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

The description clearly states the action ('Get'), the resource ('Google Search autocomplete suggestions'), and the context ('for a partial query'). It distinguishes itself from sibling tools like google-search.search or youtube.search_autocomplete.

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 when needing autocomplete suggestions but does not explicitly state when to use or avoid this tool compared to alternatives like keyword_traffic_insights or 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?

No annotations provided, so description carries full burden. Discloses token cost (20 per successful call), return format (array with text, volume, competition, bids, trend), and parameter behavior. Does not specify if it's read-only, but the name and context imply a safe query. Sufficient for a read tool.

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

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

Well-structured: starts with purpose, then return format, then parameters, then token cost. No redundancy, each sentence adds value. Could be slightly more concise by grouping optional params, but current length is appropriate.

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 output schema exists, description covers return fields, all parameters, and token cost. Missing details like pagination or error handling, but for a keyword insights tool, this is adequate. No major gaps for typical 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?

Schema coverage is 100% with param descriptions, so baseline is 3. Description adds practical examples (language 'en', location 'US'), clarifies default for mode ('all') and location (global), and explains intent filter values. This enhances understanding beyond 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?

Starts with clear verb+resource: 'Get Google keyword traffic insights and related keyword suggestions for a seed keyword.' Differentiates from sibling tools like google-search.url_traffic_insights and seo.keyword_metrics by specifying it returns suggestions with volume and competition data.

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?

Lists required and optional parameters with examples (e.g., language 'en', location 'US') but provides no explicit guidance on when to use this tool vs alternatives like seo.keyword_metrics or google-search.url_traffic_insights. Usage is implied but not contrasted.

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?

With no annotations, the description carries the full burden. It discloses that there are no request parameters, the output is an array with name and code, the token cost per successful call (5 tokens), and the mapping to upstream API. It does not mention rate limits or error conditions, but for a simple listing tool, 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 extremely concise: four sentences, each serving a purpose. The first sentence states the core function, the second details the output, the third provides upstream mapping context, and the fourth notes the token cost. No unnecessary words.

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

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

Given the tool's simplicity (zero parameters, defined output schema), the description covers all essential aspects: purpose, output format, context of use (which tools consume this), and token cost. It is complete for the tool's role as a helper listing.

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 are no parameters, and schema coverage is 100%, so the baseline is 4. The description adds value by explaining the output fields (language_name and language_code) and providing an example, which helps the agent understand the return format beyond the schema.

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

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

The description clearly states what the tool does: list languages that can be used as the 'language' parameter in two specific sibling tools (google-search.keyword_traffic_insights and google-search.url_traffic_insights). It also specifies the output format (language_name and language_code) and mapping to the upstream provider API, leaving no ambiguity about its purpose.

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

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

The description explicitly says the languages are for use with two specific tools, guiding the agent on when to call this tool (before those tools). It does not mention when not to use it, but given the narrow scope, the guidance is clear and sufficient. It names the sibling tools that consume the output, which is helpful.

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?

No annotations are provided, but the description fully compensates by stating that successful calls use 5 API tokens and returns an array with country_name and country_code. This covers cost, return format, and the non-destructive nature of the tool.

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: purpose, return format, token cost. No fluff, front-loaded with the most important 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?

Given the tool has no parameters and an output schema exists, the description fully covers what it does, what it returns, and how it relates to sibling tools. No 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?

The input schema has zero parameters and schema coverage is 100%. The description confirms 'No request parameters,' adding value beyond the schema by clarifying the lack of inputs.

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

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

The description clearly states it lists countries and region codes for use as location parameter in google-search.keyword_traffic_insights and google-search.url_traffic_insights. It specifies the return format (array with country_name and country_code). No sibling tool has the same function.

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 mentions the two tools where the output can be used as location input. It states there are no request parameters. While it doesn't explicitly exclude other uses, the context is clear and no alternatives are needed.

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?

No annotations are provided, so the description carries the full burden. It mentions successful calls use 20 tokens, which is useful cost information, but does not disclose other behavioral aspects like idempotency, data freshness, or error handling. The description implies a read-only operation.

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 brief and efficient: two sentences for purpose and output, one for parameters. It is front-loaded with the core action and uses no superfluous words, earning its place.

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

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

Given the presence of an output schema, the description need not detail return values, but it lists the fields. It covers all parameters with examples and defaults. It lacks information on error handling or rate limits, but for a tool with moderate complexity and high schema coverage, it is sufficiently 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?

Input schema covers all parameters with descriptions (100% coverage), establishing a baseline of 3. The description adds value by providing concrete examples (e.g., language 'en', location 'US'), clarifying defaults (min_search_volume 0), and listing possible intent values (informational, navigational, commercial, transactional).

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 retrieves Google keyword traffic insights and keyword suggestions for a given URL, specifying the action, resource, and scope. It distinguishes itself from sibling tools like google-search.keyword_traffic_insights by focusing on URL input.

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 lists required and optional parameters with examples, and explains default behavior for location. However, it does not explicitly state when to use this tool over alternatives or provide exclusion criteria, leaving usage context implied.

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?

No annotations, so description carries full burden. It mentions API token cost (5 tokens) and return structure (cat array and msg), but does not explicitly state it is read-only or that no parameters are required. This is adequate but not comprehensive.

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 concise sentences, front-loaded with purpose, no unnecessary words. Highly 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?

For a zero-parameter tool with an output schema, the description fully explains the purpose, usage context, return structure, and token cost. No gaps detected.

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?

No parameters exist (schema coverage 100%), so the description adds no param info. Baseline 4; the description is not penalized but also does not earn extra credit.

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 lists Google Trends category and subcategory labels for use in other tools, with a specific verb 'List all'. It distinguishes itself from siblings (e.g., interest_over_time) by being the only tool for categories.

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 to use before interest-over-time or interest-by-region calls when filtering by category. However, it does not mention when not to use or alternatives, but the guidance is clear and context-specific.

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?

No annotations are provided, so the description carries full burden. It discloses the return format, token cost (40 tokens), and parameter defaults, but does not discuss error behavior, 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 a single paragraph of 5 sentences, front-loading the main action and then efficiently covering parameter details. No wasted words.

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

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

With 8 parameters fully described in the schema and an output schema presumed to exist, the description covers return format and token cost. It is nearly complete for an agent to use correctly, though missing error handling.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value by explaining parameter defaults, the requirement for datetime-with-timezone format, and the token cost, going 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 'Fetch Google Trends interest-by-region breakdowns for one to five keywords.' This is a specific verb+resource that clearly distinguishes from sibling tools like interest_over_time or 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 clear context on parameter requirements (start required, end defaults, country defaults, etc.) but does not explicitly state when to use this tool vs alternatives like interest_over_time.

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?

No annotations provided, so description carries full burden. It discloses return format (JSON with keyword keys, score 0-100), granularity dependency on date range, parameter defaults, and token cost (40). It does not explicitly state idempotency but 'fetch' implies read-only. No contradictions.

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

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

The description is a single paragraph of three sentences plus token cost note. Front-loaded with main action. Every sentence adds value with no redundancy. Highly efficient.

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 7 parameters, required 2, and an output schema, the description covers key aspects: return format, granularity, defaults, token cost. It omits explicit detail on the output structure beyond top-level keys, but output schema compensates. Overall, sufficient for agent understanding.

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% (all 7 parameters described), so baseline is 3. Description adds value beyond schema: explains granularity, token cost, and scope of return values. For example, 'Granularity depends on the requested date range' is not in 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?

Clearly states the tool fetches Google Trends interest-over-time series for one to five keywords. The verb 'Fetch' and resource 'interest-over-time series' are specific. Sibling tools like interest_by_region and related_queries are distinct, so purpose is well-differentiated.

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 explicit guidance on when to use this tool versus siblings. It provides constraints (up to 5 keywords, date format) but does not mention alternatives or exclusion cases. The agent must infer usage from the description 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?

No annotations, but the description discloses the tool is read-only (listing) and specifies a token cost of 5 API tokens. This adds behavioral context beyond the empty annotations, though it could mention non-destructive nature more explicitly.

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?

Four sentences with no wasted words: purpose, return details, usage guidance, and token cost. Front-loaded with the main action, each sentence earns its place.

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

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

Given zero input parameters and an output schema, the description fully explains what the tool returns and when to use it. Token cost is included, making it complete for a simple lookup 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?

No parameters exist (schema coverage 100%), so the description need not add param info. However, it still adds value by describing the return object structure (countries map with label and regions), which is relevant context.

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

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

The description clearly states it lists countries and subregions for use in other Google Trends tools. It specifies the return structure (geo.countries with label and regions array) and distinguishes itself from siblings by being the geography reference tool.

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

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

Explicitly tells when to use: before interest-over-time or interest-by-region calls when filtering by geography. Also suggests pairing with google-trends.categories for category filtering, providing clear context with siblings.

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

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

With no annotations, the description fully discloses return structure (top/rising sections with query and value mappings), parameter defaults, required format for start, and token cost (40 API tokens per successful call). It could add error handling details.

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 reasonably concise, front-loading the purpose and using short paragraphs for details. A few sentences could be tightened, but it's 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?

Despite 7 parameters and existence of output schema, the description covers all essential aspects: purpose, return structure, parameter constraints, defaults, and cost. It is complete for an agent to use correctly.

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

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

Schema coverage is 100%, baseline 3. The description adds meaning by explaining the datetime format for start/end, defaults for all optional parameters, and the dependency between region and country, going 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 starts with 'Fetch Google Trends related queries for one to five keywords,' providing a specific verb and resource. It clearly distinguishes this tool from siblings like interest_by_region, interest_over_time, and suggestions by name and function.

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 explains constraints (1-5 keywords, required start format) and refers to sibling tools (categories, regions) for valid values, but does not explicitly guide when to use this tool over other Google Trends 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?

No annotations provided, so description must disclose behavior. Discloses API token cost (10 tokens) but does not explicitly state read‑only nature or error handling. Sufficient for a simple lookup but with room for improvement.

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?

Four sentences covering purpose, return data, usage guidance, and cost. No fluff, every sentence adds value. Front‑loaded with the key action.

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

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

Covers what the tool does, what it returns, when to use it, and cost. Does not mention result limits or error cases, but for a straightforward suggestions tool with an output schema, this is nearly 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 coverage is 100% but description adds value by clarifying it expects a 'single keyword', complementing the schema's 'keyword or phrase'. Also describes output structure (mid, title, type) beyond 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 action ('Get Google Trends suggestions') and the resource ('a single keyword'), and distinguishes from sibling tools like interest_by_region and interest_over_time by specifying it's for keyword refinement.

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 instructs to use this tool before interest-over-time, interest-by-region, or related-queries calls, providing clear context and sequencing.

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?

No annotations provided, so description carries full burden. It discloses that the call is free (0 tokens) and what it returns, adding behavioral context beyond a simple 'describe'.

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 concise sentences: first states purpose, second gives usage context. No unnecessary words, front-loaded with key 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?

Given the presence of an output schema, the description adequately explains what the tool returns (parameter names, defaults, response fields, examples, token cost) and that it's free. No 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?

Schema coverage is 100% with a clear description. The tool description adds minimal extra meaning beyond the schema, meeting 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: 'Describe a single Vee3 capability by id.' It specifies what information is provided (parameter names, defaults, response fields, examples, token cost), distinguishing it from meta-tools.list_all.

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 usage guidance: 'Use this after meta-tools.list_all when you need parameter names, defaults, response fields, examples, and token cost before calling a tool. This call is free (0 tokens).' This tells when and why to use it.

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

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

No annotations provided, so description carries the full burden. It discloses that the tool lists live tools and their REST bindings, and that it's free (0 tokens). This is transparent for a read-only discovery tool.

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?

Extremely concise: two sentences that front-load the action and provide necessary context. No redundant 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?

Given the tool has no parameters and an output schema (exists but not shown), the description fully explains the output scope (list of tools, bindings, costs). The free cost is also noted, making it complete for a listing 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?

No parameters exist, so schema coverage is effectively 100%. The description adds value by explaining what the output contains (REST bindings and token costs) beyond the schema, which would not capture that.

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

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

Description clearly states it lists all live Vee3 agent tools with REST bindings. The verb 'list' and the specific resource 'tools' make it distinct from sibling tools, which are specific domain 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?

Explicitly says when to use: to discover existing tools, MCP names, and costs. It also notes the call is free. However, it does not mention when to avoid using it or suggest alternatives, though for a meta listing tool this is sufficient.

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?

Discloses that the call is free (0 tokens), providing cost transparency beyond the tool's basic functionality.

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 concise sentences: first states purpose, second gives usage guidance and cost info. No wasted words.

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

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

Given no parameters and presence of output schema, the description fully informs the agent with purpose, usage, and cost.

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?

No parameters exist, so parameter semantics are not needed; baseline 4 applies as schema coverage is 100%.

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

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

The description clearly states it lists all Vee3 capability groups, distinguishing from sibling tools that list tools within a group.

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 advice to use before listing tools in a specific group, though does not mention alternatives like list_group_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?

No annotations provided. Description adds transparency by stating it returns same shape as list_all, filtered, and is free. Does not mention auth requirements or side effects, but as a listing tool, risks are low.

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

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

Three sentences, front-loaded with purpose and usage, no filler. Every sentence adds value.

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

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

Given the presence of output schema and 100% schema coverage, the description is complete enough. It covers purpose, parameter source, output shape, and cost. Could mention error handling but not necessary.

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% with a clear description. Description adds value by guiding to get group_id from list_groups and providing an example, beyond the schema's own 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?

Description clearly states it lists live tools for a single capability group, uses group_id, and distinguishes from siblings like list_all and list_groups.

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 states source of group_id from list_groups, notes return shape similarity to list_all, and mentions zero token cost. Does not explicitly exclude alternatives but provides 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?

With no annotations, the description carries full burden. It discloses the call is free, lists return fields, and implies read-only behavior. It does not mention rate limits or error handling beyond the 402 hint, but overall transparency is good.

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

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

The description is two sentences, front-loaded with purpose, then usage guidance and details. Every sentence earns its place with no waste.

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

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

Given no parameters and the presence of an output schema, the description covers purpose, usage timing, and return details. It is complete and sufficient for a simple balance check.

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 are no parameters, and the schema coverage is 100%. The description adds value by explaining what the call returns, which goes beyond the empty 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 retrieves the API token balance for the authenticated account, listing specific return fields (tokens used, remaining, etc.). It uses a specific verb-resource combination and is distinct from sibling tools, which are unrelated.

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 advises using the tool before expensive calls or upon receiving a 402 error, providing clear when-to-use guidance. It also notes the call is free. No when-not-to-use or alternatives are mentioned, but the context is sufficient.

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?

No annotations provided, so description carries full burden. It discloses token cost and lists returned fields, which is positive. However, it does not detail potential errors, 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?

Two sentences front-load the purpose and usage, then list return data and token cost. No unnecessary words.

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

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

Given the existence of an output schema, the description adequately covers the tool's purpose, input, and token usage. It is complete for a straightforward lookup 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%, and the description repeats the slug example from the schema without adding new semantics. It adds minimal value beyond the schema for the single parameter.

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

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

The description uses a specific verb 'Look up' and resource 'celebrity on Rotten Tomatoes', clearly distinguishing it from other rotten-tomatoes tools that handle movies, TV shows, or 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?

Provides an example slug and states the input format, but does not explicitly mention when to use this tool versus alternatives like rotten-tomatoes.search. Context is clear but lacks exclusions.

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?

No annotations provided, so description carries full burden. It discloses return fields (names, roles, character names, profile links) and API token cost (5 tokens per success), which are useful behavioral details.

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 front-loaded sentences: purpose, output details, cost. No waste, every sentence adds value.

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

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

Given the tool's simplicity (1 required param, output schema exists), the description covers how to call, expected output, and cost. Nothing missing for an agent to correctly invoke 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 coverage is 100% with a clear description of 'movie_slug'. The tool description repeats the example but adds no new meaning beyond the schema. Baseline of 3 is appropriate.

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

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

The description clearly states 'List cast and crew credits for a movie by slug', which is a specific verb-resource combination. It distinguishes from siblings like movie_details or celebrity_details.

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 example slug (shawshank-redemption) but does not explicitly state when to use this tool vs alternatives like tv_show_cast_and_crew or when not to use it.

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

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

The description lists the returned fields and mentions a token cost of 5 API tokens, suggesting rate limiting. However, it does not explicitly state that the tool is read-only or non-destructive, and no authentication requirements or error handling are noted. Given no annotations, the description reasonably covers behavior but lacks full transparency.

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 no redundant information. The description is front-loaded with the core purpose, followed by a concise list of return values and token cost. Every sentence adds value.

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

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

Given the presence of an output schema, the description adequately covers input, output (examples of what is returned), and token usage. It is complete for a straightforward lookup tool, with no obvious gaps given the tool's simplicity.

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

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

The input schema already describes the 'movie_slug' parameter with an example. The description repeats this example without adding new semantic meaning. Since schema coverage is 100%, a baseline of 3 is appropriate.

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

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

The description clearly states the verb 'Look up' and specifies the resource 'a movie on Rotten Tomatoes' with required slug input. It includes an example slug ('shawshank-redemption'), making it easy to understand. It distinguishes from sibling tools like 'search' and 'movie_reviews' by focusing on comprehensive details.

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 mentions the required parameter (slug) and gives an example, but it does not explicitly state when to use this tool over alternatives like 'movie_cast_and_crew' or 'movie_reviews'. While the list of returned fields implies broad information, no direct guidance on selection 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?

No annotations are provided, so the description carries full burden. It discloses token cost (5 API tokens per successful call) and pagination behavior, but does not mention authentication requirements, error handling, or data freshness. Still, it provides substantial transparency.

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, front-loaded with purpose, then covers returns, pagination, filter, and token cost efficiently. Every sentence is informative and necessary.

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

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

Given no annotations but an output schema, the description covers key aspects: input slug, return fields, pagination, filter, and cost. It lacks mention of prerequisites (e.g., valid slug) or error scenarios, but is generally complete for a listing tool.

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

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

Schema description coverage is 100%, but the description adds significant value: example slug 'shawshank-redemption', clarifies cursor comes from pageInfo.endCursor, and explains review_type='critic' usage. This goes beyond schema descriptions.

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

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

The description clearly states it loads reviews for a movie by slug, specifying the returned data (quotes, sentiment, publication, critic details, pageInfo). The verb 'load' plus 'reviews' and the example slug make the purpose 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 explains pagination (cursor from pageInfo.endCursor) and optional filter (review_type='critic'), but does not explicitly differentiate when to use this tool over siblings like 'movie_details' or 'movie_cast_and_crew'. Usage is implied rather than stated with when/when-not/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?

With no annotations, the description carries full burden. It discloses API token consumption (10 per successful search) and specifies return fields. It does not mention rate limits, authentication, or error handling, but adequately covers key behavioral traits.

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 concise sentences, front-loaded with purpose, no unnecessary words. Efficiently communicates 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?

Given the presence of an output schema and sibling tools for further details, the description sufficiently covers what the tool returns. It lacks discussion of pagination or no-result behavior, but overall is adequate.

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 describes both parameters well. The description adds minimal value beyond stating 'by title or name' for query and mentioning token cost. 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 searches Rotten Tomatoes by title or name, and lists specific return fields (slugs, scores, poster URLs, etc.). It effectively distinguishes from sibling tools that provide details on known items.

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 the tool is for initial discovery (returning slugs for use in other tools), but does not explicitly state when to use it versus alternatives. No exclusions or when-not-to-use guidance is given.

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?

No annotations provided; description adds token cost and lists return fields (names, roles, character names). Lacks details on pagination, error handling, or data freshness, but provides basic behavioral context.

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 plus a token cost note, front-loaded with the main action. No wasted words.

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

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

Has output schema so return values are covered; description lists key fields. Mentions token usage. Lacks error handling details for invalid slugs, but otherwise sufficient for a simple retrieval 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?

The sole parameter 'tv_show_slug' is described in the schema with an example. The tool description reinforces the example but adds minimal extra semantic value beyond the schema.

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

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

The description explicitly states it lists cast and crew for a TV series using a slug, with specific examples. It clearly distinguishes from sibling tools like rotten-tomatoes.movie_cast_and_crew by specifying 'TV series'.

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 TV series cast/crew but does not explicitly state when to use this tool over alternatives like rotten-tomatoes.movie_cast_and_crew. No when-not or alternative mentions.

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?

No annotations provided, so description must cover behavioral traits. It discloses API token cost ('5 API tokens') but does not mention idempotency, mutability, or side effects. Adequate but not comprehensive.

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 concise sentences: first states purpose and parameter, second lists returns and cost. No wasted words.

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

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

With one parameter, output schema present, and clear return fields, the description is complete for this simple lookup tool. Covers all necessary 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 coverage is 100%; description adds an example ('breaking-bad') and clarifies 'by slug'. Adds marginal value beyond schema but not substantial.

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

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

Description clearly states 'look up a TV series on Rotten Tomatoes by slug', specifying a distinct verb and resource. It lists detailed return fields, differentiating from sibling tools like movie_details or 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?

Provides clear context for when to use (by slug) but does not explicitly mention when not to use or alternatives. Implicitly distinct from 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?

No annotations provided, so the description carries full burden. It discloses returned fields and token cost (5 API tokens). No mention of rate limits or idempotency, but adequate.

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 concise sentences: purpose, return fields, cost. No unnecessary words. Well-structured and 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?

Given the presence of an output schema (not shown but indicated), the description adequately covers inputs, key return fields, and cost. Missing mention of error handling, but enough for a simple retrieval 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% and descriptions are already detailed. The description reiterates the parameters without adding new semantic meaning 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 clearly states 'Load a single episode' using a specific verb and resource. It distinguishes from sibling tools that load season details or cast/crew.

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 (needs slug, season, episode) but does not explicitly state when not to use or suggest alternatives. Still, the context is clear enough.

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

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

No annotations are provided, so the description carries full burden. It discloses the API token cost (5 tokens per successful call) and notes that Tomatometer scores are returned 'when available'. However, it does not mention rate limits, authentication, or any side effects.

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

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

Three sentences, each adding value: purpose, return fields, and token cost. No unnecessary words or repetition.

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 existence of an output schema, the description does not need to detail return values. It covers purpose, parameters, cost, and return content adequately. Could mention read-only nature or error conditions, but overall complete for the 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?

Schema description coverage is 100%, so baseline is 3. The description does not add additional meaning beyond what is in the input schema for the two parameters.

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

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

The description clearly states it loads season-level details for a TV series by slug and season number, and lists what it returns. It is specific about the resource and action, but does not explicitly differentiate from sibling tools like tv_show_details or tv_show_episode.

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 a usage example (by slug and season number) but does not indicate when to use this tool versus alternatives (e.g., tv_show_details for show-level info). No exclusions or prerequisites are mentioned.

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?

No annotations are provided, so the description must disclose behavior. It states 'Load reviews' (read operation) and the token cost (5 API tokens per success). It describes output fields and pagination. Although it omits error behavior, the read-only nature and cost information are sufficient for an agent to use the tool safely.

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

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

The description is three sentences: first states core purpose, second lists output and pagination, third notes token cost. It is front-loaded with the action and resource, and every sentence adds essential information 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 complexity (5 parameters, pagination support, optional filter) and the presence of an output schema, the description covers the main use case, pagination mechanics, and parameter options. It does not cover error scenarios (e.g., invalid slug), but the core functionality is well-documented.

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?

All 5 parameters have descriptions in the input schema (100% coverage). The description adds value by explaining pagination with cursor and the effect of the 'type' parameter for filtering critic reviews. It also notes the default limit, which is not fully explicit in the schema (schema says default 20, description reinforces). This goes beyond what the schema alone 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 clearly states the tool loads reviews for a TV season using series slug and season number. It enumerates the output fields (review quotes, sentiment, publication, critic details, pagination info), making the purpose unambiguous. This distinctively separates it from sibling tools like 'movie_reviews' and 'tv_show_details'.

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 explains when to use (for TV season reviews) and provides pagination instructions using cursor. It mentions the optional 'type' parameter for critic-only reviews and the token cost per successful call. While it does not explicitly list alternatives, the context of sibling tools makes the usage 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?

Discloses token cost (10 API tokens) and outlines return content (overview and backlink list). However, no mention of authentication requirements, rate limits, error handling, or response pagination—despite no annotations provided to cover these.

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?

Concise, front-loaded with the primary purpose, followed by return structure and token cost. No extraneous content; every sentence 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?

Given the tool has an output schema (not shown), the description adequately summarizes typical return fields. However, it lacks context on error conditions, authorization, or performance characteristics, which would be helpful for an API-based 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?

The input schema already describes both parameters (url and include_subdomains) with clear descriptions. The tool description adds no additional semantic detail beyond what is in the schema, 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?

Clearly states the tool finds backlinks for a given URL, distinguishing it from siblings like SEO metrics tools. The verb 'find' and resource 'backlinks' are specific.

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?

Does not provide explicit guidance on when to use this tool versus other SEO tools (e.g., seo.url_metrics), nor does it mention prerequisites or exclusions. The context is implied but not directive.

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?

No annotations are provided, so the description carries full burden. It discloses token cost ('10 API tokens') but does not explicitly state side effects or authorization needs, though the tool is clearly a read operation.

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

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

Three sentences, front-loaded with key information, and no wasted words. Efficient and to the point.

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 param, output schema present), the description covers purpose, outputs, and cost. No 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?

The single parameter 'url' is fully described in the schema (100% coverage). The description adds minimal extra meaning beyond what the schema provides, so a 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 gets Ahrefs domain authority signals for a URL, listing specific outputs (domainRating and ahRank). It distinguishes among siblings like seo.backlinks or seo.keyword_metrics.

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 context: 'useful for comparing site strength and prioritizing outreach or competitive research.' It implies when to use but does not explicitly mention when not to use or name alternatives, though siblings are distinct.

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?

No annotations provided; the description adds value by stating the output format (array of 2-letter codes) and that the call is free, which helps the agent know it's low cost.

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, front-loaded with purpose, then output format and cost. No wasted words.

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

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

Given the tool has no parameters and an output schema exists, the description fully covers the tool's behavior: listing country codes and noting it's free. No missing information.

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 tool has no parameters, and schema coverage is 100%. Baseline is 4 as per guidelines, and the description provides no additional parameter info (none needed).

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

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

The description clearly states it lists country codes for use with seo.keyword_metrics, specifying 2-letter ISO codes. It distinguishes itself from other tools by its specific purpose.

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 tells when to use (for getting valid country codes for seo.keyword_metrics) and notes the call is free. No alternatives or exclusions, but not needed for this simple tool.

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

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

With no annotations, the description carries full burden. It discloses token cost but lacks details on authentication, rate limits, or side effects. The read-only nature is implied but not explicit.

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 concise sentences: purpose, return fields, token cost. No redundancy, front-loaded with 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?

Given low complexity and presence of output schema, the description covers purpose, return fields, and cost. Could benefit from mentioning sibling tools for context, but overall sufficient.

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

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

Schema coverage is 100%, so baseline is 3. The description does not add meaningful parameter information beyond what the schema provides, such as the default country or max lengths.

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 gets SEO metrics for a keyword in a specific country, listing specific return fields. It distinguishes itself from siblings like seo.backlinks and seo.url_metrics by focusing on keyword-level metrics.

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 use for keyword analysis in a country context and mentions token cost, but does not explicitly state when to use this tool versus siblings or provide exclusions.

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 discloses that it is a read operation ('Get') and lists the returned metrics for page and domain sections, as well as the token cost. However, it does not clarify potential failure modes, data freshness, rate limits, or any side effects. Given no annotations, this is adequate but not comprehensive.

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 at about 80 words, front-loaded with the purpose, and uses a clear structure with bullet points for return sections. It efficiently conveys needed information without unnecessary verbosity.

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 tool with one parameter and no annotations, the description covers the purpose, return structure, and token cost. It reasonably addresses what an agent needs to know to use it, though it could improve by noting any constraints on URL validity or data update frequency.

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 single parameter 'url' is already described in the input schema as 'Public page URL to analyze.' The description does not add additional semantics such as format requirements, allowed protocols, or expected behavior for invalid URLs. With 100% schema coverage, the baseline is 3.

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

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

The description clearly states it retrieves detailed Ahrefs SEO metrics for a specific URL, specifying the data source and target. However, it does not explicitly distinguish from sibling tools like seo.basic_metrics or seo.backlinks, leaving ambiguity about when to use this tool over others.

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. The description does not mention prerequisites, suitable contexts, or exclude scenarios. The only usage-related note is the token cost (10 API tokens), but this is insufficient for decision-making.

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 is straightforward but does not reveal behaviors beyond what is stated. It mentions cost (2 tokens) and pagination, but lacks details like whether the operation is read-only, or what the response structure looks like. No annotations are present to supplement.

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

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

Three sentences that are front-loaded and efficient: purpose, requirements, pagination, cost. Every sentence adds unique value with no 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 output schema exists, the description's focus on input and pagination is sufficient. It covers the essential aspects of a paginated reply listing tool. Minor omission: not specifying that the cursor should be taken from a specific field (e.g., 'next_cursor').

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 all parameters well. The description adds practical context for the cursor parameter (pass from a previous response) but does not significantly extend 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 clearly states 'List replies to a TikTok comment', which is a specific verb and resource. It distinguishes this tool from siblings like tiktok.video_comments which lists comments on a video.

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 mentions required parameters (video_id, comment_id) and explains pagination using a cursor. However, it does not provide explicit guidance on when to use this versus alternatives, such as after retrieving comments via tiktok.video_comments.

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?

With no annotations, the description carries the full burden. It discloses token cost (10 tokens), return type (signed download URL), and behavior (preferring return_mode 'url'). This is sufficient for a read-like download tool.

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, no fluff. The first sentence states purpose and key constraint, the second adds token cost and preference. Highly 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 that an output schema exists (known from context), the description does not need to explain return values. It covers purpose, constraints, token cost, and guidance on return_mode. It is complete for a simple three-parameter 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% with descriptions for each parameter. The description adds value by explicitly stating mutual exclusivity of music_id and music_url, and advising to prefer return_mode 'url', which is not in the schema.

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

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

The description clearly states the verb 'Download' and resource 'TikTok music track'. It distinguishes from sibling tools like tiktok.download_music_from_video and tiktok.download_video by specifying the exact resource type.

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

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

The description gives clear usage guidance: provide either music_id or music_url, not both, and prefer return_mode 'url'. It does not explicitly state when not to use or list alternatives, but the context of sibling tools helps.

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?

With no annotations, the description carries full burden. It discloses the return type ('signed download URL') and token cost, but omits details on error handling, idempotency, or authorization requirements.

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

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

Three concise sentences: purpose, constraint, and return/cost. Every sentence earns its place, front-loaded with key action.

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