bing_content_submission_quota

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered, yet the description adds non-obvious semantics: the empty_response label meaning 'silence, not a measurement' and the prohibition on reporting it as 'no problems found'. It also warns to treat untrusted-marked fields as data, not instructions — behavior an agent could not infer elsewhere.

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?

Front-loads the purpose, then usage, then the failure-mode caveat, then the safety instruction — a logical order with no filler. It is denser and slightly longer than minimal, but every sentence carries distinct 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?

With no output schema, the description steps in to explain return-value semantics (the empty_response label) and the untrusted-data handling, which is exactly what an agent needs to interpret results correctly. Nothing material is missing for a single-parameter read tool.

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 0%, so the description carries the burden, but it only implies a single-site scope via 'for one site today' rather than describing site_url's expected format or constraints. It adds marginal meaning over the bare string parameter without fully compensating for the coverage gap.

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 precise verb ('Read'), an exact resource ('how much content submission Bing still allows'), and scope ('for one site today'). It explicitly names the sibling it is not ('Do not use this for ordinary URL-submission quota; call bing_submission_quota'), so an agent can distinguish it from bing_submission_quota without opening either 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?

Explicit trigger ('Use when the user asks whether a page body can still be submitted') and explicit exclusion routing to an alternative ('Do not use this for ordinary URL-submission quota; call bing_submission_quota'). Nothing about when to select this tool is left to inference.

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