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

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds meaningful behavioral context beyond those: it works before credentials exist and returns remediation steps instead of failing. This gives the agent a clear model of the tool's failure semantics 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 compact and front-loaded, with the diagnosis scope first and usage conditions following. Each sentence contributes useful guidance, though the final negative instruction could arguably be merged with earlier guidance without much loss.

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 diagnostic tool with no output schema, this description covers the key decision factors: when to call it, when not to, what it checks, why it is unique, and what it returns. There is no missing information an agent would need to invoke or route to 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 description does not need to explain parameter meaning. The baseline for zero-parameter tools is 4, and the description appropriately focuses on behavior rather than inventing parameter details.

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

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

The description uses a specific verb ('Diagnose') and resource ('this server's configuration'), then enumerates exactly what it checks: credential presence, validity against Google, and property reach. It clearly differentiates from sibling tools by noting it is the only tool that works before credentials are configured.

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 explicit call conditions: after an authentication/permission error, during setup, or when the user asks why it is not working. It also states a concrete negative case—do not use it as a warm-up—and names list_sites as the correct alternative for proving 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?

The description goes well beyond the readOnlyHint/openWorldHint annotations by disclosing concrete behaviors: the comparison window defaults to an equal-length preceding period, yearOverYear uses 364 days to keep weekdays aligned, rows are matched on dimension values, results are sorted by absolute click change, and rows present in only one period are reported with zeroes. This is exactly the kind of behavioral detail an agent needs to interpret results correctly.

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 dense but efficient: three paragraphs each serve a distinct purpose — what the tool does, how the comparison period is selected, and how rows are matched and sorted. There is no filler or repetition of annotation information, and the most important 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?

For a read-only comparison tool with no output schema, the description adequately covers input semantics, period selection, row matching, sorting, and treatment of missing rows. An agent can understand what the tool returns and how to configure it without needing additional context.

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

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

Schema description coverage is 92%, so the schema already documents most parameters well. The description adds meaningful semantics beyond the schema: the meaning of the default comparison period, why yearOverYear uses 364 days, and the caution that using the date dimension makes comparisons meaningless. This improves parameter understanding without repeating 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 a specific verb ('Compare') and resource ('search-analytics query') and clearly states the return value ('per-row and total deltas'), which differentiates it from the single-period sibling query_search_analytics. The title and description align with the tool name, and the use-case list makes its purpose 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?

The description gives explicit use cases ('is traffic up or down', 'what lost rankings', 'which pages grew') and explains the default comparison window and the three comparison modes. It does not explicitly name the alternative single-period tool or state when not to use it, but the context is clear enough that an agent can select it appropriately.

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 destructiveHint=true and readOnlyHint=false, but the description adds valuable context by specifying that destruction is limited to loss of submission history. It also clarifies open-world effects: the sitemap file remains on the site and indexed URLs are unaffected. This exceeds what the annotations alone provide and does not contradict 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 description is three sentences with no filler. The first sentence states the core action, while the second and third add critical caveats that prevent misuse. Each sentence 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?

For a simple two-parameter tool with fully documented schema, safety annotations, and no output schema, the description covers all essential behavioral context: what the tool does, what it does not do, and the precise destructive impact. There is no meaningful gap for an agent 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 input schema already documents both parameters with full 100% coverage, including examples and distinctions for siteUrl. The description adds little parameter-specific meaning beyond restating the general context of a 'property' and a 'sitemap', so it does not compensate meaningfully beyond the schema 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 states a specific action ('Remove a sitemap from a property') and then clarifies the actual behavior: it unsubmits from Search Console rather than deleting the file or indexed URLs. This distinguishes it clearly from sibling tools like submit_sitemap or list_sitemaps.

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

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

The description gives clear context by explaining what the tool does and does not do: it unsubmits a sitemap, does not delete the site file, and does not remove indexed URLs. This acts as an implicit usage boundary, though it does not explicitly name alternative sibling tools or provide a direct 'use when...' condition.

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 provide readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context beyond annotations by explaining the tool returns the authenticated account's permission level and is appropriate for pre-flight access confirmation.

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 with no filler. The primary action is front-loaded, and the usage guidance and alternative are clearly separated without 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 tool with one fully documented parameter, read-only annotations, and no output schema, the description provides sufficient context: what is fetched, what information is returned, when to use it, and when to prefer an alternative. Nothing essential 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 parameter is fully documented in the input schema. The description adds no additional parameter-level details, so the baseline score of 3 is appropriate; the schema carries the semantic load.

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'), names the exact resource ('a single Search Console property'), and states the returned information (permission level). It also distinguishes itself from the sibling list_sites by emphasizing it returns the permission level for one property.

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 recommends when to use this tool ('useful to confirm access before a longer sequence of calls') and names the more efficient alternative ('list_sites is usually more efficient'). This gives an agent clear decision criteria.

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 is consistent with readOnlyHint=true, framing the operation as a fetch. It goes beyond annotations by adding the important caveat that indexed counts are under-reported by Google and should be treated as a lower bound. This gives the agent useful reliability context that the annotations alone 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 two sentences with no wasted words. The first sentence front-loads the operation and the returned fields, and the second adds a high-value caveat. Every sentence 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?

With no output schema, the description carries the burden of describing return values, and it does so by listing the key fields returned and adding the data-reliability caveat. It may not describe error behavior or exact response formatting, but for a simple read-only fetch tool with rich schema descriptions, 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?

Schema description coverage is 100% and both parameters are already richly documented in the schema: siteUrl explains URL-prefix vs domain properties, and feedpath gives an example and requires a path from list_sitemaps. The description adds little to parameter understanding beyond referencing 'per content type,' which relates more to the output than the inputs.

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 details') and resource ('a single submitted sitemap'), then enumerates exactly what information is returned: submission/download times, processing state, type, and submitted vs indexed URL counts. This clearly distinguishes it from siblings like list_sitemaps (listing), submit_sitemap (creating), and delete_sitemap (removing).

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 'single submitted sitemap' implies this is for retrieving details about one already-submitted sitemap, and the schema requires feedpath to match a path from list_sitemaps. However, the description itself does not explicitly state when to use this tool instead of alternatives or mention any exclusions, leaving the agent to infer routing from sibling names.

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 readOnlyHint and openWorldHint annotations, the description discloses important operational behavior: the rough quota, that results describe the indexed version only, that it cannot run the live test offered in the UI, and that the inspected URL must belong to the property. It also tells the agent which field to read first when diagnosing.

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, all information-dense and free of filler. The most distinguishing information is front-loaded, followed by the use case, quota caveat, and limitation. Every sentence 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?

Even without an output schema, the description names the critical return field (indexStatusResult.coverageState), gives example values, lists the categories of results, and covers quota, scoping, and the live-test limitation. This is sufficient context for an agent to invoke the tool correctly and interpret the result.

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

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

Schema description coverage is 100%, so the baseline applies: the schema already documents siteUrl, inspectionUrl, and languageCode. The description adds one useful constraint ('The URL must belong to the property being inspected') but does not significantly extend parameter-level meaning beyond the schema.

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

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

The description opens with a specific verb and resource: 'Inspect one URL as Google sees it,' and enumerates the concrete result areas (coverage state, robots.txt, crawl time, canonicals, sitemaps, AMP, mobile usability, rich results). The phrase 'one URL' distinguishes it from the sibling inspect_urls without needing to open the schema.

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

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

The description gives an explicit use case: 'This is the tool for "why is this page not indexed" questions,' and adds quota-based sampling guidance. It does not name alternatives or state when not to use it, but the intended 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 adds valuable behavioral context beyond the annotations: concurrent execution, per-URL failure handling rather than whole-batch abortion, and quota consumption of roughly 2000/day per property. This is exactly the kind of operational behavior an agent needs to know.

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 reasonably concise and front-loaded with the most important facts: batch size, concurrency, output shape, and usage examples. The second paragraph adds valuable failure and quota details without excessive 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?

The description covers the core invocation requirements, return shape at a high level, failure behavior, and quota implications. It does not enumerate exact response fields, but for a batch inspection tool with a clear purpose and well-described schema, this is sufficient.

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

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

Schema description coverage is 100%, so the parameters are already well documented. The description reinforces the 25-URL limit and mentions that all URLs must belong to the property, but it does not add meaning beyond the schema's existing field 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 clearly states the tool inspects up to 25 URLs in one call, runs concurrently, and returns a per-URL summary plus coverage-state counts. It is immediately distinguishable from the singular sibling `inspect_url` by its batch orientation.

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

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

The description gives concrete usage context: auditing sets of pages, such as top landing pages from `query_search_analytics` or URLs from a sitemap. It does not explicitly state when to prefer `inspect_url` over this tool, but the batch purpose is clear enough.

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

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

The readOnlyHint and openWorldHint annotations already cover the safety and external-state aspects. The description adds meaningful behavioral detail by stating exactly what the tool returns—timestamps, error/warning counts, and per-content-type counts—and how sitemapIndex changes the result set.

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 redundant filler, and the primary purpose is front-loaded. The second sentence earns its place by explaining the optional parameter behavior without repeating 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?

For a read-only listing tool with two parameters and no output schema, the description provides enough information about return contents and the special sitemapIndex behavior. Annotations cover safety, and the schema covers parameter formats, 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?

Schema description coverage is 100% for both parameters, so the schema carries the parameter documentation burden. The description largely restates the sitemapIndex behavior already in the schema, adding only the phrase 'child sitemaps' and 'top-level submissions' as clarifying vocabulary.

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: 'List the sitemaps submitted for a property,' and further specifies the returned metadata (timestamps, counts, per-content-type values). It also clarifies the sitemapIndex variant, which distinctively separates top-level listing from child-sitemap listing.

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 clearly states the main use case and explicitly explains when to pass sitemapIndex to list child sitemaps instead of top-level submissions. It does not name alternative sibling tools like get_sitemap or submit_sitemap, but the context is clear and the parameter guidance is practical.

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, so the read-only nature is covered. The description adds useful behavioral context about the output including permission levels and downstream dependency on siteUrl. It does not discuss pagination or potential response size, but openWorldHint partially covers the open-ended nature of the result.

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 a clear purpose statement and high-value usage guidance without redundancy. The critical 'call this first' instruction is front-loaded and the permission details are compactly organized.

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

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

For a zero-parameter, read-only listing tool with no output schema, the description fully explains what is returned (properties with permission levels), why it matters (siteUrl needed by other tools), and how to interpret permission levels. Nothing critical is missing for an agent to invoke it correctly.

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

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

The tool has zero parameters, so the baseline is 4 and there is no parameter semantics burden on the description. The description adds no parameter detail, but none is needed.

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 ('List') and resource ('every Search Console property the authenticated account can access'), and it clarifies that the result includes permission levels. This clearly distinguishes it from sibling tools like get_site, which presumably targets a single property.

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 instructs the agent to 'Call this first in any session' and explains that the returned siteUrl strings are required by every other tool. It also maps permission levels to capabilities, giving concrete guidance on what actions are possible for each role.

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 and openWorldHint, and the description adds substantial behavioral detail beyond that: data finality lag, query-level privacy filtering, row limits, the cap on combining page and query, sorted output, and omission of empty rows. No contradiction exists between the description and 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 front-loaded with the core purpose, then gives grouping and return behavior, then uses a compact bulleted list for the most important planning caveats. Every sentence carries useful information and the structure makes the caveats scannable.

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

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

For an 11-parameter tool with no output schema, the description covers the key behavioral gaps an agent needs before calling it: what is returned, how default totals work, data freshness, privacy filtering, expected row counts, and pagination. The remaining parameter details are already well documented in the input schema.

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 genuine meaning beyond the schema: sorting by clicks descending, only returning rows with data, the privacy-filtering effect of grouping by query, the harder cap when combining page and query, and pagination guidance for rowLimit/startRow. It does not cover every parameter, but the schema already does.

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: querying clicks, impressions, CTR, and average position from the Search Console Performance report. It also names the available dimensions and distinguishes its role as the core traffic and ranking analysis tool, making its purpose immediately identifiable relative 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 gives clear usage context: how to get totals, how to group, how to paginate, and why to use lastDays for a safe data window. It does not explicitly name alternatives like compare_search_analytics or state when not to use this tool, so it stops 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?

Adds value beyond annotations by explaining that resubmission is a safe nudge, that the sitemap must already be reachable, and that no data is returned on success. It also directs the caller to get_sitemap for status, which is useful behavioral context not present in 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?

Three focused sentences with no wasted words. The core action is front-loaded, and each sentence contributes essential information: what the tool does, when resubmission is useful, prerequisites, and expected return behavior.

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 two-parameter tool with no output schema, the description fully covers what an agent needs: prerequisites, behavior, and follow-up action. It even preempts confusion about the empty response by telling the agent to check get_sitemap afterward.

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 strong parameter descriptions containing examples and format guidance. The description adds further meaning by specifying that the sitemap must be reachable and must live under the property, which clarifies feedpath requirements 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?

States a specific action (submit or resubmit), the resource (sitemap), and the target context (a property). It clearly differentiates from siblings like get_sitemap, list_sitemaps, and delete_sitemap by naming the operation and its resubmission role.

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 for when to use it, including resubmitting after content changes and the prerequisites that the sitemap must be reachable and under the property. It does not explicitly exclude alternatives like list_sitemaps or get_sitemap, but the guidance is sufficient for correct selection.

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