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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuinely non-obvious context: that the Chrome extension is what actually executes indexing clicks, which changes how an agent should interpret a completed or failed request_indexing call. It says nothing about auth requirements or whether quota counts are cached/stale.

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?

One dense sentence covering the key returned fields, with the most decision-relevant facts (plan, budget, extension online) listed first. It is slightly elliptical — a fragment rather than a sentence with a verb — but no clause is padding.

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 appropriately enumerates the returned data points, including the Google quota comparison an agent needs for planning. The main gap is the absence of any guidance on when to call it relative to other 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?

Schema coverage is 100% and the single optional 'tz' parameter is fully documented in the schema. The description never mentions time-zone handling, so it adds nothing over the schema here; 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 enumerates the specific resources the tool reports on: plan, key permissions and hourly budget, Chrome extension online state, and today's per-site request counts vs Google's daily quota. That is concrete and clearly distinct from action-oriented siblings like request_indexing or cancel_indexing_request. It omits an explicit verb ('returns'/'reports'), but the scope 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?

There is no stated when-to-use or when-not-to-use guidance, and no sibling is named. The clause about the extension performing 'every Request indexing click' hints that this tool explains why request_indexing may fail, but the agent must infer that routing itself.

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 flag destructiveHint=true and idempotentHint=true; the description adds the crucial nuance that only the queued request is destroyed while the page itself stays in IndexMachine, which meaningfully reframes the destructive flag. It also discloses the state precondition (closed requests are not cancelable). It does not describe the error behavior or return value on success.

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, zero filler, with the primary effect front-loaded and the precondition and side-effect note following in priority order.

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 mutation with rich annotations and no output schema, the description covers effect, scope, and precondition adequately. The only meaningful gap is what happens when the request is closed (error vs no-op), which matters for a cancel operation.

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

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

Only one parameter and schema coverage is 100%, so the schema already documents request_id fully; baseline 3 applies. The description adds nothing about the id format or how to obtain a valid request id (e.g., from list_indexing_requests).

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 (cancel) and resource (indexing request) plus the precise mechanism: it removes the request from the queue so the extension never performs it. That is clearly separable from the sibling read tools (get_indexing_request, list_indexing_requests) and from request_indexing.

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 a concrete applicability condition — only open requests can be canceled, a closed request cannot — which tells the agent when the call will fail. It stops short of naming alternatives (e.g., use get_indexing_request to check state first), so not a full when/when-not/alternatives treatment.

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 cover safety (readOnly, non-destructive, openWorld), and the description adds substantive behavior on top: the per-site live-check quota, that indexed is null rather than false when never inspected, and that a refused live check degrades to stored state with a warning. Quota and graceful-degradation details are exactly the kind of context an agent cannot get from 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?

Purpose is front-loaded in the first clause, then the three return components and the live/fallback caveats follow in a tight block with no filler. The first sentence is long and colon-chained, which costs a little readability, but every clause carries 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?

There is no output schema, so the description carries the burden of describing returns — and it does: index status, stored inspection timing, open-request ETA, live result, null-when-unknown, and the warning path. For a 2-parameter read tool this leaves nothing an agent needs 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 coverage is 100%, so the baseline is 3, and the description still adds meaning: live means 'ask Google now' and carries a concrete quota cost, and the null semantics of the indexed result are clarified. The url parameter itself is only restated, but the live flag's tradeoff is genuinely enriched.

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 — whether a URL of the user's site is indexed on Google and as of when — and enumerates what is returned (stored inspection, open request ETA, optional live check). It is not tautological and an agent can tell it apart from list_pages or get_indexing_request, though it never names those siblings 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?

Usage is largely implied: the agent infers you call this to learn a URL's index status, and the description explains the live flag costs 1 of 50 daily checks, which is a real decision cue. However, it never states when to prefer this over get_indexing_request or list_pages, and gives no prerequisites about the URL needing to belong to a Search Console property.

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 cover readOnly, non-destructive, closed-world, so the description's added value is semantic: eta_text applies only while the request is open, and a closed request with status 'requested' means only that the click happened, not that indexing succeeded. That interpretation guidance is genuinely beyond structured fields, though it doesn't address lookup-miss 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 sentences with no filler; the returned-field summary comes first and the check_url disambiguation second. Phrasing like 'once the extension performed it' is terse and assumes some context, but nothing 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?

With one required parameter, no output schema, and annotations covering safety, the description is complete enough: it enumerates the meaningful return concepts and their conditions. Remaining gaps are minor—unnoted behavior for an unknown or stale request_id.

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 request_id parameter, including UUID format and pattern, so the schema does the documentation work. The description adds no syntax or sourcing detail (e.g., where a request_id comes from) beyond that 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 names the resource (one indexing request) and specifies exactly what is returned: status, queue position, and ETA in eta_text while open, plus the Search Console response once performed. This separates it from check_url, which handles post-indexation questions. It doesn't explicitly contrast itself with list_indexing_requests beyond the singular 'One indexing 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?

It routes a related but distinct question explicitly: 'whether Google indexed the page is check_url's answer,' telling the agent not to expect indexation truth from this tool. The condition of use (read a single request, especially an open one or a closed one with status requested) is clear, though no when-not rule or prerequisite is stated outright.

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 destructiveHint=false, so the description is not carrying the safety burden. It nonetheless adds real context beyond them: newest-first ordering, that open requests expose position and ETA, that closed ones expose outcome, and the 90-day retention window for closed requests.

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, no filler, and the key scoping information (ordering, site scope, open vs closed) is packed into the opening clause so an agent learns the shape of the result immediately.

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 does the needed work of describing what each result mode returns (position and ETA, or outcome) plus retention. Pagination mechanics are delegated to the cursor parameter's schema description, which is a reasonable split.

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%, with site, limit and cursor well documented in the schema. The description adds semantics the schema lacks for status, spelling out what 'open' (preparing, queued, served) and 'closed' (outcome) actually contain, which is the one enum without a description.

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

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

States a specific verb and resource (list indexing requests) plus the ordering (newest first) and scope (one site or all). It implicitly contrasts with get_indexing_request by being a listing, but never names the sibling that returns a single 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 open/closed split and the 'one site or all of them' phrasing imply how to use the status and site parameters, but no sentence says when to prefer this over get_indexing_request or how to follow up on a request. Usage is inferable rather than stated.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. Beyond that, the description discloses a real behavioral caveat: 'A status comes from the last stored inspection,' i.e. values may be stale, and it clarifies what not_indexed aggregates. It does not mention pagination behavior or result caps, though the schema covers those.

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?

Very compact and front-loaded: the returned fields come first, then the status caveat and the sibling pointer. The fragment style ('the last crawl and request') is slightly telegraphic and forces some inference, but nothing 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?

For a paginated list tool with no output schema, the description covers the returned fields, the meaning of the status filter, and the staleness caveat. Cursor/limit mechanics are left to the schema, which is acceptable; only a note on result ordering/capping would strengthen 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 coverage is 80%, so the schema already documents q, site, limit and cursor. The description adds meaning for q ('matches part of the URL', i.e. substring not exact) and for the status values, notably the composite not_indexed bucket. Baseline 3 applies given the schema does most of the work.

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 the resource (a site's pages), what is returned (status, Google coverage state, last crawl and request), and the path ordering. The verb is only implied via the title, and there is no explicit scoping contrast with list_sites, so it is clear but not fully self-differentiating.

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 a concrete routing rule away from this tool: 'check_url has a single URL in full,' which tells the agent to use check_url for one-URL deep inspection. It also defines the not_indexed bucket so the agent knows what that filter selects. No when-not guidance against list_sites or list_indexing_requests is given.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing the exact payload shape (five page-count buckets, indexing on/off, billable, IndexNow readiness), which matters since there is no output schema. It omits freshness/pagination but nothing contradicts 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?

One dense, front-loaded sentence that leads with scope and then lists the returned attributes. Every clause carries information, though the run-on parenthetical makes it slightly harder to scan than a bulleted field 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?

With no output schema and no parameters, the description's main job is explaining what comes back, and it does that thoroughly, including the semantic meaning of the billable flag. Minor gaps remain: page-count definitions and whether results are paginated or cached.

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 takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a 0-param tool applies. The description correctly implies the scope is all properties with no filtering options.

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?

Names the resource (every Search Console property connected to IndexMachine) and enumerates the returned fields, which implicitly separates it from list_pages and site_summary. It never states an explicit verb like 'returns' or 'lists' but the resource and scope are 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?

Usage is only implied: needing to see all connected properties. There is a useful forward reference — noting 'billable, which Request indexing needs' — that hints at the request_indexing sibling's prerequisite, but no explicit when-to-use, when-not-to-use, or named alternative such as site_summary.

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 adds substantial behavior beyond the annotations: the extension queues and performs the action later, there is a ~10 requests/site/day limit, eta_text refers to the click not indexing, and confirmation works through elicitation or a refusal plus confirm token. These are exactly the operational details an agent needs.

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

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

The description is front-loaded with the core action and remains information-dense, but it is a long paragraph that could be split or tightened slightly. Most sentences carry necessary behavioral 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 non-idempotent, open-world mutation with no output schema, the description covers the critical unknowns: deferred execution, rate limits, preview behavior, force semantics, and the confirmation flow. Nothing essential to correct invocation appears 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 coverage is 100%, so the baseline is 3, but the description adds meaningful semantics for force (a re-index) and confirm (the token from a refusal that stands in for the user's yes), beyond what the schema descriptions alone state.

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: it queues an indexing request for a URL on one of the user's sites, including URLs not yet part of the site. This clearly distinguishes it from sibling tools like submit_indexnow, check_url, and list_indexing_requests.

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 explains the practical conditions well: preview first, skip already-indexed pages unless force is true, and require user confirmation for re-indexes, non-sitemap URLs, and the last request of the day. It does not explicitly name alternative tools, but the intended 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.

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

The description provides highly valuable behavioral context beyond annotations, including the indexing quota (approx. 10 a day), its reset schedule (midnight Pacific), and the data retention limit of up to 30 days for counts.

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 tool is defined in a single, highly packed sentence that efficiently communicates the breadth of information provided and its scope.

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 single input parameter and high schema coverage, the description is fully complete. It explains not only what data is provided but also the operational constraints, like the quota and time-window limits.

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 schema adequately defines the single 'site' parameter. The description merely confirms the input flexibility (UUID or domain), falling back to the baseline score.

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

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

The description clearly states the function as providing a comprehensive summary ('One site in full') and lists the exact data points returned, such as page counts, quota, and median indexing days.

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?

Although it does not explicitly name siblings, the description defines its scope as a comprehensive summary, which helps the agent distinguish it from granular checks like `list_pages` or individual request checks.

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 well beyond the annotations: it discloses that crawl timing is engine-decided (not guaranteed), that requests do not reach Google, the prerequisite key file, the per-site daily quota, and the full confirmation protocol including the elicitation path and the confirm-token fallback. No contradiction with readOnlyHint=false, openWorldHint=true, idempotentHint=false or destructiveHint=false.

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?

placeholder

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?

placeholder

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?

placeholder

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

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

States a specific verb (notifies engines), the exact resource (up to 100 URLs of one site), the target engines (Bing, Yandex, other IndexNow engines), and explicitly what it does NOT do (does not reach Google). That negative scope cleanly distinguishes it from siblings like request_indexing and check_url.

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 concrete preconditions (IndexNow key file present, verified via indexnow_ready in list_sites) and a usage cap (20 submissions per site per day), which tells the agent when this call is viable. It implies but never explicitly names the alternative for Google coverage, so routing to a sibling is left to inference rather than stated.

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