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

Annotations already indicate this is not read-only and not destructive, but the description adds essential context: it spends credits (~0.1 per URL), results arrive asynchronously within minutes, and the task does not submit URLs to Google. This goes well beyond what annotations convey.

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 tight sentences: purpose first, then cost and async timing, then the critical exclusion and alternative. Every sentence earns its place with no redundancy or filler.

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

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

With an output schema present, return values do not need explaining in the description. The description covers cost, async polling workflow, and the sibling distinction, so an agent has everything necessary 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?

Schema description coverage is 100%: urls and title are both documented, including URL format, min/max items, and max length. The description adds no extra parameter-level meaning, so the schema-carrying baseline of 3 is appropriate.

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

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

States a specific verb and resource: 'Create an index-check task that reports, per URL, whether Google currently has it in the index (indexed / unindexed).' It clearly identifies the outcome and distinguishes itself from the sibling submit_urls_for_indexing by explicitly saying it does not submit anything.

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 routing: 'use submit_urls_for_indexing for that' for submission, and gives the exact follow-up workflow: 'poll get_task, then read get_task_links.' This tells the agent when to use this tool and what to do after invoking 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 mark it read-only, idempotent, and non-destructive; the description adds value by explaining what the call actually performs—a ping, a feature report, and API key validation. This extra context helps the agent interpret success or failure. No contradiction with the annotations exists.

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 compact sentences with no filler. The main action is front-loaded, and the parenthetical list of reported features is an efficient way to convey additional detail.

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

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

For a parameterless health-check tool with rich annotations and an output schema, the description covers the essential contract: what is pinged, what is reported, and that API key validation occurs. Return format details are handled by the output schema, so nothing critical is missing.

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

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

The input schema has zero parameters, so there is nothing parameter-related the description needs to add. With no parameters to document, the baseline of 4 is appropriate, and the description does not introduce any ambiguity.

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 ('Ping') and names the exact resource ('Rapid Indexer API'), then enumerates the specific outputs: version, enabled feature flags, and API key validity. This clearly distinguishes it from siblings like check_index_status, which is about URL indexing status rather than service health.

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 conveys a clear use case: verify that the Rapid Indexer API is reachable, learn which features are enabled, and confirm the configured API key works before relying on other indexer workflows. It does not explicitly name alternatives or exclusions, but the context is strong enough that an agent can judge when to call 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?

Goes beyond the annotations by disclosing immediate credit spend at traffic rates, the need for explicit user confirmation, and the human-like browsing behavior. These are non-obvious operational effects that annotations alone cannot convey.

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 short, high-signal sentences. The action is front-loaded, followed by the credit warning, the confirmation requirement, and the validation source. No filler or redundant elaboration.

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 21-parameter creation tool, the rich schema plus output schema cover the inputs and return shape, while the description covers the critical operational context: cost, user confirmation, and search-engine value lookup. Nothing essential is missing 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?

Schema description coverage is 90%, so the schema already documents nearly all parameters. The description adds little beyond restating the default search engine and pointing to list_search_engines, which the schema also mentions. 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?

States a specific mechanism (send visitors who search keywords, find the target URL, click it, browse) that clearly distinguishes this from the sibling create_traffic_campaign. The title and description both make the CTR campaign'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?

Gives useful procedural guidance: confirm with the user before creating, and use list_search_engines for valid search_engine values. However, it does not explicitly say when to choose this over create_traffic_campaign or when not to use it, leaving that 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?

Discloses non-obvious side effects not present in annotations: immediate credit consumption, a 1,000/day pacing cap, and the async return of a task id requiring polling. This goes well beyond the structured hints (readOnly=false, idempotent=false) and gives the agent the cost and confirmation guardrails it needs.

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

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

Five short sentences, each adding distinct value: main action, cost warning, pacing limit, user confirmation, and follow-up polling. The most important information is front-loaded and 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?

Given 16 parameters, the description plus a rich schema covers the full create-and-monitor workflow, including cost, limit, confirmation, and status retrieval. It is complete enough for an agent to call the tool safely and know what to do next; the only minor gap is not mentioning the CTR-campaign alternative.

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 88%, so the schema carries most parameter meaning; the description adds little beyond naming configurable dimensions and restating the daily cap already encoded in visitors' description. It does not clarify the one undocumented parameter (video_chance), 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?

Description opens with a concrete action ('Send AI-driven, human-like visitors to a URL') and names configurable dimensions (geo, device, referrer, on-page behavior). It clearly identifies the resource and outcome, though it does not explicitly contrast with sibling create_ctr_campaign, so it stops short of full 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?

Provides strong operational context: credits are spent immediately, check get_pricing, confirm with the user before creating, and poll get_task for status. It does not explicitly state when to choose this over create_ctr_campaign, but the workflow guidance is clear enough for an agent to act.

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, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read-only operation. The description's 'Does not create anything' repeats that safety profile rather than adding new behavioral context such as rate limits or account-checking side effects. With strong annotation coverage, a 3 is appropriate.

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?

A single, front-loaded sentence that states the core function, the timing ('before submitting'), and the side-effect guarantee. Every clause earns its place with zero redundancy or filler.

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

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

For a read-only estimation tool with 3 parameters (1 required) and a full output schema, the description fully covers what the tool does, when to use it, and what it does not do. Nothing an agent needs to call it correctly is missing.

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 documents all three parameters (vip, type, url_count) with descriptions. The tool description adds no parameter-specific meaning beyond stating the task types ('indexing or index-check'), which maps to the existing type enum. Baseline 3 is correct.

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: 'Estimate the credit and USD cost of an indexing or index-check task before submitting it, and whether the account balance covers it.' This clearly distinguishes it from sibling tools like submit_urls_for_indexing and check_index_status, and the closing 'Does not create anything' reinforces the non-mutating scope.

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

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

The phrase 'before submitting it' provides clear contextual timing for when to use this tool, and 'Does not create anything' implies it is a safe pre-flight step rather than the actual submission tool. However, it does not explicitly name alternatives like get_pricing or exclude cases where estimation is unnecessary, so it falls short of the top score.

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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful context by specifying the account is 'authenticated' and enumerating the returned fields, giving the agent a clear model of what the call will reveal without overstating 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?

Two short sentences with no filler. The return fields are front-loaded, followed immediately by the practical use case. Every word contributes to the agent's understanding of what the tool does and when to call it.

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, read-only account lookup with an output schema available, the description fully covers purpose, expected fields, and typical usage. There are no hidden inputs, side effects, or pitfalls that need disclosure. Nothing an agent needs to correctly invoke this tool is missing.

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 there is nothing for the description to explain about inputs. The description focuses on output fields and usage intent, which is appropriate. The baseline of 4 applies here because no parameter documentation burden exists.

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 ('Return'), identifies the resource ('authenticated Rapid Indexer account'), and enumerates the exact fields returned (id, email, credits balance, created date). This clearly distinguishes it from siblings like get_pricing or estimate_cost, which address costs rather than account state.

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 clear usage cue: 'Use it to check credits before creating tasks.' This gives an agent a concrete trigger for invoking the tool. It does not explicitly name alternatives or exclusions, but the context is sufficient for this simple read-only account 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 establish readOnly, idempotent, open-world, and non-destructive behavior. The description adds useful context by emphasizing 'live' and 'currently enabled,' signaling that the returned pricing and feature flags are dynamic rather than static. This goes beyond the structured annotations without contradicting them.

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 entire description is a single front-loaded sentence that states the core action first and then itemizes the return contents. There is no filler, repetition, or unnecessary detail.

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

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

For a parameterless read-only pricing tool with rich annotations and an output schema, the description covers everything needed: what the tool returns, that it is live rather than cached, and the dynamic availability flags. No missing prerequisites or usage conditions are apparent.

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 baseline is 4 and the description does not need to explain parameter semantics. Schema coverage is effectively 100% because there are no properties to document.

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 ('Return') and identifies a clear resource ('live credit costs') with an explicit list of included values. It clearly conveys what the tool does, but it does not explicitly differentiate itself from sibling estimate_cost, which could plausibly overlap.

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

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

No guidance is given on when to use get_pricing versus alternatives like estimate_cost or get_account. The intended context is implied by the tool name and contents, but there is no explicit when-to-use or when-not-to-use statement.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds valuable behavioral context: it refreshes the status from the provider (implying a network call) and returns progress counts. This goes beyond the annotations and helps the agent understand side effects and latency.

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 waste. The first sentence states the core action and the refresh behavior; the second states the return value and usage. Key information is front-loaded, and every clause 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 tool is simple with one parameter, and the output schema is present, so return values are already documented. The description covers the refresh behavior and the polling use case. It doesn't mention error cases (e.g., task not found), but for a read-only, idempotent tool this is a minor gap. Overall it is complete enough for an agent to call 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 input schema has 100% coverage, with a clear description for task_id referencing list_tasks or create_* results. The tool description adds no additional parameter information beyond that, so the baseline of 3 is appropriate. The description does not need to restate what the schema already explains.

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 'Fetch' and resource 'one task', clearly distinguishing it from list_tasks (which returns many tasks). It also mentions refreshing status, which sets it apart from a simple cache read. Siblings like get_task_links are clearly different, so an agent can select this tool without ambiguity.

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

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

The description provides an explicit usage context: 'Poll this after creating a task.' This tells the agent when to use it. It doesn't name alternatives or exclusions, but the 'one task' scope and the presence of siblings like list_tasks make the intended usage clear. Slight deduction for not explicitly stating when not to use it (e.g., for listing).

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, idempotentHint, and destructiveHint=false. The description adds value by stating that a summary count is always included and that pagination is supported via limit/offset, which are not covered by the annotations. No contradictions 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?

Two sentences with zero waste. The main action is front-loaded, followed by filtering and pagination details, and the summary-count behavior. Every sentence contributes essential information.

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

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

Given the output schema exists and annotations cover safety, the description covers purpose, filtering, pagination, and the summary count. It is complete for a read-only tool, though it lacks explicit routing to alternatives, which is minor given the clarity of the purpose.

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 75% (three of four parameters have descriptions). The description clarifies the purpose of limit/offset (pagination) and status (filter), adding meaning beyond the schema. It does not add detail for task_id, but the schema already explains its origin. This is more than the baseline 3 for high 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 returns per-URL statuses for indexing or index-check tasks, with a specific verb ('Return') and resource ('each URL'). It distinguishes itself from siblings like get_task (which likely returns task metadata) and check_index_status (which may check overall status), though it doesn't name them 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 implies usage for tasks needing per-URL details and mentions pagination for large tasks, but it does not explicitly compare to alternatives like get_task or check_index_status. There is no 'use this instead of X' guidance, leaving the agent to infer when this tool is the right 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering safety and side effects. The description adds context beyond these by linking the returned data to a specific parameter in create_ctr_campaign, which helps the agent understand the data's purpose. This adds value without contradicting 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?

A single sentence with no filler. The purpose is front-loaded, and every word contributes. It is appropriately sized for a zero-parameter, output-schema-backed tool.

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

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

The output schema exists, so return format is already documented. The description covers the only missing piece: what the returned values represent (valid search_engine options for a specific campaign type). An agent has everything needed 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 tool has zero parameters, so the schema is trivially complete and the description need not elaborate on parameter meanings. Per the rubric, 0 params sets a baseline of 4; the description does not need to add anything and does not.

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 ('Return') and names the resource ('search engines and marketplaces') with a clear linkage to a sibling tool's parameter ('accepted by create_ctr_campaign.search_engine'). This instantly distinguishes it from all other tools, which either fetch data or create campaigns. An agent knows exactly what this tool provides.

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 its usage: before calling create_ctr_campaign, an agent should call this tool to get valid values for the search_engine parameter. However, it does not explicitly state 'use this when you need the allowed values' or mention any alternatives. Since there is no other listing tool among the siblings, the implicit context is sufficient, but a more explicit 'when to use' would push it to 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral specifics beyond the schema: newest-first ordering and per-link indexed/unindexed/pending/error counts, which help the agent understand what results to expect.

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 deliver the core action, ordering, output counts, filters, and intended use with no filler. The most important selection-relevant information 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?

Given the low complexity, the full annotation safety profile, and the presence of an output schema, the description covers everything an agent needs to select and invoke this tool correctly: what it lists, how it orders results, what counts are included, and how to filter.

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%, with type and status already described in the schema. The description restates 'filter by type or status' but adds no new meaning for those parameters, and it does not compensate for the undocumented page and per_page parameters beyond what their names and defaults imply.

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

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

The description clearly states the action (list), the resource (the account's tasks), ordering (newest first), and key output characteristics (per-link counts). It also distinguishes itself from siblings like get_task and get_task_links by framing collection-level listing with counts and the explicit purpose 'find task ids.'

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 identifies a use case ('Use it to find task ids') and mentions available filters by type/status. It does not explicitly name when not to use it or direct the agent to alternatives like get_task for single-task details, but the sibling context makes the distinction reasonably clear.

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

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

Discloses immediate credit spending, approximate costs, queue start times, drip-feed spreading behavior, returned task id, polling follow-ups, and that Google makes the final decision. This adds substantial behavioral context beyond 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 a compact six-sentence paragraph with no filler; it front-loads the core purpose and immediately warns about credit spending. It is dense but every sentence contributes useful behavior or 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?

Covers prerequisites (estimate_cost), side effects (credit spend), follow-up (get_task/get_task_links), and outcome uncertainty (Google decides). The only notable gap is that the description defaults to Google and does not mention the bing engine option, though the schema covers 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 schema already documents all parameters. The description adds some reinforcement around drip_feed and costs, but does not provide new syntactic or semantic parameter details beyond the schema.

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

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

The description states a specific verb and resource: 'Create an indexing task' and explains the mechanism (signals Googlebot to crawl URLs). It clearly differentiates this submission action from sibling tools like check_index_status or get_task.

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 tells the agent to run estimate_cost first and confirm with the user for large batches, and explains standard vs VIP queue behavior and drip_feed. It does not explicitly contrast with check_index_status, but the usage context is clear.

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