Send feedback to Search1API

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

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false, so the safety profile is largely covered. The description still adds non-obvious behavior the annotations do not convey: the no-credentials/no-personal-data rule, that reporting is optional, and that it must not block the user's task. It does not say what a submission returns or whether reports are deduplicated server-side, which keeps it below a 5.

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?

Purpose is front-loaded in the first clause, followed by routing rules and then constraints, with no filler sentences. It is dense — four constraint sentences packed into one paragraph — but each carries an operational rule an agent needs, so nothing is wasted.

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?

Five parameters with only one required, 80% schema coverage, and no output schema, so the description need not explain return values. It supplies the purpose, the triggering conditions, the exclusion, privacy limits, and the non-blocking guarantee — everything an agent needs to decide and submit correctly.

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 80%, so the schema already documents model, intent, message and request_id, and the baseline is 3. The description's enumeration of problem types loosely maps onto the category enum (bug, feature_request, docs) but never names the parameter or the enum values, and it does not clarify when request_id is worth supplying. Added meaning beyond the schema is marginal.

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 and resource ("Report a problem with Search1API to its developers") and then enumerates the qualifying problem classes: wrong/empty/incomplete results, unresolved errors, doc mismatches, missing capabilities. This is unmistakably different from the sibling retrieval tools (search, crawl, news, maps), which an agent can rule out without opening any 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?

It gives explicit when-to-use conditions, an explicit when-not ("Do not report normal successful results"), a timing rule ("after you have worked around or abandoned the step"), a granularity rule ("one report per distinct problem"), and a priority constraint ("must not block the user's task"). No plausible ambiguity about whether to invoke this is left.

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