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

Goes well beyond the annotations: discloses that up to five engines and a time window are inferred from wording, up to 10 results are returned ranked by relevance, the response includes the inferred intent and any failed engines, and each call costs 5 credits. The failed-engines and cost disclosures are operationally important and appear nowhere in the structured fields.

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?

Three sentences, each carrying distinct payload: what it does, what it returns, and what it costs versus the alternative. The disambiguating condition is front-loaded in the first sentence and nothing is redundant.

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?

Despite an output schema existing, the description still usefully previews the result shape (results, intent, failed engines) and adds the credit cost, which no structured field carries. For a single-parameter, read-only tool this leaves no meaningful gap.

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 one parameter at 100% schema coverage, the schema already explains that naming a platform or period steers engine and window selection. The description corroborates this and adds that up to five engines are chosen automatically, though it introduces no new syntax or constraints (e.g., the 500-character limit stays in the 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?

States a specific verb and resource ("Search several sources at once") with the distinguishing scope: natural-language federated search across up to five engines. It names the sibling tool `search` and the condition that separates them, so an agent can disambiguate 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 routing guidance in both directions: use this "when the right engine is unclear" and "use search when you already know the engine." It pairs that with a concrete cost tradeoff (5 credits per call), which is exactly the kind of information needed to choose between the two.

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

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

Annotations already declare readOnly, openWorld, non-idempotent, and non-destructive behavior. The description adds that only public pages are read and that the output is the title, URL, and main content as text, but it does not mention limitations such as JavaScript rendering, paywalls, authentication, or rate limits.

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 two sentences, front-loads the action, and immediately explains the practical benefit of reading the full page rather than a snippet. There is no redundant or filler text.

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 one-parameter read tool with rich annotations and an output schema, the description covers purpose, source, and output nature adequately. It leaves a small gap around sibling differentiation and runtime limitations, but nothing essential for a basic call is missing.

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 100%, and the schema already describes the URL as a link from the user or search results. The description restates that sourcing context but adds no new syntax, format, or constraint details for the parameter.

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 gives a specific verb and resource: reading a public web page. It contrasts the result with a search snippet, which helps distinguish it from the search tool, but it does not explicitly name or rule out close siblings such as render_results.

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 clearly states when this tool applies: when the user supplies a URL or when a URL comes from search results. It does not explicitly say when not to use it or which sibling handles alternative cases, so it falls short of full routing guidance.

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

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

Annotations already declare readOnly/openWorld/non-destructive, so the description's credit cost (20 credits per started task regardless of page count), the ~45 second wait, and the task_id resumption path are genuine additions. The async polling pattern is the single most important behavioral trait for correct invocation and it is spelled out. It stops short of stating crawl-concurrency or failure-mode details beyond "the URLs that failed."

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 mechanics, cost, timing, resumption, and alternatives — a sensible priority order. Some clauses overlap the schema text ("returns ... with title, URL, and Markdown text") but the density is justified for a tool with async and billing semantics.

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 6-parameter, billed, potentially asynchronous crawl with an output schema, the description covers everything needed to call it correctly: selection criteria, cost model, latency, resumption, and sibling disambiguation. Return-value detail is correctly compressed since an output schema exists.

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 100%, so baseline is 3; the description still adds value by linking parameters into a workflow — that path rules gate which URLs are counted against max_pages, that price is flat regardless of max_pages, and that task_id overrides the other arguments. It doesn't restate the include_paths wildcard syntax, which it correctly leaves to the 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 opening sentence names a specific verb and resource ("Read many pages of one website in a single task") and scopes it to a site-section use case, which an agent can immediately distinguish from a single-page fetch or a bare URL listing. It also names the sibling tools it is not.

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 states the selecting condition ("when the user needs content from across a site rather than one page") and explicitly routes to alternatives: "Use crawl for a single page and sitemap for a list of URLs without their content." When-not guidance is present, not just when.

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

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

Beyond the read-only and open-world annotations, it discloses one-page pagination, the 20-place cap, conditionally available fields, and a three-credit charge per page regardless of result count. These details establish important output-scope and cost expectations before invocation.

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?

Three sentences front-load the purpose and usage triggers, then cover result scope, cost, and alternatives. The returned-field list is dense but relevant to tool selection, and there is no filler or redundant explanation.

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?

Together with the fully documented input schema, output schema, and safety annotations, the description supplies the triggers, scope, cost, pagination behavior, and sibling routing needed for correct selection and invocation. Details such as the location requirement for later pages and coordinate bounds are appropriately handled by the schema.

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 100%, and the schema already documents query behavior, pagination, location requirements, result limits, and per-page pricing. The description reinforces page and cost semantics but adds little new parameter-specific syntax or constraint information, making the high-coverage baseline of 3 appropriate.

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 opening sentence gives a specific verb and resource—finding local businesses and places on Google Maps—and identifies concrete use cases such as nearby options and lists with contact details. The final clause also distinguishes it from search for webpages and crawl for business-site content.

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 explicitly names three user intents that should trigger the tool: asking where something is, wanting nearby options, or needing businesses with contact details. It also routes webpage discovery to search and business-website reading to crawl, providing clear sibling alternatives.

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

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

Annotations already declare readOnly, openWorld, non-idempotent, non-destructive, so the safety profile is covered. The description adds that results are citable and may include extracted full text, but it omits the credit cost implied by crawl_results and any note that results are external/unverified content. Useful addition, not rich behavioral context.

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?

Two sentences, zero waste: the first covers when to use it, the second covers what comes back. Front-loaded with the trigger condition.

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 an output schema present and full schema coverage, the description needs only to establish purpose, trigger, and general shape of results, all of which it does. The only meaningful gap is that cost-bearing behavior (crawl_results consuming extra credits) is left entirely to the schema.

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 description coverage is 100% and every parameter — including time_range, max_results, and the include/exclude site lists — is documented in the schema, so the baseline of 3 applies. The description adds no parameter-level guidance beyond what the schema already states.

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?

Names a specific verb and resource ("Search current news") and scopes it to recent events, announcements, and coverage, which distinguishes it from the generic 'search' and 'crawl' siblings in spirit. It does not explicitly name a sibling or state the boundary, so it stops short of a 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?

The opening clause gives a clear trigger condition (user asks about recent events, announcements, or coverage), which is exactly the context an agent needs. It offers no exclusions or named alternatives (e.g., when to prefer 'search' or 'trending' instead), so it is clear context without routing.

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

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

Goes well beyond the annotations: it discloses the UI-vs-text fallback that depends on host capability, that no search credits are consumed, that ordering is preserved as passed, and the integrity constraint against inventing URLs or titles. The annotations only cover the read-only/idempotent profile, so this content is genuinely additive.

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 the action and its fallback, and every sentence contributes a distinct constraint. The opening sentence is somewhat dense with its host-capability conditional, but nothing is redundant padding.

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 rendering needn't be explained, and the description covers the remaining risks for this tool type: when to call it, what it must not do, and the integrity constraints on input data. Nothing an agent needs to invoke it correctly is missing.

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 description coverage is 100%, so the schema already documents both parameters and the nested result fields. The description still adds useful semantics by stating results are passed "in the desired order" (order is meaningful, not incidental) and reinforcing the no-fabrication rule for url and title.

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 specific verb and resource ("Present already retrieved source results as source cards") plus the fallback behavior ("complete readable text list otherwise"). This is clearly distinguishable from search/news/crawl siblings, and the tool's role as a pure presentation layer is unambiguous.

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?

Gives explicit positive triggers ("user wants to browse sources or a visual list helps the task") and explicit negatives ("Do not call for intermediate research results or when a text answer is sufficient"). It also enumerates what it does not do ("Does not search, crawl, fetch URLs, verify sources, or consume search credits"), which routes the agent to the right sibling for those needs.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint=false, and destructiveHint=false, so the safety and side-effect profile is covered before the description is read. The description adds modest context ("live web", citable results, crawl for full text) but says nothing about credit costs, rate limits, or per-engine reliability — the credit note appears only in the crawl_results param description.

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?

Three sentences, no padding: the capability and engine scope come first, then the usage trigger, then the return shape and follow-up action. The long engine list in sentence one is dense but functional, and nothing repeats what the annotations already state.

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 an output schema present and 100% param coverage, the description only needs to convey purpose, trigger, and routing, all of which it does. Minor gaps remain around pagination caveats (only some engines paginate) and cost, but those live in the schema and are not required in the 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?

Schema description coverage is 100%, so every parameter already carries its own explanation, establishing a baseline of 3. The description's engine enumeration overlaps the search_service enum and is actually less complete (omits yandex, imdb, bingcn, grokipedia), adding no syntax or selection heuristics beyond the 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?

States a specific verb and resource ("Search the live web") and enumerates the engine scope, including specialized platforms like GitHub, Reddit, and arXiv. It also explicitly hands off full-page reading to the sibling tool crawl, so the agent can tell this apart from crawl 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?

"Use when the user needs current information, sources, or research" gives a clear triggering condition, and the mention of crawl establishes the read-in-full alternative. It stops short of naming when-not-to-use cases or contrasting with siblings like news or trending, which likely overlap for time-sensitive queries.

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

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.

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

The annotations already declare readOnly, openWorld, non-idempotent and non-destructive, so the safety profile is carried structurally. The description adds that results are absolute URLs restricted to public links and are meant to be fed into crawl, but it says nothing about result volume, same-domain vs cross-domain scope, or why the operation is non-idempotent, so added value is modest.

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?

Two sentences, zero filler, with the trigger condition front-loaded before the return-shape and follow-up guidance. Every clause earns its place.

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 an output schema present, the description rightly omits return-value detail and focuses on when to call and what to do next. The remaining gap is scope: it does not say whether results are limited to the given domain or how the search sibling differs, which matters for a link-discovery 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?

There is a single parameter with 100% schema description coverage, so the schema already explains it fully. The description only echoes the page-or-domain distinction found in the schema and adds no format, normalization, or redirect-handling detail, so the baseline of 3 is appropriate.

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?

"Discover related public links from a page or domain" names a specific verb (discover) and resource (links), scoping the input to a single site. It implicitly contrasts with the crawl sibling by casting sitemap as the discovery step and crawl as the reader, so an agent can tell the two apart.

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 trigger condition is explicit: "when the user wants to explore a site's structure or available pages," and it names crawl as the natural next tool. It stops short of stating when not to use it (e.g., versus the search sibling for cross-site discovery), so it is clear context without exclusions.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true and idempotentHint=false, so the safety and network profile is covered upstream. The description adds genuine value by disclosing the return shape (title, URL, short description when available), but adds nothing on freshness, rate limits, or result ordering beyond 'top of the list'.

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?

Two tight sentences with no filler; the action and scope lead, and the return-shape note follows. Every clause earns its place.

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?

Output schema exists so return values need not be detailed, and annotations cover safety and openness; the description correctly avoids duplicating those. Only small gaps remain around what 'trending' means in terms of time window or ranking.

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 description coverage is 100%, so both parameters are fully documented with defaults, bounds, and enum values in the schema itself. The description merely restates the two sources and adds no format or usage nuance beyond it, so baseline 3 applies.

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 specific verb ('List') and resource ('currently trending repositories or stories') plus the two sources, so the agent knows exactly what comes back. It stops short of explicitly contrasting with the sibling 'news' tool, which is the closest potential overlap.

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?

Provides a clear triggering condition ('when the user asks what is popular now'), which is more than most definitions offer. It gives no explicit when-not guidance or named alternative for non-trending lookups, leaving that inference to the agent.

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