gsc_request_indexing

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

With no annotations, the description carries the full burden and does so admirably. It discloses the BLOCKING nature, pacing (130-180 seconds), quota per property (roughly eleven slots), early-stop on throttle/captcha/signed-out, and details the return structure including error format. This goes well beyond a simple tool summary.

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 yet information-dense. Every sentence adds distinct value: purpose, pacing, alternative tool, quota, call order, return shape, early-stop condition, and error shape. It is structured logically, front-loading the core purpose and moving to caveats and outputs.

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 no output schema, the description compensates by clearly listing the return keys and explaining the early-stop behavior and refusal format. It also covers operational context (quota, pacing, browser profile) that integrates well with sibling tools like gsc_quota and gsc_start_indexing_job. This is a fully specified tool from the agent's perspective.

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 schema has 0% coverage—the description doesn't explain the format of each URL string. However, it does add a meaningful constraint: 'up to five URLs' and the behavioral nuance 'one at a time.' For a single, self-evident parameter named 'urls' this is adequate, but it leaves room for more detail (e.g., URL validation, required protocol).

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-resource pair: 'Submit up to five URLs to Google's Request Indexing.' It further clarifies the method ('through the browser extension in your own signed-in profile') and even distinguishes itself from a sibling tool ('Use gsc_start_indexing_job for anything larger'). This fully clarifies the tool's purpose and 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 description explicitly states when to use this tool vs. the alternative ('Use gsc_start_indexing_job for anything larger') and provides a critical prerequisite ('Call gsc_quota first to see what is spendable; act on spendable_free, not free'). It also implicitly warns about blocking/slowness, setting user expectations.

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