Submit URLs to IndexNow

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

Annotations already declare openWorld, idempotent, non-destructive, non-readOnly. The description adds real behavioral value on top: the authentication prerequisite (a key from INDEXNOW_KEY or indexNowKey in config.json), the requirement that it be served as a text file, and the fact that the file is validated before anything is sent. It omits failure handling and any rate/volume limits beyond the schema's maxItems.

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

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

Three sentences, each load-bearing: purpose first, then the Google exclusion, then the prerequisite. No filler and no restatement of the title.

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 4-parameter tool with no required parameters and no output schema, the description covers the key prerequisite and input modes well. It leaves slight ambiguity about whether urls or sitemapUrl must be supplied (the schema enforces no requirement) and says nothing about what a successful submission returns or how many URLs were accepted.

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% and the description usefully fills the biggest gap: where the key comes from (INDEXNOW_KEY or config.json) and the default key-file location /<key>.txt, which the keyLocation schema field only partially implies. It also clarifies list-vs-sitemap as alternative input modes. The undocumented urls array gains no per-item format guidance beyond the schema's uri format.

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 ('Notifies IndexNow engines ... of new or changed URLs') and names the accepted input shapes (a list or a whole sitemap). It also rules out Google, which is genuinely useful scoping. It does not, however, differentiate itself from the sibling submit_sitemap or bing_submit tools, so an agent must infer the boundary.

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?

'New or changed URLs' clearly frames the trigger context, and 'Google does not use IndexNow' functions as an explicit when-not. It stops short of naming alternatives (submit_sitemap, bing_submit) or stating the exclusivity rule between urls and sitemapUrl.

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