gsc_quota

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

With no annotations provided, the description carries the full burden—and it excels. It discloses that the tool is read-only and local, explains the exact computation of spendable_free with a worked example, clarifies the semantics of next_free_at, and defines the 'binding' field. The description even warns about acting on spendable_free rather than free, a critical behavioral nuance that prevents misuse.

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 long but front-loaded with the core purpose. It uses clear headers for each budget type and flows logically from general to specific details. Every sentence carries essential information (e.g., the free vs. spendable_free distinction, the clamp arithmetic, the inspection limits). It is not excessively verbose for the complexity it covers, though it could be tightened slightly.

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 tool with zero parameters, no annotations, and a rich output schema, the description fully covers all contextual aspects: data source, safety profile, empty-store behavior, exact field semantics, edge cases, and the meaning of 'binding'. The return values are exhaustively documented, making the output schema redundant. This is a complete description.

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 the baseline is 4. The description adds no parameter syntax (none needed) but instead thoroughly explains the returned data structure, which is the semantic content the agent needs. This is appropriate given the empty 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 first sentence clearly states the tool's purpose: 'Report Request-Indexing and URL Inspection budget for every property the store currently knows about.' The verb 'Report' plus the specific resources (Request-Indexing and URL Inspection budget) distinguishes it from sibling tools like gsc_check_status, which spends these budgets, and gsc_performance, which deals with analytics data.

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 strong usage context: it is local-only, makes no API call, requires no OAuth, and is safe to call at any time, including before signing in. It also explains the empty-store case. However, it does not explicitly state when NOT to use this tool (e.g., 'if you need live quota data from Search Console, use gsc_check_status instead'), though the comparison to gsc_check_status implies this.

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