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

With no annotations, the description carries the full burden and largely delivers. It explains sync vs async behavior, that async returns a request id for polling via requests_get, and how prompt and schema jointly affect extraction. It stops short of disclosing costs, rate limits, or failure behavior, but what it does disclose is substantial and non-obvious.

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 longer than typical, but every section earns its place given the nested schema and mode selection. The use of 'Best for', 'How schema works', and 'Execution notes' improves scannability. A slight redundancy exists because 'best for structured data from a single page' is repeated after the earlier best-for list.

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 nested schema, no annotations, and multiple execution modes, the description covers the key operational details: what the tool does, when to use it, how to write the schema, and how to handle sync vs async. It does not mention authentication, account balance, or failure/error handling, but the presence of an output schema lessens the need to describe return shapes.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds significant meaning beyond the schema. The example schema clarifies how to shape output, and the execution notes explain the semantic difference between sync and async plus the combined effect of prompt and schema. This directly helps an agent construct correct 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 a specific verb and resource: 'Extract structured information from a web page with Outscraper AI Scraper.' It further clarifies this is for turning a single page into structured JSON, which clearly distinguishes it from the many search/review/listing sibling 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 'Best for' section gives concrete use cases and the description states it is best for structured data from a single page. It also explains how async execution connects to requests_get for polling. It does not explicitly name sibling tools to avoid, but the single-page scoping makes the intended usage clear.

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

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

Annotations are not provided, so the description bears the full burden of behavioral disclosure. It states it 'fetches' a balance, implying read-only, but does not explicitly confirm that it is side-effect-free, does not consume credits, or how it handles invalid keys. The reference to the active API key adds useful context, but the transparency is incomplete.

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 lead sentence and bullet-point lists. However, the 'Best for' and 'Use this when' sections overlap in content (e.g., 'checking whether the key is attached to a funded account' vs. 'quick health check'), introducing some redundancy. It is not verbose but could be tightened without losing value.

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

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

For a simple tool with no parameters and an output schema likely documenting return fields, the description adequately covers the purpose, usage scenarios, and the reliance on the active API key. The only missing element is an explicit read-only confirmation, which is minor given the tool's nature.

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

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

The tool has zero parameters, so the schema is empty and fully covered. The description correctly omits parameter explanations that are unnecessary. The mention of 'active API key' is contextual, not a parameter, and does not conflict with 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 first sentence clearly states the action (fetch), the resource (current Outscraper account balance and billing summary), and the scope (active API key). It is immediately distinct from all sibling tools, which are focused on data scraping, searching, and review retrieval. No ambiguity exists about what this tool does.

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 'Best for' and 'Use this when' sections provide concrete scenarios: checking funded status, confirming before large jobs, and debugging billing issues. Although no alternatives are mentioned, none exist among siblings, so the guidance is sufficiently directive. The usage contexts are practical 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 of behavioral disclosure. It fails to mention that this is a read-only operation, whether it can be expensive or rate-limited, or that it supports async execution modes. The description mentions the endpoint but not the behavior around async/sync or webhook usage, which is critical for a potentially long-running operation.

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

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

The description is concise, just one sentence, but it lacks useful information. It's not overly long, but it could be more informative without becoming bloated. It repeats the endpoint name which is somewhat redundant. Front-loading is fine, but the content is thin.

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

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

Given the tool's complexity (11 parameters, async execution options, webhook), the description is grossly inadequate. It doesn't explain the business context (e.g., how to use 'query' for Booking URLs, what 'cutoff' means, when to use 'execution_mode'). The output schema exists, so return values are covered, but the description fails to provide enough context for an agent to call this tool effectively, especially with so many optional parameters.

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 for all parameters, but many descriptions are terse (e.g., 'Skip reviews', 'Booking sort parameter'). The description text adds no additional meaning beyond what's in the schema, so it doesn't compensate or clarify. Baseline 3 is appropriate as the schema covers the parameters, but the tool description adds no value in clarifying parameter usage.

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 Booking reviews via a specific endpoint, but it's somewhat vague about the exact resource (reviews for what? Booking URLs?). It distinguishes from siblings like yelp_reviews and tripadvisor_reviews, though not explicitly. The verb 'Fetch' is specific and the resource is 'Booking reviews', making it clear enough.

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 minimal usage guidance, only mentioning the endpoint. It doesn't explain when to use this tool versus alternatives like tripadvisor_reviews or yelp_reviews. No context on prerequisites (e.g., need Booking URLs) or typical use cases. The agent is left to infer usage from the name and parameters.

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

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

No annotations are provided, so the description carries full burden. It describes the operation as retrieving/fetching data, so behavior is clear. However, it doesn't disclose what 'full detail payload' includes or how fields selection works beyond the schema. It also doesn't mention whether it returns a single object or array. This is adequate but not rich.

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

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

The description is compact, with key information front-loaded (what it does) followed by usage guidance. Every sentence adds value; no redundancy or fluff.

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

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

The tool is simple (2 params, 1 required) and has an output schema, so the description doesn't need to explain return format. The description covers purpose and usage. The only minor gap is not explaining the 'full detail payload' vs field-selected payload, but that's arguably obvious from the fields parameter. Overall complete enough.

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 with descriptions (business_id and fields), and coverage is 100%. The description adds context that business_id comes from businesses_search, which is helpful. No additional parameter semantics are added beyond that, so a baseline 3 is appropriate.

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

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

The description clearly states the tool retrieves a single business by Outscraper business id and explains the difference from businesses_search, which is for discovery. It specifies the resource (business details) and the verb (get), making it unambiguous and distinct from siblings.

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

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

Explicitly instructs when to use this tool (after businesses_search, when business_id is known) and when not to use it (for discovery), referencing the sibling tool businesses_search. This provides clear routing guidance.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the endpoint is synchronous, that async-style execution controls are intentionally not exposed, and that free-form query parsing may fail with a specific error. It also notes that structured filters are the most reliable input mode. It doesn't mention pagination behavior beyond cursor support, but the schema already covers cursor. The description adds meaningful behavioral context beyond the schema.

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

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

The description is well-structured with clear sections and front-loaded purpose. It is somewhat longer than necessary, but every section earns its place: the 'Best for' and 'Prefer this tool' sections provide actionable guidance, and the notes about synchronous behavior and query parsing failures are valuable. The bullet-point format makes it scannable.

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 purpose, usage context, alternatives, and important behavioral caveats. With an output schema present, return values don't need to be explained. The only minor gap is that it doesn't describe the structure of the filters object in detail, but the schema's 'Structured Outscraper /businesses filters JSON' description plus the note about reliability is sufficient for an agent to proceed. Overall, it is complete for a tool with this complexity.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters. The description adds context about the query parameter's reliability (may fail to parse) and emphasizes structured filters as the most reliable mode, which is useful. However, it doesn't add much detail about the filters object structure or fields parameter beyond what the schema provides. Baseline 3 is appropriate given full schema coverage.

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

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

The description clearly states the tool searches Outscraper businesses using structured filters, natural-language query, or both. It explicitly distinguishes this from google_maps_search by noting it targets the normalized /businesses dataset rather than raw Google Maps search behavior. The verb 'search' plus the resource 'businesses' and the mention of structured filters makes the purpose unambiguous.

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

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

The description provides explicit 'Best for' and 'Prefer this tool when' sections, and directly names the alternative google_maps_search with the condition for choosing this tool instead. It also includes a note about the synchronous endpoint and warns that free-form query parsing may fail, which helps the agent decide when to use structured filters. This is exemplary 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 transparency burden. It discloses that the tool layers a documented enrichment on the Google Maps search pipeline, implying a read/enrichment operation. However, it doesn't address async behavior, rate limits, or any operational caveats beyond this.

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

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

Three short sentences, front-loaded with the core purpose. The phrase 'documented enrichment' appears twice and is slightly redundant, but there is no material waste.

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

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

For a 7-parameter enrichment tool, the description plus schema provide sufficient context: the query intent is explicit, the Google Maps pipeline is named, input parameters are fully described in the schema, and an output schema exists. It doesn't elaborate on execution modes, but the schema already covers those 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?

Schema description coverage is 100%, so all parameters already have semantic descriptions. The tool description adds no per-parameter detail, but the schema carries the weight; baseline 3 is appropriate.

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

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

Uses a specific verb ('Detect') and a specific resource ('chain membership'), and names the underlying ai_chain_info enrichment. This clearly differentiates it from sibling search, review, and contact-enrichment tools.

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

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

Explicitly states when to use it: 'Use it when you want to know whether a business is part of a chain.' It doesn't name an alternative sibling or provide a when-not, but the intended use case 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 provided, the description carries the full burden of behavioral disclosure. It explains distinct sync vs async behaviors and the return payloads for each mode ('direct response payload' vs 'async request metadata'), and mentions the async tracking via requests_get. It does not disclose error handling, rate limits, or side effects, but for a read-oriented enrichment tool the description is reasonably transparent. It does not contradict any annotations (none exist).

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

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

The description is organized with clear sections ('Best for', 'Prefer this tool when', 'Use async mode when', 'Use emails_and_contacts instead when', 'Returns'). It is longer than a one-liner but each bullet point adds decision-relevant information. The structure front-loads the core purpose and then drills into when/how to use it, making it efficient 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?

Given the tool's complexity (6 parameters, sync/async modes, multiple use scenarios) and the presence of an output schema (which obviates the need to describe return structure in full), the description covers the key decision points: use cases, alternatives, and mode selection. It omits details like error handling or rate limits, but those are often outside the scope of tool descriptions and the core info needed for correct invocation is present.

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

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

Schema description coverage is 100%, so parameters are already documented. The description adds meaningful context beyond the schema: it explains when to prefer async mode, how execution_mode relates to sync/async, and how async jobs can be tracked with requests_get. This goes beyond simple repetition of the schema's fields and helps the agent make parameter choices.

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 exactly what the tool does: 'Get structured company-level insight data from Outscraper.' It clearly distinguishes itself from siblings by explicitly positioning it for company enrichment (firmographics, size, revenue, industry) versus contact extraction, which is a key differentiator from tools like emails_and_contacts. The purpose is 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 gives explicit 'Prefer this tool when...' conditions, contrasts with emails_and_contacts, and provides async mode guidance including when to use it and how results can be tracked with requests_get. It covers both positive and negative usage cases, leaving no ambiguity about when to invoke this tool.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It transparently exposes the existence of async mode, explains that long crawl/enrichment may occur, and points to requests_get for progress tracking. It also flags the async parameter as deprecated in favor of execution_mode. However, it does not explicitly state whether the operation is read-only or write-related, nor does it mention any potential costs or rate limits. These are minor gaps given the detailed mode guidance, so a 4 is warranted.

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 one-sentence purpose, bullet-point 'Best for', and clear decision sections. It is front-loaded with the core function, and every section serves a distinct purpose—usage, async guidance, and alternative routing. No filler or repetition. It is longer than average, but every sentence earns its place given the tool's complexity.

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

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

For a tool with 5 parameters (1 required), an output schema, and multiple execution modes, the description covers all necessary aspects: main use case, when to use this vs. the sibling, async behavior and tracking, and parameter guidance. The existence of an output schema relieves the need to describe return values. The description also anticipates common questions (e.g., many domains at once) making it complete for agent invocation.

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

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

Schema coverage is 100%, so the baseline is 3. The description goes beyond schema definitions by explaining parameter interplay: it defines query as 'domains or URLs' with an example, elaborates on execution_mode ('Use auto to let the MCP server choose between sync and async'), and clarifies async as a 'Deprecated compatibility flag'. It also adds context to preferred_contacts as 'contact-role prioritization.' This adds meaningful value over the schema's brief descriptions.

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

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

The description opens with a clear, specific action: 'Find emails, phones, and social/contact data from one or more company domains.' It names the exact resource types and the input (domains), and explicitly differentiates from sibling company_insights by stating what it does NOT do (firmographics, revenue, etc.). This is a textbook example of a specific verb+resource with sibling differentiation.

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

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

The description provides explicit when-to-use sections: 'Prefer this tool when...' and 'Use company_insights instead when...', directly addressing when to choose this tool over an alternative. It also gives concrete async usage guidance ('Use async mode when...') and references tracking with requests_get. Nothing is left to inference.

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. 'Validate' strongly implies a non-mutating check, which is helpful context, but the description doesn't explicitly explain the async/webhook execution behavior that the schema exposes. It also leans on 'documented endpoint' rather than stating important operational details inline.

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: one lead sentence stating the action and endpoint, followed by a scannable three-item 'Best for' list. Every line earns its place, and no filler is present.

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 straightforward validator with a fully documented schema and an output schema present, the description covers the main use cases and purpose. It could be marginally more complete by noting rate/cost implications or the deprecated async flag, but nothing essential is missing for selecting and invoking the 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?

Input schema coverage is 100%, and each parameter already has a meaningful description (query, async, webhook, execution_mode). The tool description doesn't need to restate parameter meanings; the baseline 3 applies because it adds no extra parameter-level insight 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 opens with a specific verb-resource pair ('Validate email addresses') and names the exact endpoint, then reinforces the purpose with three concrete use cases. This clearly separates it from sibling tools like emails_and_contacts, which are about finding/collecting emails rather than checking validity.

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 'Best for' bullets give clear contexts (deliverability checks, lead-list validation, pre-enrichment filtering) that tell an agent when to choose this tool. It doesn't explicitly say when not to use it or name alternatives, so it stops one step short of a 5.

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

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

No annotations are provided, so the description must carry behavioral disclosure, but it only says 'Fetch'. It does not mention async/sync execution modes, webhook behavior, potential rate limits, or any side effects, despite having parameters that imply these 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?

Compact, front-loaded, and easy to scan with a short summary and three bullets. No redundant filler, though it could be slightly more informative without losing conciseness.

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 schema is rich and an output schema exists, covering parameter and return details. However, with 10 parameters and no annotations, the description could more explicitly explain execution modes, tag semantics, and when to use async, so agents aren't left to infer operational behavior.

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

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

Schema coverage is 100%, so the baseline is 3, but the 'Best for' bullets add meaning by mapping use cases to the tag enum (menu, by_owner, latest) and to query-based photo extraction. This goes beyond the bare parameter descriptions in the schema.

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

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

Clearly states 'Fetch Google Maps photos' with a specific verb and resource. The 'Best for' bullets (place photo extraction, menu, owner, latest) help differentiate from siblings like google_maps_search and google_maps_reviews, though it doesn't explicitly say what the returned data contains.

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

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

Provides clear context via 'Best for', telling an agent when to use it for photo-related needs. It does not name alternatives or exclusions, but the listed use cases are specific enough to guide selection.

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

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

With no annotations provided, the description carries the full burden. It discloses async/sync execution modes, mentions webhook for async completion, and explains polling progress via requests_get. However, it does not explicitly state read-only behavior, rate limits, or error handling, though these are implied by the nature of a fetch tool. The guidance on async for heavy jobs adds meaningful 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 well-structured with clear section headers (Best for, Prefer this tool when, Use async mode when, Do not use) that front-load the core purpose and usage. Every sentence earns its place, and the bullet-point format makes it scannable without unnecessary prose. It is appropriately sized for a complex 17-parameter 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?

Despite 17 parameters and an output schema, the description is complete enough for an agent to call it correctly. It explains use cases, alternatives, async behavior, and even provides a workflow (use google_maps_search first). The output schema covers return values, and the parameter schema covers individual params, so nothing critical is missing from the description's standpoint.

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 100% of parameters with descriptions, so the baseline is 3. The description repeats the query parameter's meaning ('place ids or place queries') but adds no new information about parameters beyond what the schema already provides. It doesn't elaborate on sort, limit, or other params, but the schema handles those adequately.

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

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

The description opens with a specific verb and resource: 'Fetch Google Maps reviews for place ids or place queries.' It clearly distinguishes from siblings by explicitly stating it is for reviews, not basic place discovery, and directly references google_maps_search as the alternative for that purpose. This makes the tool's 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 'Prefer this tool when' and 'Do not use this' sections provide explicit conditions and name the alternative (google_maps_search). It also details when to use async mode and mentions polling with requests_get, giving clear decision guidance. No other tool in the sibling list is routed to as directly, making this exceptionally 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?

Since no annotations are provided, the description carries the full burden. It mentions async submissions, enrichments, execution_mode choice, and implicitly indicates read-only behavior by being a search. It also notes the absence of cursor pagination (in contrast to businesses_search). However, it does not explicitly state the return format or side effects, but the output schema covers return structure. Overall, it offers solid 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 moderately long but well-structured with bullet points, making it scannable and front-loaded with the primary purpose. Each bullet adds distinct guidance without repeating schema info. It earns its length by covering usage scenarios and alternatives.

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

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

Given the tool's complexity (12 params, output schema present), the description comprehensively covers usage scenarios, alternatives, and execution mode guidance. It lacks authentication or error mention, but those are likely implicit in a search tool. The output schema handles return details, so the description is sufficiently complete for an 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?

Schema description coverage is 100%, so every parameter is already documented. The description adds usage context (e.g., 'Google Maps-style queries', execution_mode triggers) but does not provide parameter-specific details beyond the schema. Baseline of 3 is appropriate as the schema does the heavy lifting.

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

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

The description clearly states 'Search Google Maps places through Outscraper' and differentiates from the sibling tool businesses_search by emphasizing direct Google Maps search pipeline vs normalized filters. It specifies use cases like 'ad hoc place discovery' and distinguishes itself from alternatives explicitly.

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

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

The description provides explicit 'Prefer this tool when' and 'Use businesses_search instead when' conditions, and further guides on execution_mode='auto' with specific triggers. This is excellent routing information that leaves no ambiguity about when to choose this tool over siblings.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'Search Google.' It does not explain pagination behavior, whether async execution is possible, what happens with multiple queries, or any rate limiting or error conditions. The agent is left without critical operational 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 one-sentence description is perfectly concise and front-loaded with the action. However, for a tool with 12 parameters and 26 sibling tools, this brevity reads as under-specification rather than effective trimming. It contains no filler but omits valuable context.

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

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

Given the tool's complexity (12 parameters, async/sync execution modes, webhook support, multiple sibling tools) and zero annotations, the description is inadequate. An agent cannot decide when to invoke it, how it behaves, or how to configure it beyond reading the schema. The output schema helps but does not compensate for missing usage 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 no parameter-specific meaning, but since every parameter already has a schema description, the tool definition meets the minimum viability threshold without needing additional prose.

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

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

The description states a specific verb and resource: 'Search Google with the documented /google-search endpoint.' It clearly identifies the core function. However, it does not differentiate from sibling tools like google_search_images or google_maps_search, so an agent may need to inspect other definitions to disambiguate.

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 vs. the many sibling search tools (images, maps, businesses, etc.). There is no mention of exclusions, prerequisites, or alternative selection criteria. The agent must infer usage from the name alone.

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

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

No annotations are provided, so the description carries the full burden. It only says 'Search Google Images' and references an endpoint; it does not disclose async/webhook behavior, execution_mode semantics, pagination, or result characteristics. The verb 'Search' weakly signals a read-only operation, but little else is transparent.

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

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

The description is short and front-loaded, but it is under-specified for a 9-parameter tool. The clause 'with the documented /google-search-images endpoint' is redundant and does not earn its place, leaving the description closer to a name restatement than useful specification.

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?

Although the schema and output schema cover parameter mechanics, the description leaves key contextual gaps: no differentiation from google_search, no guidance on sync vs async, and no mention of webhook or regional/language behavior. An agent can invoke the tool, but not with confidence about when or how it behaves.

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 no parameter semantics beyond the schema, but the schema already documents query, limit, fields, region, language, webhook, execution_mode, uule, and async adequately.

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

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

The description states a clear verb and resource: 'Search Google Images.' This distinguishes it from the sibling google_search tool at a basic level. However, it mostly restates the tool's name/title and adds no scope or filtering detail, so it stops short of top-tier clarity.

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 instead of google_search or other sibling search tools. No context, exclusions, or prerequisites are provided, so an agent must infer usage from the tool name and schema.

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 full burden. It only states that it searches via an endpoint, giving no information about execution modes, rate limits, data handling, or side effects. This is minimal and uninformative for a tool that has async capabilities and enrichment options.

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 short (one sentence) but it's under-specification rather than effective conciseness. It repeats the tool name and adds no structural benefit or front-loaded key information. It fails to convey any actionable details.

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

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

Given the tool has 7 parameters, an output schema, and many sibling alternatives, the description is severely incomplete. It doesn't explain return structure, execution behavior, or selection criteria. Even though output schema exists, an agent lacks enough context to know when to call this 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?

The schema provides 100% description coverage for all 7 parameters, so the baseline is 3. The description adds no parameter-specific meaning beyond what the schema already documents. It doesn't compensate or elaborate on any 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 description states a clear verb+resource: 'Search Indeed'. It clearly identifies the target platform, distinguishing it from other search tools like google_search or yellowpages_search. However, it doesn't mention any scope or specific capabilities beyond the generic search, so it's not fully differentiated from similar siblings.

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

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

No guidance is provided on when to use this tool versus the many sibling search tools. It doesn't mention any prerequisites, context, or exclusions. An agent cannot infer when Indeed is the appropriate 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 must carry the full burden. It clearly states the synchronous nature and the lack of async/webhook support, which is a key behavioral trait. Beyond this, it doesn't detail other behaviors like rate limits or data retention, but the explicit note on execution mode is a significant disclosure that goes beyond typical descriptions.

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

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

The description is compact and front-loaded, leading with the core purpose and then listing use cases in a bullet-like format. The note on synchronous execution is appended at the end, preserving flow. Every sentence has a purpose, with no fluff or repetition.

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

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

Given the tool's simplicity (single parameter, no nested objects) and the presence of an output schema, the description covers the essential aspects: purpose, use cases, and execution mode. It doesn't describe the return format, but since an output schema exists, that's not required. The lack of annotations is compensated by the synchronous note, and there are no missing pieces for an agent to make a correct call.

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

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

Schema coverage is 100% for the single parameter 'query', which is described as 'One or more phone numbers to enrich.' The description adds value by implying that the query is about phone numbers and the purpose is enrichment, complementing the schema. It doesn't add extra syntax details, but the schema is already clear, so this is sufficient.

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: to enrich phone numbers using a specific endpoint. It lists three concrete use cases (carrier lookup, phone validation, message deliverability checks), which are specific enough to differentiate from sibling tools like emails_validator or businesses_search, which deal with different data types.

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 use cases ('Best for:') without explicitly naming alternatives for when not to use it. However, the clear focus on phone-specific tasks implicitly distinguishes it from email or business tools. It also mentions the synchronous-only limitation, guiding the agent on execution expectations, which is valuable for usage decisions.

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 explicitly states observable behavior: a reachability check plus return of basic server metadata, which also implies a read-only, non-destructive operation. It does not enumerate every operational detail like auth or latency, but for a simple ping that is sufficient.

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

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

The description is compact and front-loaded: one clear declarative sentence followed by three relevant use-case bullets. Every sentence earns its place, with no filler or repetition.

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

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

For a zero-parameter health check with an output schema, the description fully covers what the tool does and when to use it. An agent has everything needed to select and invoke the tool correctly.

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

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

The tool has zero parameters and the schema is trivially complete at 100% coverage. Per the baseline for no-parameter tools, the description is not required to add parameter semantics; nothing is missing.

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

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

The description uses a specific verb-plus-resource construction: 'Check whether the Outscraper MCP server is running and return basic server metadata.' This clearly differentiates ping from all sibling tools, which focus on scraping, search, review, and request/balance operations.

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 'Best for' section gives concrete, actionable scenarios: validating startup, confirming reachability before live API calls, and lightweight health checks in demos or registry validation. It does not list exclusions or alternatives, but no sibling tool serves the same health-check purpose, so the guidance is clear enough.

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

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

With no annotations, the description correctly carries the burden of disclosing destructive behavior. It clearly states the request will be terminated and should not be expected to complete normally, which is the key behavioral risk an agent must know before invoking.

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 front-loaded action, a 'Best for' list, and a 'Use this carefully' section. Minor redundancy exists between 'cleaning up... no-longer-needed jobs' and 'only use it when you are sure the request is no longer needed', but overall it is efficiently 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?

For a simple one-parameter delete tool with an output schema, the description covers purpose, appropriate use cases, caution, and the destructive consequence. Nothing essential is missing for an agent to decide whether and how to invoke it.

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

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

The input schema fully documents request_id (type: string, minLength: 1, 'Async request id to delete'), so the schema already covers parameter meaning. The description adds only 'by request id', which does not materially extend the schema's 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 states a specific verb ('Delete or terminate'), a specific resource ('asynchronous Outscraper request'), and a required identifier ('by request id'). This clearly distinguishes it from reading tools like requests_get and requests_list.

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

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

The 'Best for' bullets give concrete scenarios: cleaning up queued jobs, stopping polling, and testing lifecycle. It also provides a caution that the tool should only be used when the request is no longer needed, though it does not name sibling tools for locating or inspecting request IDs.

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 of behavioral disclosure. It reveals that callers must poll until completion or failure and mentions the Pending/Success/Failure statuses, which is useful. However, it does not state that this is a read-only operation, note rate-limit considerations, or clarify what happens if the request id is invalid.

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 clear lead sentence, a short typical flow, and a bulleted when-to-use list. Every section earns its place and the most important starting point is front-loaded.

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

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

For a single-parameter status-polling tool with an output schema, the description covers the trigger, the flow, the parameter source, and termination conditions. Nothing essential is missing for an agent to invoke it 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 already covers the only parameter with 'Async request id.' and has 100% coverage. The description reinforces this by explaining the id comes from a prior async submission and should be captured after calling an async tool, which adds modest context but no new format or syntax details.

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

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

The description opens with a crisp verb-resource pairing: 'Check the status of an asynchronous Outscraper request.' It clearly differentiates from sibling tools like requests_list and requests_delete by focusing specifically on status polling of an already-submitted request.

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

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

The description gives explicit when-to-use conditions: after an async call, when an async request id was returned, and when pending/success/failure status is needed. It also presents a typical flow. It does not name an alternative like requests_list for listing or cleaning requests, so the exclusions are implicit rather than explicit.

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

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

No annotations are provided, so the description must carry the full behavioral burden. It implies a read-only listing operation but does not explicitly state lack of side effects, authentication requirements, or behavior on empty result sets. It also fails to mention any pagination or rate-limit implications. The description lacks the transparency expected of a tool with zero 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 well-organized with a concise opening sentence followed by clearly labeled 'Best for' and 'Use this when' sections. It avoids fluff and front-loads the core purpose, making it easy for an agent to scan and understand quickly.

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

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

Given the simple optional parameter and the presence of an output schema (as indicated by context), the description covers the essential use cases: listing recent requests, debugging async flows, and checking status. It does not mention edge cases like pagination or error conditions, but for a straightforward list tool with an output schema, this is reasonably complete.

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

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

The schema describes the only parameter 'type' as 'Optional request bucket.' The tool description adds meaning by explaining the buckets as 'running, completed, or failed,' which maps directly to the enum values. This enriches the schema description without redundancy.

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 clear, specific verb and resource: 'List recent Outscraper requests by bucket.' This immediately distinguishes it from sibling tools like requests_get (specific request retrieval) and requests_delete (deletion). The 'Best for' and 'Use this when' sections reinforce the purpose without tautology.

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

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

The description provides explicit 'Best for' and 'Use this when' lists, giving concrete scenarios such as debugging async flows and recovering lost request IDs. It does not explicitly name alternatives, but the context makes the intended use clear enough relative to 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?

With no annotations provided, the description carries the full burden of behavioral disclosuretons. It only states that the tool is a legacy alias and that the canonical tool should be preferred; it does not describe what the tool does, side effects, return behavior, async implications, or any operational constraints. The alias status is useful but not enough 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 two short sentences with no wasted words. The legacy-alias status is stated firstable, and the routing recommendation follows immediately. It earns its place as a compact deprecation notice.

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 a simple alias with a well-covered schema and an output schema, so the structured data fills many gaps. However, the description does not independently state what the tool does or how its behavior relates to trustpilot_data beyond being an 'alias.' For a legacy alias, the deprecation guidance is communicated, but an agent would still need to consult the canonical tool's description for full 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 parameters are already well documented in the input schema, including query, execution_mode, async, fields, webhook, and enrichment. The description adds no additional parameter meaning and does not need to because the schema already carries the semantic weight.

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 identifies the tool as a legacy alias for trustpilot_data, which makes its relationship to the sibling clear, but it does not state the actual function with a verb and resource. The title 'Trustpilot Data' and the schema's query description imply it retrieves Trustpilot data, but the description itself only describes its alias/deprecation status.

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 names the preferred alternative and the condition: 'Prefer trustpilot_data for new integrations.' This clearly tells the agent when not to use this tool and directs it to the correct sibling able. It does not spell out 'use this only for legacy integrations,' but that is strongly implied by the word 'Legacy.'

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 only mentions legacy alias status and says nothing about execution behavior, data returned, side effects, async handling, or rate limits. For a tool with execution_mode and async parameters, this is a significant 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 two short sentences with no filler. It front-loads the alias status and immediately communicates the preferred alternative. Every word earns its place.

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

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

The definition is adequate for a legacy alias whose main job is to route agents to trustpilot_reviews, and the rich schema covers parameters and outputs. However, it lacks any operational description of what the tool does, leaving the agent to infer behavior from the title and schema alone.

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

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

Schema description coverage is 100%, so the parameters are already well documented in the schema. The description adds no additional parameter meaning, which matches the baseline of 3 for complete schema coverage.

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

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

The description identifies tp_reviews as a 'Legacy alias for trustpilot_reviews' but never states the actual action or resource, such as fetching Trustpilot reviews. The title and schema implicitly communicate the purpose, but the description itself remains vague and indirect.

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 instructs agents to 'Prefer trustpilot_reviews for new integrations', which gives clear routing guidance away from this alias. It does not elaborate on when legacy usage is acceptable, but the alias status plus preference statement is sufficient context.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'fetch,' without mentioning how the endpoint behaves regarding async execution, webhooks, cutoff handling, or response structure. This is minimal but not misleading.

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, but part of it is filler: 'with the documented /tripadvisor-reviews endpoint' adds little since the endpoint is implied by the tool name. It is concise but misses an opportunity to convey meaningful guidance.

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

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

Despite having an output schema and well-documented parameters, this 8-parameter tool still needs usage context that the description does not provide. There is no indication of how to construct queries, what the output represents, or how async/webhook behavior should be handled.

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

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

Schema description coverage is 100%, so parameters are already documented with descriptions like 'One or more Tripadvisor URLs' and 'Execution strategy.' The tool description adds no extra semantic value beyond what the schema provides, so the baseline 3 is appropriate.

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

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

The description states a clear verb and resource: 'Fetch Tripadvisor reviews.' This distinguishes it from broad search tools like tripadvisor_search, though it does not explicitly differentiate it from other review-focused siblings such as booking_reviews or yelp_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?

No guidance is given on when to choose this tool over alternatives. The description does not explain that Tripadvisor URLs are required, when async execution makes sense, or when to use another scraper or review 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. It mentions nothing about whether it is read-only, whether it can be async (though parameters suggest async support), pagination behavior, rate limits, or whether it might be slow. The phrase 'documented endpoint' implies an external API but does not explain side effects or operational behavior.

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

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

The description is a single sentence, which is concise, but it is under-specified. It refers to 'documented' endpoint without offering any inline hint about the endpoint's purpose. For 8 parameters and complex sibling landscape, a few more sentences would improve usability without bloating.

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

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

Given the tool's complexity (8 params, multiple siblings, output schema present), the description is insufficient. It does not explain what the output looks like, how to interpret results, how to choose between sync/async, or how this search differs from tripadvisor_reviews. Agents would likely struggle to select and call this correctly without external documentation.

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

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

Schema coverage is 100%, so each parameter has a description, but the descriptions are minimal (e.g., 'Skip results', 'Maximum results'). The overall description does not explain how parameters like 'query' (array of strings) are used, what 'search_type' values are valid, or how 'execution_mode' differs from 'async'. It adds little 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 'Search Tripadvisor' which is a clear verb+resource, but it lacks scoping details such as what types of entities (businesses, reviews, etc.) are returned. It only references the 'documented /tripadvisor-search endpoint' without elaborating, which is somewhat vague. It does not distinguish itself from siblings like 'tripadvisor_reviews' or 'businesses_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?

No guidance is given on when to use this tool versus siblings such as tripadvisor_reviews or google_maps_search. The description does not state whether to use it for general searches vs. specific entities, nor does it provide context like 'use for broad searches; use tripadvisor_reviews for detailed review retrieval'. With 8 parameters and many siblings, more guidance is needed.

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

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

No annotations are provided, so the description carries the full burden of disclosing behavior. It does not mention that the tool may execute asynchronously (despite execution_mode and webhook params), rate limits, data scoping limitations, or any side effects. 'Fetch' implies a read operation but does not address the async complexity present in the schema.

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

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

The description is a single concise sentence with no filler, and the core action and target are front-loaded. However, it is arguably under-specified for the tool's complexity, but the dimension rewards efficiency over completeness; there is zero waste.

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

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

Given the tool's 6 parameters, no annotations, several ambiguous sibling tools, and no usage guidance, the description is insufficient. The output schema exists so return values need not be described, but the description still lacks information about when to use it, what data is fetched, and how it relates to similar Trustpilot 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 description coverage is 100%, and the description adds no extra parameter meaning. It does not clarify how 'enrichment' works, what 'fields' are valid, or how 'query' should be formatted beyond the schema. Baseline 3 applies because the schema already handles parameter documentation.

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

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

The description clearly states a specific verb ('Fetch') and resource ('Trustpilot business data'), so an agent knows what action is performed. However, it does not differentiate this tool from near-siblings like 'tp_data', 'trustpilot_reviews', or 'tp_reviews', and 'business data' is broad enough to overlap with other Trustpilot tools.

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

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

The description provides no guidance on when to use this tool versus alternatives, no exclusion criteria, and no mention of recommended use cases. It merely states what it does, leaving the agent to infer selection from the name and broad 'business data' phrase.

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 disclosing behavioral traits. The single sentence mentions the endpoint but reveals nothing about execution modes (async/sync), rate limits, error behavior, pagination, or side effects. Even the existence of an execution_mode parameter is not hinted at. This is insufficient for an agent to understand how the tool behaves beyond 'fetching.'

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 one short sentence, which is concise but severely under-specified. It does not front-load any critical scoping info or behaviors. The phrase 'with the documented /trustpilot-reviews endpoint' is filler that adds no value. For a tool with eight parameters and an output schema, this is too brief to be useful; it reads like a stub rather than a considered description.

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

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

Despite having an output schema and eight parameters (including execution_mode and async), the description explains none of the operational context. It does not mention how to choose between sync/async, what fields can be requested, how pagination works, or what the response structure is. An agent would need to rely entirely on the schema and output schema, which may not capture runtime behavior. The description is critically incomplete for a tool of this complexity.

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

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

Schema description coverage is 100%, so all eight parameters have descriptive text in the schema. The description adds no extra meaning to the parameters, but the schema already documents their roles. Per the rubric, with high schema coverage the baseline is 3, and the description does not lower that score. However, it also does not add any semantic clarity 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 clear verb and resource ('Fetch Trustpilot reviews'), and mentions a specific endpoint. However, it does not differentiate this tool from several siblings with overlapping purposes (trustpilot_data, tp_reviews, tp_data), and the word 'documented' adds no distinguishing information. Without specifying scope or uniqueness, the purpose is clear but not well differentiated.

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

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

The description provides no guidance on when to use this tool versus alternatives. It neither states when to prefer it nor mentions any exclusions or prerequisites. There are many sibling review tools (e.g., yelp_reviews, tripadvisor_reviews) that could overlap, and the agent is left with no decision support. This is a complete absence of 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?

With no annotations, the description carries full responsibility for disclosing behavior, but it reveals nothing beyond the endpoint name. It does not mention execution modes, async behavior, webhooks, result shape, pagination, rate limits, or what data is returned. The phrase 'documented endpoint' punts all useful context to an unspecified external reference.

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 text is short, but shortness here is under-specification, not conciseness. The single sentence earns no real informational value because it merely rephrases the title and references an endpoint. It is a placeholder-level description.

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

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

Despite the output schema and fully documented parameters, the description leaves out critical context for a tool with 9 parameters, async/sync execution, deprecated flags, enrichment, and webhooks. The phrase 'documented endpoint' is not a substitute for telling an agent what the tool does, how it behaves, and when to reach for it.

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

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

Schema description coverage is 100%, so the input schema already documents all nine parameters and their purposes. The description adds zero param-level meaning, but because the schema carries the burden, the baseline score of 3 is appropriate.

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

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

The description restates the tool name and title almost verbatim: 'Search Yellowpages with the documented /yellowpages-search endpoint.' It names a verb and resource, but provides no semantic differentiation from sibling tools such as businesses_search, google_maps_search, or yelp_reviews. It reads as a tautology rather than a substantive definition.

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

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

The description offers no guidance on when to use this tool versus alternatives. It does not mention use cases, exclusions, prerequisites, or how it relates to the many sibling search and data tools. The only implicit signal is that it searches Yellowpages, which is too weak to support correct tool selection.

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

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

With no annotations provided, the description carries the full behavioral burden. 'Fetch' implies a read operation, but it does not disclose pagination behavior, async execution, webhook handling, rate limits, or side effects of parameters like execution_mode and async. This is a substantial gap for a non-trivial scraping 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 a single concise, front-loaded sentence with no wasted words. The phrase 'with the documented /yelp-reviews endpoint' adds little beyond the tool name, but overall the length is appropriate for the little content it conveys.

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

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

Given the tool's complexity — nine parameters, async/sync execution modes, pagination cursor, webhook, and a cutoff parameter — a one-sentence description is not enough for an agent to select and invoke it correctly. The output schema may cover return values, but usage context and behavioral expectations remain largely unexplained.

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

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

Schema description coverage is 100%, so the schema already documents all nine parameters. The description adds no parameter-level meaning, but per the rubric the baseline is 3 when the schema covers the parameters; the description neither helps nor harms.

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

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

The description clearly states the verb 'Fetch' and the resource 'Yelp reviews', and the endpoint reference reinforces the operation. It does not explicitly contrast itself with review tools for other platforms, but the resource name makes the core purpose unambiguous.

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

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

The description gives no guidance on when to use this tool versus siblings like tripadvisor_reviews, google_maps_reviews, or trustpilot_reviews. There are no usage conditions, prerequisites, or exclusion criteria, so an agent must infer applicability solely from the tool name.

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