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

Annotations are absent, so the description carries the full burden. It discloses the basic read behavior but does not mention rate limits, authentication, response format, error handling, or what happens when no AI Overview exists. The generic operation structure is also not explained beyond the minimal contract.

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, front-loaded with the main purpose, and includes only the essential operation details. No filler or redundant content.

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

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

For a simple single-operation tool with no output schema, the description provides the minimum viable information. It lacks guidance on expected output, use cases versus siblings, and any limitations, leaving gaps for an AI agent deciding between this and similar search tools.

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

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

The schema descriptions for 'operation' and 'args' are generic and reference the tool description. The description adds value by specifying the exact operation value ('ai_overviews') and noting that 'q' is required, which clarifies the search query parameter. It could be improved by explicitly defining 'q' as the search query.

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 fetches Google's AI Overview answer block for a search query, which is a specific verb and resource. However, it does not explicitly differentiate from similar sibling tools like google_ai_mode or realtime_web_search, so it falls short of a 5.

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

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

No guidance is given on when to use this tool versus alternatives such as google_ai_mode, gemini, or realtime_web_search. The description only states what it does and how to call it, with no exclusions or preferred scenarios.

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

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

With no annotations provided, the description must disclose behavioral traits, but it only mentions getting a response. It does not describe any side effects, authentication requirements, rate limits, or response format, which is a significant gap for a tool that sends prompts to an external service.

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 front-loaded with the purpose. The operations section is necessary because the schema delegates to it, but the 'chat (required: message): Chat' line is somewhat redundant. Overall, it is appropriately sized without 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 (one operation, one parameter), the description is minimally adequate, but gaps remain. There is no output schema, and the description does not explain the response structure, error handling, or distinguish usage from other AI tools, making completeness only moderate.

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

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

The schema has 100% description coverage, but both descriptions are generic pointers to the tool description. The description adds that the 'chat' operation requires a 'message' parameter, but it fails to specify the type, format, or any constraints, so it adds only marginal 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 the tool's function: 'Relay a chat prompt to ChatGPT (OpenAI) and get the model's response.' This uses a specific verb ('relay') and resource ('ChatGPT'), and it distinguishes itself from sibling AI tools like copilot and gemini by name.

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

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

The description provides no guidance on when to use this tool instead of alternatives such as copilot or gemini. It only states what the tool does without any context for selection or exclusions, leaving the agent to infer usage from the purpose statement.

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, placing full burden on the description. It only states the relay function without disclosing any behavioral traits such as rate limits, error handling, authentication, or response format.

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

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

The description is concise and front-loaded with the main purpose. The operation list is somewhat redundant (repeating 'Copilot'), but the overall structure is 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 the simplicity of the tool and lack of output schema/annotations, the description is minimally sufficient. However, it lacks response format details and explicit guidance on when to select this tool over similar ones.

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

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

The schema already documents both parameters (operation and args). The description adds value by noting that the 'copilot' operation has no required params, clarifying what goes into 'args'.

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 'Relay a prompt to Microsoft Copilot and get the response' with a specific verb and resource. This distinguishes it from sibling AI tools like chatgpt and gemini.

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 context is clear: this tool is for Microsoft Copilot. However, it does not explicitly mention alternatives or when to use this vs other AI tools, though the Microsoft Copilot reference implies the appropriate scenario.

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 responsibility for behavioral disclosure. It only mentions the operation pattern and required parameters, but does not describe the response format, potential limitations, authentication needs, or any side effects. There is no contradiction, but the disclosure is minimal.

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 front-loaded with a clear purpose statement, followed by a structured operation list. The only minor redundancy is the 'Get Directions' label duplicating the operation name, but overall it's efficient and well-organized.

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 output schema and no annotations, the description should explain the return value and any important context. It provides the invocation pattern and required params, but lacks details on response structure, route detail scope, and whether it supports real-time data, making it only partially complete for a navigation 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 schema already provides descriptions for 'operation' and 'args' (100% coverage), and the description adds the required parameters for the get_directions operation (origin, destination). However, it does not elaborate on parameter formats (e.g., address vs. coordinates), so it only partially adds 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 the tool provides turn-by-turn driving directions and route details between origin and destination, with a specific verb ('get_directions') and resource. It distinguishes itself from generic search tools, though it doesn't explicitly differentiate from the sibling tool 'waze'.

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?

There is no guidance on when to use this tool versus alternatives like waze. The description only explains the operation structure and required parameters, without any context on use cases, limitations, or 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 are provided, so the description carries the full burden. It discloses a behavioral limit ('up to 5,000 results') and explicitly details the operation/argument invocation pattern. However, it does not mention return format, error behavior, or rate limits, which would be useful for a search endpoint. Still, the core behavior is transparent enough for an agent to invoke correctly.

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 compact and well-structured: a one-sentence purpose, a formatted list of operation parameters, and a clear 'When to use' line. Every sentence earns its place with no redundant or vague 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?

The tool is simple (one operation, two params). The description covers purpose, parameters, and usage guidelines, and the result limit adds useful context. However, with no output schema or annotations, a brief note on the return structure (e.g., 'returns a list of email addresses') would make it fully complete. The implied output is sufficient for most selection purposes.

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 only defines 'operation' and a generic 'args' object with no schema for the actual operation parameters. The description compensates fully by naming the operation ('search_emails') and listing the required parameters ('query, email_domain'), while also instructing that parameters go in 'args'. This is essential semantic information beyond the schema.

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

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

The description states a specific verb ('Find'), a resource ('email addresses'), and a scope ('within a given email domain') with a result limit. It also distinguishes the tool from the sibling website_contacts_scraper, making the purpose clear and 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?

The 'When to use' section explicitly states the intended use case ('discover emails by query + domain') and provides an explicit alternative ('To scrape contacts from a known website use website_contacts_scraper'). This is model guidance for selecting between 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?

There are no annotations, so the description must carry the full burden of behavioral disclosure. It only states the tool finds stations with connector and availability details, but it does not mention any behavior such as rate limits, data source freshness, error handling when no stations are found, or any authentication requirements. This is a significant gap for a tool with no other annotations.

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

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

The description is reasonably concise and front-loaded with the main purpose, followed by operation details. The final lines 'Search by Location' and 'Search by Coordinates Point' are slightly redundant given the operation names, but the overall structure is clear and no words are wasted.

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?

The tool has two operations, nested args, no output schema, and no annotations. The description gives the essential operation/parameter mapping but omits details about the return format (other than 'connector and availability details'), pagination, filtering options, or error behavior. Given the tool's moderate complexity, this is adequate but leaves noticeable 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 schema covers only operation and args generically, but the actual parameters (near, lat, lng) are only documented in the description. The description lists them as required but does not explain the expected formats (e.g., whether 'near' is a city name, whether lat/lng need decimal degrees). Thus it adds some meaning beyond the schema but not enough to fully clarify the input semantics.

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 function: 'Find EV charging stations by location name or by coordinates, with connector and availability details.' It uses a specific verb (find) and resource (EV charging stations), and the two operations (search_by_location, search_by_coordinates_point) further clarify the scope. This clearly differentiates it from sibling tools like driving_directions or waze, which focus on routes/navigation.

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 by explicitly listing the two operations and their required parameters, telling the agent when to use search_by_location (provide a location name) vs search_by_coordinates_point (provide lat, lng). However, it does not discuss alternatives or exclusion criteria (e.g., when to prefer a sibling tool like local_business_data), so it slightly misses the full 'when to use vs alternatives' ideal.

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?

Without annotations, the description carries the full burden of behavioral disclosure. It states the core behavior (relay and get a response) and lists the operation with its required message parameter, but it does not mention rate limits, potential errors, or any other caveats. For a simple chat relay, this is adequate but lacks depth.

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 appropriately brief: two sentences and a one-item bullet list. It front-loads the main purpose and then explains operations and parameters without any filler or redundant 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 operation, one required parameter), the description is reasonably complete. It clearly identifies the operation and parameter, but it does not describe the response format or any edge cases. Since there is no output schema, a little more detail about the return value could have improved completeness, but the tool's straightforward nature makes this acceptable.

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

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

The schema's 'args' field is generic and defers to the description for parameter details. The description compensates by explicitly stating that 'chat' requires a 'message' parameter and that parameters go in 'args', providing the necessary semantic meaning beyond the schema's sparse structure.

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 function: relaying a chat prompt to Google Gemini and returning the model's response. The verb 'relay' and specific resource 'Google Gemini' make the purpose explicit and distinguish it from sibling chat tools like ChatGPT and Copilot.

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 when to use the tool (when you need to interact with Google Gemini) but does not explicitly compare it to alternatives or state when not to use it. There is no mention of exclusions or alternative tool recommendations, leaving the context to be inferred from the tool name and sibling set.

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 only states the fetch action and operation names, without disclosing behavioral traits like authentication needs, rate limits, output format, or side effects. The POST variant is mentioned but its unique behavior is not explained.

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, front-loaded with the primary purpose, and uses a clear structured list for operations. Every sentence earns its place with no filler.

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

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

The description provides enough to invoke the operations but lacks an output description, error handling, and rationale for having two near-identical operations. Since there is no output schema, some return-value or behavior information 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?

The schema descriptions are generic, but the tool description adds the required 'prompt' parameter for each operation. However, it does not elaborate on prompt content or format beyond being a query, and the args object is open-ended.

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 fetches Google's AI Mode conversational answer for a query, using a specific verb and resource. It distinguishes from sibling tools like gemini or ai_overviews by explicitly naming Google's AI Mode.

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

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

Usage is implied: use this tool when you need Google AI Mode answers. It lists the two operations and their required prompt parameter, but does not explicitly compare to alternatives or state when one operation should be preferred over the other.

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 carries the full burden of disclosing behavioral traits. It lists operations and required parameters but does not mention data sources, accuracy, update frequency, rate limits, or what happens for unknown titles/locations. The description is factual but lacks contextual behavior disclosure.

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

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

The description is reasonably concise and structured with an operations list. However, the per-operation descriptions ('Job Salary', 'Company Job Salary') are tautological and add no information, so there is minor redundancy that could be trimmed for clarity.

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?

The tool has moderate complexity (two operations) and no output schema, so the description should explain return values and limitations. It covers operations and required parameters but omits any detail about the response format, units, currency, or fallback behavior. Given the lack of an output schema, this is a clear gap in 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?

The input schema's 'args' is a generic object, so the description is the only source for parameter meaning. It explicitly lists required parameters for each operation (job_salary: job_title, location; company_job_salary: company, job_title), which goes beyond the schema. However, it does not specify argument types or value formats, preventing a higher 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 that the tool provides estimated salary ranges for job titles/locations and company-specific salaries. It distinguishes itself from sibling tools by focusing on salary data, but lacks a direct verb like 'get' or 'retrieve' in the initial sentence, making it slightly less explicit than a top-tier purpose statement.

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 how to invoke operations (set 'operation' and pass args) but provides no guidance on when to use this tool versus alternatives. Sibling tools like jsearch or realtime_glassdoor_data could also provide salary information, and there is no mention of scenarios where this tool is preferred or dispreferred, so the agent receives no decision-making support.

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 the operations and required parameters but does not mention response format, pagination, rate limits, or limitations. The statement 'aggregated from Google for Jobs' adds some context, but depth is lacking.

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: a summary sentence, a formatted list of operations with required params, and a clear usage note. It is concise without wasted words, though the operation list could be slightly more compact.

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 multi-operation nature and lack of output schema, the description covers all operations, required parameters, and usage distinctions from siblings. It falls short only on optional parameters and response details, but is complete enough for invoking 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 descriptions are generic placeholders, but the tool description adds meaning by mapping each operation to its required parameters (e.g., 'search_v2 (required: query)') and explaining that parameters go in 'args'. However, optional parameters are omitted.

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 is a job search tool aggregated from Google for Jobs, listing specific operations (search, job details, salary). It distinguishes from siblings by naming alternative tools for salary and reviews.

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 'When to use' section specifies using the tool for job postings, and directs to job_salary_data for salary-only and realtime_glassdoor_data for reviews, providing clear alternatives.

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

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

No annotations are present, so the description carries the burden. It conveys a read-oriented data tool and adds context like 'Includes contact info where available', but it does not mention rate limits, authentication, pagination, error behavior, or response format. This is adequate but not rich.

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

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

Although long, the description is well-structured and front-loaded with a summary. Each operation is listed with its required parameters; there is no filler. The minor typo 'Buisness' does not detract from clarity.

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 high complexity (15 operations) and no output schema, the description adequately covers operation selection and parameter requirements. It falls short on describing return values or response structure, which would be helpful for such a data-heavy 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 schema only defines 'operation' and a generic 'args' object. The description enumerates every operation with its required parameters (e.g., search_in_area requires query, lat, lng, zoom), adding crucial semantics that the schema does not provide.

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 identifies Google Maps business and place data as the resource, uses specific verbs (search, reviews, photos, reverse geocoding), and distinguishes itself from sibling tools like yelp_business_data and trustpilot_company_and_reviews.

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?

An explicit 'When to use' section states this is the primary tool for local business/place data from Google Maps and directs to yelp_business_data and trustpilot_company_and_reviews for alternatives, providing clear decision guidance.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. While the operations ('places', 'search', etc.) imply read-only behavior, the description does not explicitly state side effects, auth requirements, rate limits, or return format. This is a significant gap for a tool that may access external search engines.

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

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

The description is efficiently structured: a one-sentence purpose followed by a structured list of operations. Each operation entry is concise and includes required parameters. The list format improves scannability, though it could be slightly more compact by grouping shared parameter patterns.

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?

The tool has multiple operations with multiple parameters and no output schema. The description lists operations and required params but does not explain return values, pagination behavior, or coordinate format. For a complex tool, this leaves gaps, though the operation list provides a solid foundation.

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

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

The schema only defines 'operation' and 'args' with open-ended properties, but the description names the required parameters for each operation (e.g., 'query', 'lat', 'lng', 'grid_size', 'radius'). This adds essential meaning beyond the schema, making the tool usable without additional documentation.

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

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

The description clearly states the tool's function with a specific verb+resource: 'Track a business's local search ranking across a geographic grid of coordinates (local SEO rank grid).' It also enumerates the operations, which distinguishes it from sibling tools like local_business_data and yelp_business_data that focus on business data rather than ranking tracking.

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 instructions on how to use the tool by listing operations and their required parameters, but it does not explicitly state when to use this tool versus alternatives. There is no mention of exclusions or alternative sibling tools, leaving the decision to the agent.

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

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

No annotations are provided, so the description must disclose behavioral traits such as read-only nature, rate limits, or data source specifics. It only lists operations and required params, with no mention of return formats, pagination, or side effects, leaving the agent with minimal 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?

The description is organized as a summary line followed by a bulleted list of operations with required params, which is scannable and front-loaded. It could be slightly more concise by not repeating the operation name in the trailing label (e.g., 'Search'), but overall it earns its length.

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 multi-operation nature of this tool and no output schema, the description is complete enough to list all available operations and their required inputs, but it lacks information about return values, optional parameters, and any constraints. This is a minimum viable description for invocation, though not fully comprehensive.

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 only defines operation and a generic 'args' object, while the description maps each operation to its required parameter (e.g., q for search, app_id for reviews). This adds essential semantic information beyond the schema, though it omits descriptions of what those parameters mean and any optional 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 opens with 'Google Play Store data' and enumerates ten specific operations (search, app_reviews, app_details, categories, top charts). This clearly states the tool's resource and scope, distinguishing it from the many sibling tools that focus on other domains.

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 operation-by-operation required parameters, which tells the agent how to invoke each endpoint. However, it does not explicitly state when to choose this tool over alternatives or when not to use it, leaving usage context only implied by the 'Play Store' domain.

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 lists operations and parameters but does not disclose behavior such as whether calls are read-only, rate limits, authentication needs, result formats, or edge cases. For a data-access tool, this lack of behavioral context is a notable gap.

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

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

The description is long but well-structured: a brief overview followed by a compact list of operations with required params, then a clear 'When to use' section. Every sentence serves a purpose, and the format is easy to scan.

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

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

With 21 operations and no output schema, the description provides a comprehensive map of operations and their parameters, which is sufficient for selecting and invoking the tool. It does not describe return shapes, but that is less critical for a data retrieval tool and can be inferred from operation names.

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

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

The schema only defines 'operation' and 'args' generically. The description compensates fully by listing each operation with its required parameters in parentheses, enabling the agent to construct valid 'args' for any operation. This adds essential 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 identifies the tool as Amazon product data with a specific list of operations. It distinguishes itself from siblings by stating 'Use for Amazon specifically' and naming alternative tools for other retailers.

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

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

Provides explicit usage guidance: 'Use for Amazon specifically' and directs to alternatives like realtime_product_search for Google Shopping and dedicated tools for Walmart/Costco/Wayfair/eBay. This clearly answers when to use vs 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Search Books' and mentions metadata, but does not explain what is returned, whether results are live or cached, any rate limits, or output format. This is minimal and leaves important behavior undisclosed for a data-fetching 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?

The description is very short and to the point, using a bullet for the operation. It is concise and front-loaded with the main purpose. However, it could be slightly more structured by explaining the operation parameters clearly; the current style is efficient but not overly elaborate.

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 output schema and no annotations, the description is insufficient. It does not describe the return value, result format, pagination, or any additional behavior. For a tool that searches real-time book data, an agent would need context on what 'metadata' includes or how results are delivered. The completeness is lacking.

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 a generic 'args' object with 'additionalProperties: true' and defers parameter details to the description. The description clearly specifies that 'search' requires 'query', which is essential for an agent to invoke the tool correctly. This adds meaning beyond the schema, which does not enumerate per-operation 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 'Book search with metadata across major book sources', which identifies the tool's domain and purpose. The operation 'search' is explicit. While it doesn't explicitly distinguish itself from sibling real-time tools, the noun 'books' makes the scope unambiguous.

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

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

The description implies usage (when you need book data) but does not provide explicit guidance on when to use this tool versus alternatives or any exclusions. There is no mention of supporting use cases or non-goals, so usage context is only implicit.

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 must carry the behavioral disclosure burden. It only lists operations and required params, and does not mention return formats, pagination, rate limits, or any other behavioral traits. This is a minimal disclosure that leaves the agent without crucial information.

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, using a bulleted operation list that is easy to parse and front-loads the core purpose. Each line has a clear function. The tiny tautologies in the operation descriptions ('Search', 'Product Details') keep it from being a perfect 5, but there is zero filler.

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

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

Given no output schema and no annotations, the description should clarify what results the tool returns and any constraints or error behavior. It only covers operation selection and required args, omitting result structure, search result limits, and data fields. This is a significant gap for a two-operation 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 schema only defines 'operation' and a generic 'args' object, with no property-level definitions for query or product_id. The description compensates by specifying 'search (required: query)' and 'product_details (required: product_id)', adding meaning beyond the schema. However, it does not elaborate on value types or formats, so it is not perfect.

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 immediately states 'Costco product search and product details', clearly identifying the resource (Costco products) and the specific actions (search, product details). It also enumerates the two operations, making it easy to distinguish from sibling tools focused on other retailers.

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 operation list provides clear guidance on when to use search vs product_details by listing required parameters for each. The 'Costco' scoping implies the intended use case, but the description does not explicitly mention alternatives or exclusions (e.g., use realtime_walmart_data for Walmart), so it falls short of a full 5.

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

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

No annotations are provided, so the description carries the full behavioral disclosure burden. However, it does not disclose any non-obvious behavior such as data freshness, rate limits, authentication, or output structure. The operation labels like 'Product Search' simply restate the operation names without adding meaningful context beyond what is already evident.

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, opening with a clear summary and then presenting each operation in a consistent, scannable format. Every sentence contributes meaning, and the list of operations with parameters is easy to parse with no redundant text.

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

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

This is a multi-operation tool with no output schema and no annotations, leaving the description to provide complete context. It successfully covers operations and required parameters, but omits any information about return data, error behavior, or operational constraints. For complex usage, an agent would need more details about what to expect from each operation.

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

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

The schema only defines a generic 'args' object, so the description adds significant value by specifying the required parameter for each operation (query, category_id, product_id, seller_id). While it does not provide types or formats, the parameter names are self-explanatory and directly tied to their operations, compensating for the schema's lack of detail.

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 'eBay product search, products by category, product details and seller feedback across eBay domains,' using specific verbs and resources. It enumerates four distinct operations, clearly distinguishing it from sibling tools like realtime_amazon_data and real_time_walmart_data by focusing on eBay.

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 how to invoke the tool ('set operation... put its parameters in args') and lists required parameters for each operation, but it does not explicitly compare this tool to alternatives or state when not to use it. Usage is implied by the eBay-specific scope, but there is no direct guidance for choosing between this and sibling data 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 are provided, so the description carries the burden. It discloses only the operation names and required parameters, which are already partially reflected in the schema enum. No mention of data freshness, geographic scope (beyond 'local and online'), rate limits, authentication, error behavior, or return format. Minimal behavioral insight is added.

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: one sentence of scope plus a two-item operation list. No redundant text, clearly 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?

Two operations, dynamic args, no output schema, and no annotations. The description explains operation parameters but omits expected return data, pagination, sorting options, and any caveats. It's sufficient for a simple dispatcher but lacks depth for production agents.

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

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

The schema has generic args object with additionalProperties true, so the description's per-operation required parameters (query, event_id) are essential and add real semantic value. However, it doesn't list optional parameters or value formats, but for a dispatcher pattern this covers the minimum.

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 searches local and online events with full event details, listing example categories (concerts, conferences, festivals). This distinguishes it from sibling realtime search tools (news, products, etc.) and aligns with the tool name.

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

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

No explicit when-to-use vs alternatives. The description implies usage for event-related queries but doesn't mention when not to use other realtime data tools or provide alternative tool names. Sibling tools like realtime_news_data and realtime_product_search cover different domains, but the description doesn't draw those boundaries.

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 of behavioral disclosure. It offers only a list of operation names and claims 'no required params' for every operation, which is implausible for operations like stock_quote and fails to mention data sources, latency, rate limits, or error behavior. No side effects or return behaviors are described.

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 bullet list of 14 operations is well-structured and front-loaded with a summary. However, the display labels largely repeat the operation names (e.g., 'Stock Quote' for stock_quote) and the repeated 'no required params' phrase adds noise without 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?

This is a high-complexity, multi-endpoint tool with no output schema, so the description must explain what each operation returns and what arguments it requires. It neither documents return shapes nor per-operation arguments, leaving agents to guess for most operations. The claims of 'real-time' and 'crypto' are also not backed by the operation list.

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

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

The schema gives only generic descriptions for operation and args, so the description should compensate with per-operation parameter detail. It repeats the operation enum and tells the agent to put parameters in args, but it does not define actual argument keys for any operation and misleadingly labels all operations as having 'no required params'. Schema coverage is high but shallow, and the description adds a dispatch pattern without real parameter semantics.

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 first sentence clearly identifies the tool as providing real-time finance data and distinguishes it from sibling tools by domain and data categories. However, it promises 'crypto' but no crypto operation appears in the list, slightly overstating the actual scope.

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 dispatch mechanism ('set "operation" to one of these; put its parameters in "args"') and enumerates all operations, which tells an agent how to invoke the tool. It gives no guidance on when to prefer this tool over sibling real-time data tools or how to choose among the 14 operations for a specific user intent.

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, and the description only states that it performs a search. It does not disclose the return format, any side effects, rate limits, or authentication requirements, leaving a significant behavioral gap beyond the obvious read-only nature.

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 succinct and front-loaded with its purpose, followed by a clear operations list. Every sentence serves a purpose with 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?

Without annotations or an output schema, the description should explain what the tool returns and any limitations. It only provides minimal operational detail (operation and query), leaving the agent uncertain about response format and usage constraints.

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 only describes an operation enum and a generic args object. The description adds the required parameter name 'query' for the search operation, which is meaningful beyond the schema. However, it does not elaborate on the query's format or any optional 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 the tool searches discussion forums and community threads (Reddit and similar) for a query. This specific verb and resource distinguishes it from sibling search tools like realtime_news_search or realtime_video_search.

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

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

The description implies usage for forum searches but provides no explicit guidance on when to use this tool over alternatives, nor any exclusions. No alternative tools are mentioned, so the usage context is implied rather than stated.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention whether operations are read-only, any authentication needs, rate limits, or response formats. The tool name implies real-time data, but the description adds no behavioral context beyond the operation list.

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 as a concise bullet-like list of operations with their required params. It is front-loaded with a clear overview and avoids unnecessary prose. Every line contributes useful 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?

The description covers all 9 operations and their required parameters, which is sufficient for basic invocation. However, it lacks details about return values, optional parameters, pagination, or any operation-specific nuances. Given the tool has no output schema and 9 distinct operations, more context would be needed for a complete 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?

The input schema's 'args' is a generic object with no per-operation properties, making the description the authoritative source for parameter requirements. It explicitly lists each operation's required parameters (e.g., company_salaries requires company_id and job_title), providing essential semantics that the schema lacks.

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 identifies the resource (Glassdoor) and lists the specific data types (company search, overview, reviews, salaries, interviews, jobs) and operations. It distinguishes from siblings by being Glassdoor-specific, though it lacks an explicit verb like 'search' or 'retrieve' in the opening sentence.

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

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

The description provides no guidance on when to use this tool versus alternatives (e.g., jsearch, job_salary_data) or when not to use it. It simply lists operations without contextual recommendations.

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 fully disclose behavioral traits. It only claims to be 'fast and reliable' and 'real-time,' which are vague marketing terms, and does not mention response format, data freshness, rate limits, authentication requirements, or error behavior. The operation list is structural, not behavioral.

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 and well-structured with a clear operation list. The opening sentence contains some promotional fluff ('Fast and Reliable,' 'and More'), but the bullet-style operation breakdown is efficient and easy to parse.

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 multi-operation tool with no output schema and no annotations, the description covers the operation/parameter mapping adequately but omits important context such as example queries, result shape, pagination, or error conditions. It is enough to attempt a call but not enough to fully understand behavior or response structure.

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 only generic descriptions for 'operation' and 'args' (with additionalProperties true). The description compensates by enumerating each operation and its required parameters (query, category_id, search, item_id), giving agents the necessary mapping to construct valid requests. It does not explain parameter value formats, but the operation-to-parameter mapping adds significant 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 identifies the tool as providing Home Depot product searches, category listings, product details, reviews, and item lookup. The explicit operation list (search, products_by_category, product_details, item_lookup, product_reviews) gives specific verbs and resources, and the Home Depot branding distinguishes it from sibling retail data tools.

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

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

The description clearly implies the tool is for Home Depot product-related real-time data retrieval. It does not explicitly mention when not to use it or name alternatives, but the operation list and brand-specific context provide clear guidance for when this tool should be selected over similar 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 are provided, so the description carries the burden. It clearly implies a read-only search operation, but does not mention rate limits, authentication, pagination, or result structure beyond 'full image metadata'. The description could add more 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?

The description is concise and well-structured, with a clear first sentence, an operations list, and a focused usage note. Every sentence serves a purpose, and the format is easy to scan.

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

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

For a simple one-operation tool, the description is largely complete: it covers what the tool does, required parameters, and usage guidance. However, the absence of an output schema means the description could better explain the returned metadata structure and filter value constraints, leaving a minor gap.

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

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

The input schema only defines generic 'operation' and 'args' objects. The description compensates by specifying the 'search' operation requires 'query' and mentioning available filters (size, color, type, license). This adds meaningful parameter semantics 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 performs Google Images search with filters and full metadata. It also distinguishes itself from siblings by explicitly naming reverse_image_search and realtime_lens_data as alternatives for searching by image.

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 'When to use' section tells exactly when to use this tool ('find images by keyword') and when not to, naming alternative tools for by-image search. This is explicit and actionable.

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 clarifies each operation's behavior (e.g., OCR extracts text, exact matches) but does not disclose potential error conditions, response format, or any side effects. The read-only nature is 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?

The description is well-structured with a clear intro, a bulleted list of operations with required parameters, and a concise 'When to use' section. Every sentence serves a purpose, with 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?

For a tool with five sub-operations, the description covers operation semantics, required input structure, and usage context. It does not describe the output schema, but the absence of an output schema makes the one-line descriptions of returns (e.g., 'Image to Text (OCR)') reasonably sufficient. It is nearly complete for an AI agent to select and invoke correctly.

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

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

The schema provides 100% coverage of the top-level parameters (operation and args), but the args object is generic. The description compensates by stating that each operation requires 'url' inside args and giving one-line descriptions for each operation, adding meaning beyond the schema's enum values.

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 'Google Lens on an image URL' and enumerates specific sub-operations: visual matches, exact matches, object detection, and OCR. It distinguishes this tool from the sibling reverse_image_search by focusing on deep visual analysis rather than simple reverse lookup.

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 includes an explicit 'When to use' section: use for deep visual analysis of an image, and for simple reverse lookup use reverse_image_search. This directly names an alternative tool and clarifies the boundaries of 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?

With no annotations provided, the description carries the full burden of disclosing behavior. It lists the supported operations and required params, but does not describe the response format, pagination, error handling, or any side effects. The read-only nature is implied by 'Google News data' but not explicitly stated. This is adequate for operation selection but lacks depth for fully understanding tool behavior.

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

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

The description is efficiently structured: a one-sentence overview, a bullet list of seven operations with their required params, and a concise 'When to use' section. Every sentence serves a purpose, and the information is front-loaded with the core capability. It is appropriately sized for a multi-operation tool.

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

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

The tool has 7 operations, no output schema, and no annotations, so the description must compensate. It thoroughly covers operation selection and parameter requirements, but it does not describe the return value structure or expected output for any operation (e.g., what 'full_story_coverage' returns). Given that the output schema is absent, this is a notable gap that prevents an agent from knowing how to interpret results.

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 only defines 'operation' and a generic 'args' object, so the description is the primary source for per-operation parameters. It lists the required parameter names for every operation (query, topic, story, country), which adds meaning beyond the schema. However, it omits types, optional parameters, and format details, so it does not fully compensate for the schema's generic 'args' placeholder.

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

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

The description opens with 'Google News data: search news, top and topic headlines, by-section and local headlines, and full-story coverage,' which clearly specifies the verb+resource. It names the sibling alternative tools (real_time_news_search, realtime_web_search) and differentiates this tool as the structured Google News accessor. The operation list further clarifies distinct endpoints.

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?

An explicit 'When to use' section states: 'Use for structured Google News (headlines, topics, coverage). For a flat news search across outlets use real_time_news_search; for general web results use realtime_web_search.' This provides direct guidance on when to use this tool versus alternatives. Each operation also lists its required parameters, giving clear invocation conditions.

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

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

There are no annotations, so the description carries the full burden. It mentions 'Flat' and 'simple,' hinting at a lightweight, non-hierarchical response, but does not disclose return fields, pagination, rate limits, or how results are ordered. The 'search' operation is tautological ('Search') and adds no behavioral 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 mostly compact and front-loaded with the purpose. The 'Search' after the bullet is redundant, but overall the structure is clear, with an operations section and a usage tip, without excessive 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?

The tool is simple with one operation, and the description covers the core purpose and when to use it. However, with no output schema and no annotations, the description does not explain what fields are returned, how many results, or any query formatting details. It is minimally viable but has 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?

While the input schema has 100% coverage for its top-level properties (operation and args), it leaves args as an open object and defers to the tool description. The description adds the required 'query' parameter for the search operation, which is essential and not present in the schema. This meaningfully compensates for the schema's generic args definition.

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 performs a 'Flat news article search across many outlets for a keyword query.' It specifies the action (search), resource (news articles), and scope (across many outlets). It also distinguishes itself from the sibling tool realtime_news_data by noting the flat structure versus Google News topics/headlines.

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 guidance is given: 'Use for a simple article keyword search. For Google News structure (topics, headlines) use realtime_news_data.' This directly tells the agent when to use this tool and when to choose the alternative sibling 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 the full burden of behavioral disclosure, but it only lists operations and parameters. It does not mention whether operations are read-only, rate limits, authentication, pagination, or response formats, limiting the agent's understanding of side effects and constraints.

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 operation list, but it includes filler like 'Complete reference documentation' and 'Includes code examples, data samples, and usage guides' that are not actionable for an AI agent. The core operational content is concise but could be more direct.

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?

This dispatcher-style tool has seven operations and no output schema, yet the description provides only operation names and required params. It lacks return-value descriptions, error behavior, or usage context, making it incomplete for an agent to fully understand the tool's behavior and results.

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 only defines generic 'operation' and 'args', but the description adds essential operation-specific required parameters (e.g., q for search, product_id for details). This compensates for the schema's lack of per-operation parameter definitions, though it omits optional parameters and value formats.

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 is a real-time product search API for Google Shopping, covering products, offers, and reviews across major retailers. The specific verb-resource pairing and explicit operation list distinguish it from sibling tools focused on other data sources (e.g., Amazon, Walmart).

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 each operation with its required parameters, which guides invocation. However, it does not explicitly state when to choose this tool over alternatives like realtime_amazon_data or real_time_walmart_data, leaving selection based on inferred scope (Google Shopping) rather than explicit guidance.

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

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

No annotations are provided, so the description carries the full burden for behavioral disclosure. However, it only lists operations and parameters; it doesn't mention read-only status, auth requirements, rate limits, output format, or side effects. This leaves significant behavioral ambiguity.

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 compact and front-loaded with a summary, followed by a structured list of operations. Minor redundancy exists (e.g., 'Search by Coordinates' repeated as both label and description), but overall it's 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?

This multi-operation tool has no output schema and no annotations. The description lists required params but fails to explain what each operation returns, optional parameters, or the meaning of 'property_details' (which claims no required params but presumably needs a listing identifier). This leaves users underinformed for several operations.

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

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

The schema covers both operation and args generically, but the description adds operation-specific required parameters (e.g., ne_lat, ne_lng, sw_lat, sw_lng for search_coordinates), which is essential for correct invocation. This goes beyond the schema's generic 'key/value pairs' guidance.

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

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

The description clearly states it provides 'Redfin real estate data' with specific operations for searching by location, coordinates, or polygon, plus property details and market trends. This distinguishes it from sibling tools like realtime_zillow_data or real_time_walmart_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 explicitly lists each operation and its required parameters, giving clear context on how to invoke the tool. It doesn't explicitly compare to alternatives, but the 'Redfin' branding signals when to use this tool over other real-time data 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?

With no annotations, the description carries the full burden of behavioral disclosure. It only states the action and operation, omitting return format, error handling, rate limits, or authentication needs. The agent gets no insight into what happens after invocation.

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 front-loaded with the main purpose, followed by a clear structured list of operations and parameters. Every sentence earns its place, with no redundancy or filler.

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

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

For a tool with a single operation and no output schema, the description covers how to invoke it but omits expected results, usage context, and differences from similar tools. It is minimally adequate but leaves gaps in 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?

The description explicitly names the required parameter 'query' for the search operation, which the generic 'args' schema does not specify. This adds meaningful semantics for constructing a correct call, beyond the schema's placeholder description.

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

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

The description clearly states the tool searches short-form videos, using the specific verb 'Search' and resource 'YouTube Shorts and similar'. This distinguishes it from likely siblings like realtime_video_search by scoping to shorts, making 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?

No guidance is provided on when to use this tool versus alternatives such as realtime_video_search or realtime_web_search. The description does not mention exclusions or preferred contexts, leaving the agent to infer usage.

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

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

With no annotations provided, the description carries the full burden for behavioral disclosure. It only restates the search purpose and gives a usage hint, but does not mention what the operation returns (e.g., video metadata, URLs, result counts), possible rate limits, or any read-only implication. The agent is left without insight into the response structure or 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?

The description is short and front-loaded with the primary purpose. The operations list is a bit redundant ('search' and 'Search'), but the when-to-use note is valuable and space-efficient. No wasted words, though it could be more informative without bloat.

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

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

The tool has no output schema and only a generic args schema, so the description must compensate by explaining both invocation and expected results. It adequately explains how to invoke the 'search' operation and when to use it, but it does not describe the return payload (titles, URLs, etc.), which is critical for an agent to assess whether the tool answers the user's query. Overall adequate but with a clear gap.

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

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

The schema itself has a generic 'args' object with additionalProperties, so the tool description is the only source that names the required parameter 'query' for the search operation. It adds minimal meaning ('required: query') but does not elaborate on what the query should contain, formatting, or supported values. Baseline 3 applies because the description does provide some crucial parameter information beyond the schema, but lacks depth.

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

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

The description clearly states a specific action: 'Search videos across YouTube, Vimeo, TikTok and the web for a query.' It identifies the resource (videos), the platforms, and the query input, and implicitly differentiates from sibling video tools like realtime_shorts_search by mentioning the short-form alternative.

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

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

Explicit usage guidance is provided: 'When to use: Use for full-length videos. For short-form clips use realtime_shorts_search.' This tells the agent when to select this tool and names the direct alternative, which is exactly what the dimension asks for.

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 for behavioral disclosure. It lists operations and required parameters but does not mention safety (read-only nature), rate limits, response format, or error behavior. The operations appear read-only, but this is 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?

The description is well-structured with a clear summary and a list of operations with required parameters. It is front-loaded and free of unnecessary words, though the bullet-like format could be slightly more compact.

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?

The tool has five operations, no annotations, and no output schema. The description explains how to invoke each operation with required args, which is adequate for basic use. However, it lacks return value descriptions, pagination details, or examples, leaving gaps for a richer multi-operation data 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 only defines a generic 'args' object; the description adds the actual parameter names (query, category_id, product_id) for each operation. This is essential and goes beyond the schema. However, it does not provide types or optional parameters, so it is not fully exhaustive.

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 scope: 'Walmart product search, products by category, product details, offers and reviews.' Each operation has a specific verb and resource, and the Walmart-specific focus distinguishes it from sibling real-time data tools.

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

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

The description implies usage for accessing Walmart product data through its listed operations, but it does not explicitly compare with alternative tools or state when not to use this tool. No exclusions or alternative recommendations are 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?

With no annotations, the description must disclose behavioral traits, but it only lists operations and required parameters. It does not mention that the tool is read-only, how fresh the data is, pagination, rate limits, or any response format. This leaves the agent uncertain about side effects and return structures.

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: a one-sentence purpose upfront, followed by a clear list of operations with required params. Every sentence serves a purpose, and the format makes it easy to parse.

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?

The tool has three operations and no output schema, so the description should explain what each operation returns. It only names the operations ('Search', 'Product Details', 'Product Reviews') without detailing the response data, pagination, or error behavior. It is sufficient for basic invocation but incomplete for full 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?

The schema descriptions defer to the tool description for required params, and the description does specify the required parameters for product_details and product_reviews (sku). However, it omits any optional parameters for search and gives no detail on the sku format, leaving the agent to guess. This adds some value but does not fully compensate for the schema's lack of specific param 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 the tool's scope: 'Wayfair product search, product details and reviews (furniture and home goods).' It identifies the specific resource (Wayfair) and the three operations, distinguishing it from sibling tools like real_time_ebay_data and real_time_walmart_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 provides clear context for when to use the tool: for any Wayfair product data. It does not explicitly list alternatives or exclusions, but the resource-specific name and operations imply its use case. It lacks direct 'when not to use' guidance, but the intended context is unambiguous.

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

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

With no annotations, the description carries the transparency burden. It does disclose output types and required parameters per operation, but it omits operational details like rate limits, pagination, or the differences between search, search_full, and search_light. The use of 'SERP' adds context, but deeper behavioral traits remain unspecified.

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: a one-sentence purpose, a bulleted operation list, and a short usage note. It is front-loaded with the most important information and contains no redundant or filler text.

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

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

The description covers the tool's overall purpose and available operations, but it does not explain when to choose specific operation variants (e.g., search vs search_full) or describe the return format/pagination for the variant responses. Given the absence of an output schema, this leaves notable gaps for an agent deciding which operation to invoke.

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's parameter descriptions are generic and explicitly defer to the tool description for required params. The description compensates by listing each operation with its required parameter names (q, queries, prompt) and clarifies that args is a key/value container. This adds substantial meaning beyond the schema, though it does not explain parameter nuances beyond their names.

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 performs real-time Google web searches (SERP) and enumerates specific result types (organic results, knowledge panels, AI Overviews). It distinguishes itself from siblings by explicitly naming alternatives for news and autocomplete, leaving no ambiguity about its core 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?

A dedicated 'When to use' section explicitly directs users to realtime_news_data for news and web_search_autocomplete for autocomplete, while positioning this tool for general web/Google searches. The list of operations further implies different use cases, giving clear contextual guidance.

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

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

No annotations are provided, so the description carries the full burden for behavioral disclosure. It does clearly define a dispatcher-style API with operation names and required params, but it does not disclose response shape, data freshness, pagination, or the ambiguity of property_details having no required params. This leaves some behavioral uncertainty.

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: an intro summary, a bulleted operation list, and a brief when-to-use line. Each operation line is terse and informative, though a little repetition (e.g., 'Search' after 'search') could be trimmed.

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

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

For a multi-operation tool with no output schema and no annotations, the description covers operation selection and required parameters well, but it omits return-value details and leaves property_details/no-required-params and the promised 'market trends' under-specified. It is adequate for basic invocation but not fully complete.

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

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

The schema only provides generic args and an operation enum, so the description carries the burden of documenting per-operation required params. It lists each operation's required args (e.g., long, lat, polygon, zpid), which is essential and effective. It does not, however, provide types or formats for these values, keeping it from a 5.

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

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

The description opens with 'Zillow real estate data' and enumerates concrete operations (search, property_details, zestimate, agent_search). It clearly identifies the tool's scope and explicitly differentiates from the sibling real_time_redfin_data by naming it in the 'When to use' section.

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 'When to use' section explicitly states 'Use for Zillow' and directs Redfin listing use to real_time_redfin_data. This is direct, actionable guidance that names an alternative tool, which is exactly what this dimension asks for.

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 merely restates that it finds visually matching images, without disclosing any behavioral traits such as read-only status, expected result format, 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 concise and front-loaded with the main purpose. The 'Operations' section is somewhat redundant with the input schema but provides necessary context for the args object. Slight repetition prevents a 5.

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 absence of an output schema and the presence of sibling tools with overlapping functionality, the description is incomplete. It does not describe what the result looks like, what kind of images are returned, or any limitations. A simple reverse image search tool needs more detail.

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

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

The schema covers the operation and args wrapper, but the actual 'url' parameter is only mentioned in the description as 'required: url'. This adds necessary but minimal meaning; the description does not explain what forms of URL are acceptable or how the URL is used.

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 that the tool performs reverse image search using an image URL, with a specific verb and resource. However, it does not distinguish itself from sibling tools like realtime_image_search or realtime_lens_data, so it misses the full bar for a 5.

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

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

The description provides no guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. It only outlines the internal operation structure, which is not usage guidance.

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

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

No annotations are provided, so the description carries the full behavioral burden. It states the core behavior (finding social links) and input types, but does not disclose output format, potential limitations, or any side effects. For a read-only search operation, it is minimally adequate but lacks richer 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?

The description is concise and front-loaded: it opens with the tool's purpose, then lists the operation in a clear, bulleted format. Every sentence adds value and there is no unnecessary fluff.

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

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

The tool is simple with a single operation, and the description sufficiently covers how to invoke it. However, since there is no output schema, the description could have mentioned the return format or error conditions. Overall, it is nearly complete for basic usage but leaves some ambiguity about response details.

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 describes 'operation' and a generic 'args' object, but the actual parameter 'query' is only documented in the tool description. The description adds essential meaning by specifying the operation name and required query parameter, compensating for the schema's generic nested object.

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 finds social media profile links and lists specific platforms (Instagram, LinkedIn, X, etc.) for a query, domain, or brand. This distinguishes it from sibling tools like email_search or website_contacts_scraper.

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 given on when to use this tool versus alternatives, nor are any exclusions or alternative tools mentioned. The description only explains what the tool does and how to invoke it, not when it is the preferred choice.

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 carries the full burden of behavioral disclosure. It discloses key traits: free tier only, never incurs charges, will not alter an existing paid subscription, and that effects take a few seconds. It lacks explicit statement about failure modes if already subscribed, but covers the most critical behaviors.

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, front-loading the purpose, then usage triggers, parameter guidance, and caveats. Every sentence adds value with no redundancy or filler.

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

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

For a single-parameter tool with no output schema, the description is nearly complete. It covers when to use, how to pass the parameter, cost/impact, and post-action behavior. It could explicitly state the success/error response format, but the lack of output schema is compensated by clear action guidance.

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

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

The schema already provides 100% coverage with a clear description of api_id. The description adds an example ('realtime_image_search') that reinforces the mapping but does not introduce new semantics 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 the tool's purpose: 'Subscribe the current OpenWeb Ninja API key to an API's free (BASIC) tier' with the goal of enabling use of that API's tool. It also provides a concrete example of an api_id, making it distinct from sibling data retrieval tools.

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

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

The description explicitly states when to call this tool: 'Call this when another tool returns a subscription/entitlement error: HTTP 401/403, or a 429 Too Many Requests when you have not subscribed to that API yet.' It also provides post-success guidance to wait and retry, leaving no ambiguity about usage timing.

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 no behavioral traits such as rate limits, authentication needs, data freshness, pagination behavior, or output structure. The description only enumerates operations and their required parameters, leaving the agent uninformed about side effects or access constraints.

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: a one-sentence summary followed by a clear list of operations with required params. Each line is informative, though the overall length is substantial due to the ten operations. It is concise relative to the complexity covered.

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?

The tool has 10 distinct operations, no output schema, and no annotations. The description provides operation names and required parameters but omits return formats, data types beyond string enums, error behavior, and operational caveats. It is minimally viable for selecting an operation but not fully complete for a multi-operation 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 schema provides generic args and an operation enum, but the description adds essential meaning by mapping each operation to its required parameter (e.g., company_details requires company_domain, category_search requires query). This mapping is critical for invoking the tool correctly and goes beyond the schema's generic 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 explicitly states 'Trustpilot company search, company details, reviews, and category company listings' and then enumerates ten distinct operations, giving a clear and specific verb+resource for each. This clearly differentiates it from sibling tools like yelp_business_data or local_business_data, which target other data sources.

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?

There is no guidance on when to use this tool versus alternatives. The description lists operations and required parameters but does not discuss context, prerequisites, or exclusions. The agent is left to infer usage purely from the tool name and the raw operation list.

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 of explaining behavior. It mentions operations and required parameters but does not disclose whether the tool is read-only, any rate limits, response formats, or authentication needs. The implicit data-retrieval nature is not explicitly confirmed, leaving ambiguity around side effects and data freshness.

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

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

The description is concise and well-structured, front-loading the tool's purpose and then using a bulleted list to enumerate operations and their required parameters. Every sentence earns its place with no unnecessary verbiage.

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 output schema and no annotations, the description should cover return values and invocation details, but it only provides a high-level operation list and required parameter names. It does not describe what each operation returns, coordinate formats, or potential error conditions, making it insufficient for fully reliable invocation.

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

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

The schema's 'args' field is generic, but the description lists required parameters for each operation (e.g., bottom_left, top_right, source_coordinates, destination_coordinates). This adds meaning beyond the schema, but it does not define parameter types or formats (e.g., coordinate representation, query string), leaving some semantics underspecified.

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 provides Waze data and enumerates four specific operations (alerts_and_jams, driving_directions, venues, autocomplete), each with a brief descriptor. This distinguishes it from the many sibling search tools and makes the purpose immediately evident.

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

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

The description provides no guidance on when to use this tool versus alternatives, and notably there is a sibling tool named 'driving_directions' that overlaps with one of the waze operations. No exclusions or criteria are given to help an agent choose between them.

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

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

With no annotations, the description must disclose behavioral traits, but it only explains the operation dispatcher pattern and required query. It does not mention whether the operation is read-only, any rate limits, or what the response format looks like, leaving the agent without important 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?

The description is compact and front-loaded with the purpose, but the bullet 'autocomplete (required: query): Autocomplete' includes a redundant trailing 'Autocomplete.' Overall, it is well-structured and efficient with no unnecessary filler.

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

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

For a single-operation tool, the description covers the dispatcher pattern and the required parameter, but it lacks any mention of the response structure or behavior for edge cases like empty queries. Given the absence of an output schema, this omission is noticeable, though the tool's simplicity keeps the gap moderate.

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

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

The schema describes the operation and args generically, but the description adds the specific required parameter 'query' and states that it is mandatory for the autocomplete operation. This clarifies the invocation beyond the schema, though it could elaborate further on the query's expected format.

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 'Google search autocomplete / query suggestions for a partial query,' which is a specific verb+resource combination. It distinguishes this tool from sibling search tools by focusing explicitly on query suggestions rather than general search or other specialized features.

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 partial query autocomplete but does not explicitly state when to use this tool versus alternatives like realtime_web_search or google_ai_mode. There are no exclusions or alternative recommendations, so the agent must infer the appropriate 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 are provided, so the description must carry the full burden of behavioral disclosure. It mentions the operation and required `query`, but does not explain what the tool returns, how it behaves during scraping, potential rate limits, or side effects. The operation description 'Scrape Contacts from Website' is tautological and adds no 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?

The description is relatively brief and front-loads the main purpose, followed by the operation list and usage guidance. It is well-structured, though the redundant operation description 'Scrape Contacts from Website' and the unsupported 'also find a website URL by keyword' clause could be tightened.

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

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

There is no output schema or annotations to fill gaps, and the tool has a nested `args` object with a required operation. The description does not explain return values, error handling, or the 'find a website URL by keyword' feature it mentions. This is incomplete for an API-style tool with no other structured context.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds a minimal operation schema and notes that `scrape_contacts` requires a `query`, but it does not clarify what `query` means (e.g., domain name vs. keyword) or how `args` should be structured. This adds some meaning beyond the schema but remains vague.

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

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

The description opens with a specific action: 'Extract emails, phone numbers and social links from a website/domain; also find a website URL by keyword.' This clearly states the tool's primary purpose and distinguishes it from the sibling email_search. However, the 'also find a website URL by keyword' capability is not reflected in the listed operations, which creates some ambiguity.

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

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

The 'When to use' section explicitly states 'Use to scrape contacts from a specific domain' and directs users to email_search for searching emails by person/company. This provides a clear use case and names a concrete alternative, satisfying the dimension fully.

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 adds that requests go through a proxy network and that JavaScript rendering is optional, but it does not disclose response formats, error behavior, rate limits, authentication, or how to enable the optional rendering. This is some behavioral context 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 short paragraphs plus a one-item bullet list. It front-loads the main purpose and includes a usage directive. The 'request: Request' line is slightly tautological but the structure is economical.

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 general-purpose tool with no output schema and no annotations, the description provides essential purpose and usage guidance but leaves operational gaps: no response format, no error handling, no rate limit info, and no way to activate the advertised JS rendering. It is minimally viable but incomplete.

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

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

The schema only provides generic placeholders for 'args' and 'operation'. The description adds concrete meaning: it names the only operation 'request' and specifies its required parameter 'url' (e.g., 'request (required: url)'). This goes beyond the schema. However, it does not document how to enable the mentioned optional JavaScript rendering, so coverage is incomplete.

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 opens with a clear verb ('Fetch'), resource ('raw HTML/content of any URL'), and mechanism ('through OWN's anti-bot proxy network'). It explicitly frames itself as a general-purpose fallback, distinguishing from dedicated sibling tools like realtime_amazon_data and realtime_zillow_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?

It explicitly states 'Use only when no dedicated API covers the target site' and advises 'Prefer the structured tools (Amazon, Zillow, etc.) when one exists.' This provides clear exclusionary criteria and names 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention whether operations are read-only, network-dependent, or require authentication, nor does it describe result limitations or error behavior. The operation names imply read-only retrieval, but the description offers no explicit safety or side-effect 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?

The description is compact, well-structured, and front-loaded with the tool's purpose. Operations are listed in a bullet list with required parameters, and the usage note is a single sentence. Every sentence earns its place 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?

The tool has three distinct operations and no output schema, yet the description covers operation selection, required arguments, and the sibling alternative in a concise format. It lacks details about return value structure or any special behaviors, but it provides enough for an agent to select and invoke the tool correctly in the common case.

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

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

The schema's args is a generic object with additionalProperties, deferring all parameter meaning to the description. The description clearly lists required parameters per operation (query and location for business_search; business_id for details and reviews), which is essential for correct invocation. However, it does not describe optional parameters, types, or formatting, so it is not a 5.

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 covers three Yelp-specific operations: business search, business details, and business reviews. It uses distinct verbs per resource and explicitly differentiates itself from the sibling tool local_business_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?

It explicitly says 'Use for Yelp specifically' and directs users to local_business_data for Google Maps businesses, providing a clear when-to-use and alternative. The operation list also clarifies how to choose among the tool's own functions.

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