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

With no annotations, the description carries the burden and discloses substantial behavior: sequential engine attempts, possible Cloud overlap, 1 credit cost, isError responses, retry_after handling, blocked-engine fallback, and 400/no-charge for unsupported parameters. However, “return the first result set that succeeds” sits awkwardly against the schema’s merge=true default, which returns one list from every successful engine.

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 dense but front-loaded, with purpose first and then operational details. It could be better structured into return/error/cost sections, but most sentences carry useful information for a complex tool.

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 17-parameter tool with no annotations and no output schema, the description supplies return JSON shape plus error, retry, credit, and failed-engine context. The main gap is the ambiguous/conflicting aggregation behavior around first successful result versus the schema’s merge default.

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 all 17 parameters. The description reinforces the engines ordering concept and return shape, but does not add meaningful semantics for most parameters such as merge, dedupe, filter, extract, or start beyond what the schema provides.

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 and behavior: try engines in a given order and return the first successful result set, with a concrete engines example. It also distinguishes this tool from fast_search by explaining when engine order matters.

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 usage guidance: use as a resilient default when you prefer one engine but need a fallback, and use fast_search when order does not matter. The alternative is named with the condition that selects it.

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?

Since there are no annotations, the description carries the full burden of transparency. It successfully discloses critical behaviors: handling failure within the batch (one URL failure doesn't halt the process), the complete structure of the return value (results and meta), and the impact of length limits (truncation metadata).

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 definition is highly efficient. It front-loads the scope and primary use case and then dedicates the rest of the text to describing essential operational guarantees (failure handling, billing, output structure) without any fluff.

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?

Given that the tool is complex (8 parameters) and lacks formal output/annotation schemas, the description is exceptionally complete. It details input limits, operational guarantees, and the resulting data structure needed for an agent to predict the response.

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 description adds crucial contextual meaning beyond the schema definitions. It explains practical implications, such as the effect of `clean` (when NOT to use it), the operational difference between `mode` values, and how `maxChars` leads to truncation metadata.

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 tool clearly defines its purpose (Extract LLM-ready content) and immediately differentiates itself from its sibling tools (like standard 'extract') by defining its batch operation and primary use case.

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 provides explicit usage guidance: 'Prefer this over repeated extract calls when grounding an answer in several pages.' This clearly sets the context for when to use batch_extract versus its sequential alternative.

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?

Since no annotations exist, the description carries the full burden of disclosure. It provides excellent transparency regarding behavioral traits like content truncation (`maxChars`), failure modes (logins/bot walls), and operational costs (credit usage).

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 definition is highly dense but well-ordered, following a logical flow: primary action, return data, operational limits, failure modes, and cloud billing. It maximizes information density while remaining coherent.

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?

Given the complexity and the absence of an output schema, the description is exceptionally complete. It defines the entire lifecycle of the tool, from successful return structure to operational costs and error handling.

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?

Although the schema coverage is 100%, the description adds significant value by detailing the expected output structure (url, markdown, text, etc.), defining the default limit (20,000 chars), and explaining the functionality of features like truncation.

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 tool clearly states its purpose is to fetch one URL and return its main content. It distinguishes itself from its sibling, batch_extract, by specifying it operates on a single URL.

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 definition provides explicit usage guidelines, advising the use of batch_extract for multiple pages. It also instructs users on what to try (mode rendered) when faced with failure conditions (logins, bot walls).

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?

With no annotations, the description carries the full burden and does so well: it discloses engine selection by health/latency, credit cost, return structure, error shape, retry behavior on 429/503, handling of blocked engines, and that unsupported parameters return 400 without charge. These are behavioral traits an agent would otherwise have to discover empirically.

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 front-loaded with purpose and alternatives, then compactly covers return shape, cost, and error handling. For a 17-parameter tool with no annotations, every sentence earns its place and there is no filler.

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?

No output schema and no annotations exist, so the description must explain returns and error behavior, and it does: it names the result fields, pagination fields, meta fields, credit cost, and retry/error cases. Given the tool's complexity, nothing essential is missing for correct invocation.

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 carries the parameter semantics. The description adds useful return and error context but does not add per-parameter guidance beyond what the schema provides, such as pagination interaction with start or limit. Baseline 3 is appropriate when the schema does the heavy lifting.

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: it returns one web result set and does so from the engine with the best recent health and latency. It explicitly distinguishes itself from sibling tools by naming search and any_search and explaining the engine-selection difference. An agent can identify the tool's role without opening the 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 states the intended use case, quick lookups where the engine doesn't matter, and names both alternatives with the conditions that select them: search to pick the engine, any_search to set a fallback order. This is explicit routing among siblings rather than implied usage.

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?

No annotations are provided, so the description carries the full burden, and it does useful work: it declares the operation read-only and free, and discloses the self-hosted failure mode. However, it says nothing about the error shape, whether a first call in a session has no lastResponse, or any rate/refresh behavior, leaving some invocation-risk questions unanswered.

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?

Every sentence earns its place: purpose and return shape first, then usage guidance, then the self-hosted caveat last. There is no redundant restatement of the title.

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 and no annotations, the description supplies both the return fields and the safety profile itself, which is exactly what an agent needs to decide to call it and interpret the result. The zero-parameter schema leaves nothing else to document.

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 tool takes zero parameters, so there is no parameter meaning to convey and the baseline of 4 applies. The description correctly implies parameter-free invocation rather than suggesting any input is expected.

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 names a specific resource (the OpenSERP Cloud account behind OPENSERP_API_KEY) and enumerates exactly what is returned: plan, credits_remaining, and lastResponse fields (request_id, credits used, engine). It is clearly distinguishable from the search/extract siblings, which consume credits rather than report them.

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 guidance ('check the balance before a large batch or to see what a call cost') and states a when-not-to-use condition (self-hosted mode has no credits and returns an error). No alternative tool could serve this purpose, so no routing gap remains.

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?

With no annotations, the description carries the full burden and does so: it lists the return fields, discloses that cloud cost scales with returned images, describes the error envelope (isError with status, code, retry_after), and explains engine-blocking failure modes and remediation. This is unusually complete behavioral disclosure for a search/mutation-free tool.

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 what the tool does, then outputs, then the alternative tool, then cost, then error handling. Every sentence (return shape, cost, retry, 400 unbilled) carries operational information; there is no filler.

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?

No output schema exists, and the description compensates by enumerating the JSON result fields and pagination. Combined with cost and error semantics for a 12-parameter tool, an agent has everything needed to call it correctly and interpret failures.

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 the schema already documents engine, limit/start paging, date, site, and format in more detail than the description. The description adds only the generic notion of engine choice and pagination, so it neither compensates for nor improves on the structured data.

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 images'), scopes it to a single chosen engine, and explicitly names the sibling mega_image as the multi-engine alternative. An agent can distinguish it from the other search siblings without reading 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?

Gives a clear routing rule ('Use mega_image to combine several engines') plus concrete recovery guidance: wait retry_after on 429/503, switch engines on CAPTCHA/502/503, and note that unsupported parameters return 400 unbilled. It stops short of explicit when-not-to-use guidance relative to web `search`/`any_search`, relying on the name for that split.

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?

With no annotations present, the description carries the full load and delivers the key traits: 'Read-only and free' declares both the safety profile and the cost model, and 'open means it is failing, skip it' pre-interprets a status value the agent would otherwise misread. It omits auth/prerequisite conditions and whether results are cached, so it is strong but not exhaustive.

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 purpose is front-loaded in the first sentence and the diagnostic use case lands last, which is the right ordering. Four sentences for a zero-param tool is slightly dense with backend-specific field lists, but every clause conveys real 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?

No output schema exists, and the description compensates by naming the concrete return fields for both self-hosted and cloud modes along with their semantics. For a zero-parameter read-only diagnostic tool this leaves no meaningful gap for an agent deciding whether to call it.

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 tool takes zero parameters, so the baseline is 4; there is nothing to misinterpret and the description correctly implies no arguments are needed.

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?

Specific verb+resource ('List the engines this OpenSERP backend can use') with scope limited to engine health rather than content, which cleanly separates it from the sibling search/extract tools. It goes further and enumerates the differing payload per deployment mode (initialized/circuit_state vs. web/image support, status, latency).

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 an explicit triggering condition ('Call it when searches keep failing') and a follow-up action ('pick a healthy engine for search'). It stops short of naming a specific sibling tool (e.g., any_search vs. fast_search) or stating when not to call it, so it is clear context without full alternative 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?

No annotations exist, yet the description covers the full behavioral envelope: credit costs per mode, cloud-specific behavior, error shape (isError with status, code, retry_after), 429/503 backoff instructions, blocked-engine fallback, and the fact that unsupported params return 400 uncharged. It also discloses the hard constraint that balanced mode only serves the first page.

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 purpose and the sibling alternative, then packs operational details into dense clauses. It is information-dense rather than padded, though the run-on semicolon chaining makes some of the error/cost guidance harder to scan.

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 15-parameter tool with no output schema it covers selection, modes, cost, errors and retry behavior thoroughly. The only gap is that return-shape documentation is delegated to 'Output fields match image_search', requiring a cross-reference to a sibling.

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 the schema already explains mode, start offsets per engine, dedupe, merge, limit and format in detail. The description mostly restates the mode semantics and adds only the balanced/first-page constraint, so it does little beyond the schema baseline.

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 images on several engines and merge them into one list') plus the default mode and that each result keeps source engine and rank. It explicitly contrasts with image_search for single-engine use, so an agent can distinguish it from all siblings.

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 an explicit selection condition ('use it when one engine gives too few or too similar images') and names the alternative ('use image_search for a single engine'). It also codifies mode choice: balanced for merged first page, any/fast when one engine succeeding suffices.

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?

With no annotations, the description carries the full burden and does substantial work: billing is per engine returning results, balanced mode only serves page 1, unsupported params return 400 uncharged, and 429/503 require waiting on retry_after. It stops short of describing engine-failure semantics beyond 'try another engine,' but the safety/cost profile is well disclosed.

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 and the key constraint (slower and costlier) are front-loaded, and later sentences cover return shape, billing, and errors efficiently. It is dense but nearly every clause carries actionable information; only the enumeration of result fields is slightly list-heavy.

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 an 18-parameter tool with no annotations and no output schema, the description is complete enough: it documents the JSON return shape, pagination behavior, billing model, and error protocol. An agent has what it needs to call this correctly and interpret failures.

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 already 100%, so the baseline is 3. The description adds value beyond the schema by explaining the balanced/any/fast mode trade-offs and the consequence of merging versus not merging, rather than merely restating field names.

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?

Opens with a specific verb and resource: 'Query several engines in parallel and merge their web results into one list.' It also states what each result retains (source engine and rank), which distinguishes it from plain search and any_search.

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?

Explicitly names when to use it (compare engines, check cross-engine rank, widen research coverage) and the trade-off (slower, costs more than one engine). It also routes the agent elsewhere: 'mode any or fast behaves like any_search or fast_search.'

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?

With no annotations, the description carries full behavioral burden. It discloses return structure, credit cost, error handling (429/503 retry, blocked engine fallback, 400 for unsupported parameters), and notes no charge for 400 errors. It lacks explicit auth or safety notes, but search is inherently read-only.

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 front-loaded with purpose, followed by usage, alternatives, return structure, cost, and error handling. Every sentence contributes directly to correct tool selection and invocation, with no wasted wording.

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?

Given 15 parameters, no annotations, and no output schema, the description is thorough: it explains return JSON shape, pagination, error responses, retry logic, and cost. The schema fully documents parameters, and the description complements it appropriately.

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 baseline is 3. The description adds semantic value beyond the schema by explaining engine selection trade-offs (Yandex for Russian, etc.) and the paging use case with start, though it does not detail every 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 states a specific verb and resource ('Search one engine you choose and return its ranked web results') and explicitly distinguishes from two siblings (any_search for engine-agnostic, mega_search for comparison). It also implies differentiation from fast_search by emphasizing engine choice.

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 provides explicit when-to-use guidance ('Use it when the engine matters... or to page with start'), names concrete alternatives ('If any engine will do, use any_search; to compare engines, use mega_search'), and gives examples of engine suitability (Yandex for Russian, etc.).

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