report_site

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

No annotations are provided, so the description carries the full burden. It implies an external side effect ('so the team can improve it') but does not state whether the report is sent off-box, whether it is throttled/deduplicated, whether it is anonymous, or what confirmation the caller gets. The 'real site' qualifier hints at a test-vs-production distinction but is not elaborated.

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-loaded with purpose, then usage triggers, then a compact per-parameter glossary. Every line earns its place, and the parameter block is justified by the 0% schema coverage; there is no filler or repetition.

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?

An output schema exists, so return values need not be described. Combined with the trigger list and complete parameter glossary, the definition is nearly self-sufficient; only the side-effect/telemetry behavior of the report remains unstated for a tool that transmits failure data externally.

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?

With 0% schema description coverage and no enum constraints in the schema, the description fully compensates: it defines site (domain or URL with an example 'reddit.com'), enumerates all eight valid kind values that the schema does not constrain, and clarifies that detail and url are optional with format guidance ('one short line', 'full page URL'). This adds substantial meaning beyond the bare 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 states a specific verb+resource: report a site where takeover failed, with the framing 'so the team can improve it.' It distinguishes itself from siblings by naming check_login_wall, takeover, and handback as the failure sources, making it identifiable as the diagnostic-reporting tool among browser-automation siblings. Slightly odd phrasing ('report a site') keeps it short of a perfect 5.

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 when-to-use triggers are enumerated: 'Call this whenever check_login_wall misses a login, takeover fails to complete, the handback does not trigger, or anything else goes wrong on a real site.' It names the specific sibling tools whose failures should route here, plus a catch-all, leaving nothing to inference.

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