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

Annotations already indicate non-read-only and non-idempotent, but the description adds crucial details: it downloads the file (authenticated), never overwrites (appends -1, -2 suffix), and returns the path. This goes beyond annotations to describe side effects and file handling.

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

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

Three sentences, front-loaded with the core purpose, and each sentence adds value: main action, download behavior, precondition, and file naming. No fluff or redundancy.

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

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

For a tool with 3 parameters and no output schema, the description covers the key aspects: what it does, when it works, how files are named, and the return value (path). It omits error cases but states the precondition clearly. With siblings present, it is sufficiently distinct and complete.

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

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

Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds little about parameters beyond mentioning the full column layout (which is output-related). Baseline 3 is appropriate since the schema already handles 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 action ('Save a finished scrape as a spreadsheet file on this computer and return its path') with a clear resource and output. It distinguishes itself from siblings like get_results by explaining it downloads the file rather than returning a link.

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 a clear precondition ('Only works once the scrape status is done') and explains the download behavior. However, it does not explicitly mention alternatives or when not to use it, but the context implies it is for file retrieval versus data access.

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?

Beyond the annotations (readOnlyHint, openWorldHint), the description reveals significant behavior: partial rows are visible while the scrape runs, long pages are trimmed with trimmed: true, rows include only populated fields, and _status transitions found -> extracted -> enriched. No contradiction with 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 key purpose is front-loaded in the first sentence, and each following sentence adds needed operational detail: when it works, trimming/paging, row shape, status progression, and the download_export alternative. There is no filler.

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

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

Despite having no output schema, the description compensates by defining the row format (one business per row, populated fields only), the field vocabulary, the _status lifecycle, and pagination mechanics (nextOffset, hasMore, trimmed). This gives an agent enough to call and interpret results.

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

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

Schema description coverage is 100%, and each parameter already has a clear description for limit, detail, fields, offset, scrapeId, and withEmailOnly. The description reinforces paging with nextOffset and mentions compact JSON, but it adds no parameter-level meaning beyond what the schema already provides, so baseline 3 applies.

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

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

The description opens with a specific verb and resource: 'Read a scrape's rows as compact JSON, one page at a time,' which clearly distinguishes this from siblings like start_scrape and wait_for_scrape. It also explicitly contrasts itself with download_export for spreadsheet-download use cases, so the tool's role is unmistakable.

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 says exactly when to use this tool — to page through scrape rows, both while running and after completion — and when not to: 'For a spreadsheet of every row use download_export instead of paging through thousands of rows.' It also gives the paging pattern (offset/nextOffset until hasMore is false).

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 it read-only and open-world; the description adds meaningful behavioral context: it is live/non-blocking, and it enumerates what the status payload contains (queued/running/done/error, progress, resultCount, credits, coverage). It does not describe error behavior or response structure, but for a read-only status tool the annotations lower the bar.

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

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

Two sentences with no filler: the first defines the tool's output in a compact list, and the second states the usage rule and alternative. The key verb and resource appear first.

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

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

With no output schema, the description compensates by listing the main return categories (status, progress, resultCount, credits, coverage). It also gives the core use case and alternative. It is slightly thin on exact response shape and error conditions, but the tool is simple enough that this is near-complete.

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

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

Schema description coverage is 100%, so the schema fully documents scrapeId and includeSearches. The description adds no parameter-specific detail beyond implying the scrape is identified by ID; the baseline of 3 applies because the schema carries the 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?

States a specific verb 'Get' plus a precise resource, 'one scrape's live status', and enumerates the fields returned (status, progress, resultCount, credits, coverage). It distinguishes itself from wait_for_scrape by naming it as the blocking alternative, so an agent can tell them apart.

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

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

Explicitly says when to use it: 'Use it to check on a scrape without waiting', and names the alternative wait_for_scrape for blocking. This is a clear usage rule and a sibling differentiation. It doesn't mention get_results/list_scrapes, but the tool's status-only scope makes those exclusions implicit.

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

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

Annotations already signal readOnlyHint=true and openWorldHint=true. The description adds useful behavioral context beyond annotations: account scoping, newest-first ordering, the 200-item retention cap, and the specific fields returned. This is meaningful disclosure for a read-only list tool.

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

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

Two sentences with no filler. The first sentence front-loads the resource, ordering, bound, and returned fields; the second gives practical use cases. Every clause adds value.

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

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

For a list tool with no output schema, the description covers the essential return fields and the account/retention context. Combined with fully documented parameters and safety annotations, an agent has enough to invoke it correctly. It could mention pagination edges, but the 200 cap makes this a minor gap.

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

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

Schema description coverage is 100%, so both `limit` and `status` are already documented. The description adds little parameter-specific detail beyond reinforcing the 200 cap and status relevance. Baseline 3 is appropriate when the schema carries the parameter documentation burden.

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: 'List this account's most recent scrapes.' It adds ordering ('newest first'), a retention bound ('latest 200'), and names the exact fields returned. This clearly distinguishes it from sibling tools like start_scrape, get_results, and download_export.

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 gives two use cases: finding a scrape id and reusing a finished scrape 'instead of paying for the same search again,' which points to when listing is preferable to starting a new scrape. It does not enumerate all sibling alternatives, but the guidance is concrete 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?

Beyond annotations (readOnly=false, non-idempotent), the description discloses substantial behavioral details: credit reservation and refund mechanics, charges per delivered business, the categories x locations cross-product limit, the 12-scrapes-per-5-minutes rate limit, and the requirement to confirm large scrapes with the user. This is exactly the kind of side-effect and cost context the annotations do not provide.

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

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

The description is long but densely informative and front-loaded with the core purpose and examples. Cost behavior, rate limits, and next-step workflow are all essential for safely invoking this expensive operation, and no sentence is wasted.

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

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

Given the tool's complexity, credit costs, and absence of an output schema, the description is complete enough for an agent to invoke it correctly. It covers what it returns (scrape id, status queued), what will happen later (results/download), rate limits, credit accounting, and confirmation requirements.

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

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

Schema coverage is 100%, and each parameter already has a detailed description explaining meaning, constraints, and cross-field relationships. The description text reinforces the cross-product and credit behavior, but does not add significant new parameter semantics beyond the schema.

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

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

The description names a specific action (start a Hubertino scrape), the resource (Google Maps businesses), and the output (lead rows with name, category, phone, website, email, and more). It clearly distinguishes itself from sibling tools like wait_for_scrape, get_results, and download_export by stating that this tool begins the scrape and returns an id.

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 gives concrete use-case examples like "find dentists in Austin with emails" and "build a list of plumbers in Leeds". It also explains the follow-up sequence: returns scrape id immediately, then call wait_for_scrape, then get_results or download_export, which tells the agent exactly when and how to use this tool relative to its 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description doesn't need to restate safety. It adds value by disclosing that the tool sends MCP progress notifications when requested, and it mentions the practical client-abort behavior. This goes beyond the schema and annotations, giving the agent useful 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 description is three sentences with no fluff. It front-loads the core behavior, then gives usage guidance, and finishes with a timeout recommendation. Every sentence earns its place, and the structure is efficient.

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

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

Given the tool's simplicity (no output schema, three well-documented parameters), the description covers the essential loop behavior, timeout handling, progress notifications, and client constraints. It references get_scrape for the return format, which is acceptable since get_scrape is a sibling. It doesn't detail error cases or failure handling, but those are likely covered by the referenced get_scrape behavior, so the description is adequate for correct invocation.

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

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

The input schema provides 100% coverage of all three parameters with clear descriptions. The description adds extra context not in the schema, specifically about timeoutSeconds: it warns that many clients abort after ~60 seconds and advises keeping the default unless the client supports more. This practical guidance helps the agent choose parameter values correctly, exceeding the schema's baseline.

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

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

The description clearly states a specific action: 'Poll a scrape until it is done (or failed), or until timeoutSeconds passes, then return its status like get_scrape.' It names the resource (scrape) and the result (status), and differentiates from get_scrape by using the waiting/polling behavior. This leaves no ambiguity about what the 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?

The description provides clear context for when to use the tool (to wait for completion) and gives a practical loop strategy ('If it is still running when the time is up, just call wait_for_scrape again'). It also warns about client timeout limits and advises keeping the default timeout. However, it doesn't explicitly contrast with get_scrape as a non-waiting alternative, though the 'like get_scrape' reference implicitly distinguishes them.

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