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

Annotations already declare readOnlyHint and openWorldHint, so the description adds complementary context: billing per URL, default response_detail, async/wait behavior, and a strategy recommendation. It also includes legal responsibility, which is extra transparency. It does not repeat annotation info and provides value beyond the structured fields.

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

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

The description is three sentences, front-loads the core purpose and billing, then covers options and legal note. Every sentence earns its place; no filler or repetition of schema fields. It is appropriately sized for the tool's complexity.

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

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

For a tool with 4 parameters, nested objects, and no output schema, the description covers the main usage modes (sync/async), defaults, and legal notes. It does not explicitly describe the return format, but the async/wait semantics and job id mention partially compensate. Given the absence of an output schema, this is reasonably complete, though an explicit return description would push it to 5.

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 adds meaning by noting the default `response_detail=compact` (not in schema), clarifying `async=true` yields a job id, and recommending `strategy=auto` for JS-heavy pages—these details go beyond the schema's basic 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 uses a specific verb+resource+scope: 'Scrape up to 100 URLs in parallel.' It clearly distinguishes from the sibling `metalift_scrape` by emphasizing batch capability, and references paid billing and defaults, making the tool's 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?

Provides clear context on when to use `async=true` (background jobs) and `wait=true` (block with progress), and recommends `strategy=auto` for JS-heavy pages. While it doesn't explicitly name alternatives like `metalift_scrape` for single URLs, the 'up to 100 URLs' phrasing implies the batch use case. The guidance is actionable and helps select appropriate 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?

The description discloses '1+ credits per page' and explains the blocking behavior when wait=true and the job id return when wait=false, adding cost and async context beyond the readOnlyHint annotation. This provides valuable operational details without contradicting the annotations.

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

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

The description is two sentences, efficiently covering purpose, output, cost, and wait behavior. Every sentence carries essential information with no fluff, and the primary action 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 6-parameter tool with no output schema, the description covers the core operational aspects: markdown output, credit cost, wait behavior, and job id reference. It lacks details on the exact structure of the returned markdown, but annotations and full schema coverage fill most gaps, making it sufficient for an agent to 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?

With 100% schema description coverage, the baseline is 3. The description adds meaning for the wait parameter by specifying that wait=false returns a job id for metalift_job_status, which is not in the schema. Other parameters are sufficiently described in the schema.

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

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

The description clearly states the tool 'crawl a site from a seed URL and return markdown for discovered pages,' which uses a specific verb ('crawl') and resource ('site') and distinguishes it from single-page scraping tools. The mention of discovered pages plus the cost per page adds unique functionality compared to 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?

The description provides context about the wait parameter and references metalift_job_status for asynchronous usage, but it does not explicitly state when to choose crawl over alternative tools like metalift_scrape, metalift_sitemap, or metalift_map. Usage is implied rather than clearly differentiated.

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

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

Annotations already declare readOnlyHint=true, and the description adds value by stating it returns human-readable progress and credits charged. This goes beyond the annotation to explain output behavior. There is no contradiction. While it doesn't discuss polling frequency or potential wait times, the description is sufficiently transparent for a read-only status check.

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

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

The description is two sentences, front-loaded with the core action, and every phrase adds value. No filler or repetition. It is efficient and clear, earning a top score.

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

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

Given the tool's simplicity (one required param, no output schema), the description fully captures what it does and what it returns. It mentions the job types (crawl/batch) and output details (progress, credits), making it complete for an agent to correctly select and invoke the tool. The readOnly annotation further contextualizes safety.

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

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

Schema coverage is 100% with the job_id parameter fully documented as 'Job id from metalift_crawl or metalift_batch_scrape.' The description does not add new parameter details, but the schema already provides sufficient context. Baseline 3 is appropriate because the description 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 uses the specific verb 'Poll' and identifies the resource as 'async crawl or batch job status and results.' It clearly distinguishes this tool from siblings like metalift_crawl and metalift_batch_scrape, which initiate jobs rather than check their status. The additional detail about returning 'human-readable progress (pages completed, credits charged)' further clarifies its purpose.

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

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

The description implies usage after launching an async job, mentioning 'async crawl or batch job' which correspond to siblings. However, it lacks explicit exclusions or alternatives (e.g., 'use this after starting a job with metalift_crawl'). Given the clear naming and context, it's a solid 4, missing only explicit 'when-not-to-use' 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?

Annotations already declare readOnlyHint=true, and the description confirms this read operation. It adds that sessions are org-scoped and stored via metalift_seed_session, but it does not disclose behavior such as pagination, ordering, or what fields are returned. This is a modest addition beyond the annotation.

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, front-loaded sentence that includes only essential information: the verb, the resource, and the source. There is no wasted text.

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

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

For a tool with no parameters and a simple listing function, the description is adequate. It specifies the scope ('org-scoped') and source ('stored via metalift_seed_session'), though it does not detail the contents of the returned list. Given the simplicity and annotation support, it is sufficiently complete.

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

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

The tool has zero parameters and an empty schema, so the description has nothing to add. The baseline score for 0 params is 4, which is appropriate here.

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 the specific verb 'List' and identifies the resource as 'org-scoped browser sessions,' clearly distinguishing this from scraping, crawling, and strategy tools. It also references the related seed tool, clarifying its role in the workflow.

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

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

The description provides clear context: this tool lists sessions stored via metalift_seed_session, implying use after seeding or to inspect existing org-scoped sessions. It does not explicitly mention when not to use it or alternatives like list_strategies, but the context is sufficient for typical use.

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

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

The readOnlyHint annotation already declares the non-destructive nature, so the description does not need to repeat that. It adds context by mentioning that the list includes protection levels and credit estimates, which gives an agent an idea of what to expect. However, it doesn't describe the return format or any edge cases, so it's average.

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

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

The description is two sentences long, both of which carry meaningful information: the purpose and the usage context. There is no redundant wording, and the structure is clean and efficient.

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

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

For a simple tool with no parameters and no output schema, the description is reasonably complete. It tells what the tool lists (strategies with protection levels and credit estimates) and when to use it (before scraping unknown protected sites). It does not elaborate on the response format, but this is likely not critical for comprehension.

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

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

There are zero parameters, and the schema is empty, so the description is not required to explain any parameter details. The tool appears to be a simple listing operation. The description does not need to compensate for schema gaps because there are none.

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

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

The description clearly states the tool's function: 'List scrape strategies with protection levels and credit estimates.' The verb 'List' is specific, and the resource 'scrape strategies' is distinct from the sibling tools that perform scraping actions. This differentiates it effectively.

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

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

The description provides a specific use case: 'Use before scraping unknown protected sites.' This is explicit guidance on when to use the tool, though it does not name alternatives or state when not to use it. Still, the context is clear 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?

Annotations already indicate read-only and open-world nature. The description adds useful behavioral details: the credit cost (1 credit), the parsing scope (single page), and the exclusion of full-page content fetching. This goes beyond the annotation signals.

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

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

Two sentences deliver the core purpose, cost, fallback, and a key exclusion. No filler or redundancy.

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

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

For a simple link-extraction tool with read-only annotations and full schema coverage, the description covers the essential aspects: what it does, cost, fallback, and a key limitation. While no output format is specified, the return is implicitly a list of links from the 'discover' wording. It's adequate for an agent to decide and invoke.

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

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

The schema covers all three parameters (url, limit, search) with descriptions, giving 100% coverage. The description adds minimal parameter-specific meaning, only hinting at the page context. Per the baseline rule for high schema coverage, a 3 is appropriate.

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

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

The description clearly states the tool's function: discovering same-origin links by parsing HTML anchors on a single page. This specific verb+resource distinguishes it from siblings like metalift_scrape or metalift_crawl, and the fallback note references metalift_sitemap 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 explicitly identifies a conditional usage scenario: 'Fallback when metalift_sitemap is unavailable.' It also clarifies what the tool does not do ('Does not fetch full page content'), which guides when not to use it.

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

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

Annotations already indicate readOnlyHint and openWorldHint, and the description adds useful behavioral context: default credit cost, response_detail default, e-commerce auto-routing, and a compliance responsibility warning. It doesn't describe error behavior or exact output structure, but the added context is meaningful.

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

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

Four sentences, each carrying actionable information. It is front-loaded with the purpose and has no filler, making it easy to scan and process.

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

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

With 13 parameters and no output schema, the description doesn't spell out the exact response envelope, but the detailed parameter schema and the response_detail parameter description fill most of that gap. It's sufficiently complete for a competent agent to use correctly.

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

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

Input schema covers 100% of parameters, but the description enriches key ones by explaining the default static article path, response_detail=compact as default, and when to use strategy=auto. This goes beyond the schema entries.

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

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

The description opens with a specific action: 'Scrape a single URL into markdown, HTML, or text.' This clearly identifies the tool's purpose and distinguishes it from sibling tools like metalift_batch_scrape, metalift_crawl, and metalift_sitemap by emphasizing the single-URL scope.

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

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

It provides clear context on when to use the default static path, e-commerce routing, and strategy=auto for WAF/SPA pages. However, it doesn't explicitly state when to prefer siblings like batch_scrape or crawl over 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?

Annotations already indicate readOnlyHint=false and destructiveHint=false, so the write nature is covered. The description adds valuable context beyond annotations: it explains why storage_state is preferred (preserves cookies + localStorage for fingerprint-coherent replay) and that the session is org-scoped. It does not mention overwrite behavior or TTL, but this is not a contradiction and the additional context is meaningful.

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

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

The description is two sentences long, front-loaded with the main action and scope, followed by concise preference/fallback guidance. Every sentence earns its place with no fluff or repetition of schema 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 6 parameters, nested objects, and no output schema, the description covers the core usage scenario well: what to provide (storage_state or cookie_header+user_agent) and why. It misses a few operational details like TTL handling and what the tool returns, but for a credential-seeding tool, the essential context 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 50%, and the description compensates by explicitly explaining the relationship between storage_state, cookie_header, and user_agent ('Prefer... Fallback...'). It adds semantics not in the schema for those parameters. However, it does not explain ttl_hours or the cookies object, which remain undocumented in both schema and description, preventing a 5.

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

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

The description uses a specific verb ('Store') and clearly states the resource ('browser session credentials') and scope ('for a domain (org-scoped)'). It also distinguishes itself from siblings by explaining its role in enabling later scrapes with a unified browser session, differentiating it from tools like metalift_scrape or metalift_warm_session.

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 usage guidance by stating a preference ('Prefer full Playwright storage_state JSON') and a fallback ('Fallback: cookie_header + user_agent from DevTools'). It implies when to use it (before scrapes that need authenticated sessions) but doesn't explicitly state when not to use it or list alternative tools, so it falls short of a full 5.

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

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

Annotations already mark the tool as read-only; the description adds meaningful behavior: discovery from robots.txt or /sitemap.xml, following sitemap indexes, returning optional lastmod/changefreq/priority, and a credit cost. This goes beyond annotation basics.

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

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

Three concise sentences, each adding value: purpose, behavior/return details, and cost/usage preference. No wasted words.

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

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

The description covers purpose, behavior, cost, and usage preference, and gives a sense of return content (page URLs with optional metadata). It lacks details on 'limit' behavior, but the schema provides min/max and the overall picture is adequate for a tool with moderate 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 75%. The description does not add parameter-specific details beyond what the schema provides. The 'limit' parameter lacks a schema description and is not addressed in the text, but the schema covers the other three parameters adequately.

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

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

The description clearly states the tool fetches XML sitemap URLs, with a specific verb and resource. It explicitly differentiates from metalift_map by recommending this tool for the site's published URL 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?

Provides explicit usage guidance: 'Prefer this over metalift_map when you need the site's published URL list.' This names an alternative and gives a clear condition for use.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, and the description adds behavioral context not present in annotations: it mentions the action of collecting cookies (side effect) and the failure mode on strict WAFs. It also notes a credit cost of 15, which is useful operational behavior. It doesn't detail the full session storage mechanics but provides enough beyond the structured fields.

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

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

The description is two sentences, front-loaded with the core purpose and then a usage condition and caveat. Every sentence carries useful information with zero waste 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 tool with 5 parameters and no output schema, the description gives key context: when to use it, its limitation with WAFs, and its cost. It does not explain what the tool returns (e.g., session ID or job status), but given the annotations and schema richness, this is still a fairly complete description. Slight gap on output behavior prevents a 5.

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

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

Schema description coverage is 100%, meaning all five parameters already have descriptions. The tool description does not add any parameter-specific guidance, but it does not need to because the schema covers them. Baseline 3 is appropriate when schema does the heavy lifting.

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

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

The description uses a specific verb and resource: 'Automated browser warmup to collect cookies for later scrapes'. It clearly distinguishes itself from the sibling manual tool 'metalift_seed_session' by stating when it should be used instead. This is a clear and differentiated purpose.

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

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

The description explicitly provides a usage condition: 'Use when manual metalift_seed_session is not possible'. It also states a limitation: 'often fails on strict WAFs', which serves as a caution. This gives both when to use and when to avoid, plus names the alternative.

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 declare readOnlyHint=true and openWorldHint=true, and the description adds meaningful behavioral context: it returns only snippets (not full content), costs credits, and prohibits auto-scraping. This goes beyond the annotations, covering cost and usage policy, though it doesn't discuss error handling or rate limits.

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

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

The description is only two sentences but conveys purpose, output, cost, limitations, and usage guidance without redundancy. It is front-loaded with the core action and immediately informative.

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 search tool with high schema coverage and readOnly annotations, the description is fully complete: it states the return fields, cost, snippet-only behavior, and when to use the alternative scrape tool. No output schema exists, but the description covers the necessary return information.

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

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

The schema provides complete descriptions for all three parameters (query, language, categories), resulting in 100% schema coverage. The description adds no additional parameter-specific meaning, so it rests at the baseline of 3.

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

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

The description clearly states the tool's action ('Search the web') and its output ('return up to 10 SERP results'), including specific fields. It also differentiates from siblings by noting it returns snippets only and pointing to metalift_scrape for full content, eliminating ambiguity.

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

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

Explicit guidance is provided: 'Answer simple questions from snippets; do not auto-scrape' and 'Call metalift_scrape separately only when full page content is required.' This tells the agent exactly when to use this tool versus the alternative, plus cost implications (2 credits per search).

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