ContextFetch

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

Beyond the readOnlyHint/openWorldHint annotations, it discloses the retrieval mechanism (cross-encoder scoring of every passage on the top pages), the return shape (verbatim quotes with [n] citations), the guarantee that nothing is generated, and the cost (1 credit). Cost and output-format disclosure are exactly the traits annotations cannot express.

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-loaded with the core distinction (quoted, never generated) before mechanism, usage scope, and cost. No filler, and the caveat is placed after the primary value proposition.

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 carries the burden and does so: it explains what comes back (quoted passages plus [n] citations to sources), how many pages feed it, and its suitability envelope. 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 coverage is 100% and both parameters are self-documenting, so baseline 3 applies. The description's 'top pages' phrasing loosely echoes num_results but adds no format or tuning guidance beyond the schema's '1-10, default 5'.

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 (answer) plus resource (passages quoted verbatim from the web) and explicitly contrasts with generation, which cleanly separates it from siblings like contextfetch_search, contextfetch_research, and contextfetch_deep_research. The extraction-plus-citation mechanism is named in the same breath.

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 when-to-use ('quick factual lookups') and a when-not ('the quotes may not fully answer an open-ended question'), so the agent can route away from it. It stops short of naming the sibling tool to use instead for open-ended questions, so it is not fully prescriptive.

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 only declare that this is a non-read-only, open-world, idempotent mutation. The description goes well beyond that by disclosing the real-world consequence (the saved card is charged, recurringly, up to a monthly cap), the auth prerequisites, and the policy limit on the cap. These are exactly the behavioral facts an agent cannot infer from annotations.

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 tight sentences, front-loaded with the action, followed by the trigger/effect mechanism, then prerequisites. Every sentence carries distinct information; nothing is 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?

With no output schema, the description must carry the load, and it covers the action, mechanism, prerequisites, and limits. It stops short of stating failure behavior (e.g., what happens if no card is saved or the cap is exceeded) and does not explain the required/optional split, but the essentials for a correct call are present.

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 individual parameter meanings are already documented (baseline 3). The description adds relational meaning the schema lacks: threshold is the trigger, pack is the action taken, and monthly_max_usd is the ceiling on the resulting spend, forming one coherent causal sentence rather than three isolated fields.

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 set (turn on/off, or change) tied to a specific resource (auto-reload) and spells out the exact mechanism it governs. It is unmistakably distinct from every sibling (search, crawl, balance, answer), so an agent can route to it 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 gives clear operating context and prerequisites: an API key and a card saved at checkout are required, and the monthly cap is bounded. It does not, however, name an alternative or state when-not to use it (e.g., check contextfetch_balance first), so it falls short of explicit 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds value beyond them: it specifies the auth mechanism, that the call costs nothing, and that an error state (failed payment) is surfaced in the response. It does not describe behavior when the key is missing or invalid, which is a minor residual gap.

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?

One densely front-loaded sentence covering the returned data, followed by a compact clause on auth and cost. Every element earns its place; there is no filler or repetition 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 parameters, the description carries the burden of explaining what comes back, and it does so by naming the four data points including the failure case. Auth and cost are covered. It is nearly complete for a zero-param read tool, though the exact response shape remains inferred.

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 nothing for the description to disambiguate and the baseline of 4 applies. The description correctly does not invent parameter detail that does not exist.

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 ('Show') and enumerates the exact resources returned: remaining credits, daily burn rate (7-day average), auto-reload settings, and last auto-reload error. This is far more concrete than a generic 'get balance'. It does not explicitly distinguish itself from the closely related sibling contextfetch_auto_reload, whose settings overlap with what this tool reads, 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?

Provides real prerequisites — an API key via Authorization: Bearer, and the notable fact that the call is free (no credit consumption). However, there is no explicit when-to-use guidance relative to contextfetch_auto_reload, and no statement of when this is not the right tool. Usage context is implied by the returned fields rather than stated.

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 and openWorldHint, and the description adds meaningful behavior beyond that: same-site link restriction, maximum depth, page limit, query-based pruning, and a clear credit cost per returned page. It does not cover error behavior or rate limits, but the safety and cost profile is substantially better disclosed than annotations alone.

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 compact and front-loaded: it leads with the core crawl action, then constraints, then optional query behavior, then cost. Every sentence adds useful operational detail without waste.

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 crawl tool with rich schema coverage and no output schema, the description gives enough to call it correctly: output format, same-site scope, depth/page bounds, query behavior, and credit cost. The remaining path-filter details are fully covered 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 description coverage is 100%, so the schema already documents all six parameters, including include_paths and exclude_paths. The description reinforces max_depth, limit, and query behavior but adds little semantics beyond what the schema already states, making the baseline 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 description states a specific verb and resource: crawl one website from a start URL and return its pages as Markdown. It also scopes the operation with same-site links, depth, and page limits, though it does not explicitly name sibling alternatives such as map or extract_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?

Usage is implied by the crawl and Markdown-return framing, and the query parameter's ranking behavior is explained. However, the description does not say when to choose this over contextfetch_map, contextfetch_extract_url, or contextfetch_search, nor does it state 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 only cover readOnly/openWorld, but the description discloses the cost model (1 credit per sub-query, up to 3), server-side dedup and ranking, and the exact return shape (one Markdown evidence pack with numbered sources and query-pruned passages). That is exactly the operational context an agent cannot get from annotations or schema.

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 identity and scope, then behavior, then parameter guidance; each sentence carries information (identity, cost, output, defaulting rule). It is dense but slightly long, with the derivation rule taking a full sentence that could be tightened.

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 carries the return-value burden and does so ('one Markdown evidence pack with numbered sources and query-pruned passages'), plus cost, limits (3 sub-queries), and defaulting. Nothing needed 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 coverage is 100%, so baseline is 3, but the description adds real meaning beyond the schema by explaining the fallback derivation of sub_queries when omitted (query itself, +'documentation', +'benchmark' for speed/performance/comparison questions, else +'example'). That defaulting behavior is not expressible in the schema and materially changes how the agent should call the tool.

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 (research question -> deduped/ranked evidence pack) and explicitly anchors itself to the sibling contextfetch_research ('Same as ... kept for existing clients'), so an agent can tell it apart from that sibling immediately. It is less clear versus contextfetch_search / contextfetch_answer / fetch, which are not addressed.

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 a clear selection signal by declaring itself the legacy-equivalent of contextfetch_research, which implicitly routes new callers to that sibling, and gives explicit guidance on passing sub_queries. It stops short of an explicit 'use X instead when...' statement, so it is strong context rather than a full when/when-not rule.

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 cover the safety profile (readOnlyHint, openWorldHint), so the bar is lower. The description still adds real value by disclosing the output format (clean Markdown, tables preserved) and the scope constraint that the page must be public, which annotations do not convey.

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, and the primary capability plus output format are front-loaded ahead of the optional-parameter tip. 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 no output schema, the description usefully declares the return format (Markdown with tables preserved) and the public-URL constraint, which is most of what an agent needs. It omits failure behavior for non-public or blocked URLs and any page-size or truncation notes.

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 already documented, giving a baseline of 3. The description's note that `query` returns only relevant passages restates the schema rather than adding syntax, length limits, or matching behavior.

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 ('Fetch a public web page') plus the output transformation ('clean Markdown with tables preserved'), which separates it from a raw page fetch. However, it never names the closely related siblings (contextfetch_crawl, fetch, contextfetch_search), so the agent must infer the boundary itself.

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 second sentence implies when to use the `query` mode versus fetching the whole page, which is useful implied usage. There is no guidance on when to pick this over contextfetch_crawl, fetch, or contextfetch_search, and no exclusions (e.g., authenticated or JS-rendered pages).

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 cover the safety profile (readOnlyHint, openWorldHint), and the description adds two genuinely useful behavioral facts beyond them: results exclude the source domain, and the payload is titles, URLs and top passages rendered as Markdown. That said, it does not mention latency, caching, or result ordering.

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, no filler, with the core operation and its key constraint (source domain excluded) front-loaded and the return format appended last. Every clause carries 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 readOnly/openWorld annotations supplied and both parameters documented at 100% coverage, the remaining gap is the absence of an output schema; the description compensates by describing the return payload. Only the lack of sibling disambiguation and any note on result freshness keeps it from a 5.

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 the baseline is 3, but the description adds interpretive value the schema lacks: it defines what 'similar' means in practice (alternatives, related docs, competing libraries), which directly shapes how an agent chooses the url to pass. It adds nothing on num_results, which the schema already fully documents.

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 ('Find pages similar to a given URL') and even enumerates the similarity kinds that matter (alternatives, related docs, competing libraries), which separates it conceptually from a general web search. It does not name any sibling tool, so an agent still has to infer the split from contextfetch_search or contextfetch_research, keeping it 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 parenthetical use cases (alternatives, related docs, competing libraries) imply when the tool is appropriate, but there is no explicit when-to-use guidance and no statement of when to prefer one of the many sibling tools (search, research, deep_research) instead. Usage is inferable rather than stated.

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 only declare readOnlyHint=false and openWorldHint=true; the description adds substantial behavior beyond them — one key per network ever (an irreversibility/idempotency constraint), no signup or payment required, and the instruction to retain the returned key and present it as `Authorization: Bearer <key>`. These are exactly the traits an agent needs before invoking.

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 dense sentences with no waste; the purpose and the when-to-use condition are front-loaded, and the retention/Bearer instruction is a compact actionable tail.

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 parameters and no output schema, yet the description covers what is produced (a key), how to use it, and the one-per-network limit. Nothing an agent needs to call this 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?

The tool takes zero parameters, so the baseline is 4. The description correctly conveys the keyless, argument-free invocation rather than inventing input requirements.

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 — getting a free ContextFetch API key with starter credits — and adds the distinguishing traits (no signup, no payment) that separate it from every sibling tool.

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 trigger condition: 'for when the keyless daily limit runs out.' This tells the agent exactly when to reach for it. It does not name an alternative tool or spell out when not to use it, so it falls short of a 5.

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 cover the safety profile (readOnlyHint=true, openWorldHint=true), and the description adds genuinely new behavior: the discovery strategy with fallback ('robots.txt, else /sitemap.xml'), the same-site restriction, the hard cap (<= 5,000), and the cost ('Costs 1 credit'). It does not describe behavior when no sitemap exists or any rate-limit/throttling considerations.

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?

A single dense sentence with the purpose and source method front-loaded, followed by the routing hint and cost. No filler, no repetition, every clause carries information the agent needs before calling.

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 still conveys what comes back (a capped list of same-site URLs) and how it is derived. Combined with full schema coverage and clear annotations, an agent has everything needed to invoke it 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 description coverage is 100%, so all four parameters including the include_paths/exclude_paths regexes are already documented in the schema. The description only restates the limit cap (<= 5,000) that the schema already declares, adding no new meaning. 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 precise verb+resource ('List a website's URLs') and immediately scopes it with 'without fetching its pages', which cleanly separates it from contextfetch_extract_url and contextfetch_crawl. It also discloses where the URLs come from (sitemaps, start-page links, same site only), so an agent understands the result set 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?

Explicitly routes the agent: 'Use it to find the right pages before contextfetch_extract_url or contextfetch_crawl', naming two concrete alternatives and the ordering relationship. It lacks an explicit when-not condition (e.g., a single known URL should go straight to extract_url), so it falls just short of the top bar.

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 annotations only covering readOnlyHint/openWorldHint, the description carries the behavioral load and does so richly: up to 5 concurrent searches, URL dedupe, cross-encoder ranking, verbatim quoted passages with no generated text, and a concrete cost model (1 credit per sub-query). This is exactly the kind of context annotations cannot express.

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?

Dense and front-loaded: the purpose, pipeline, cost, and parameter guidance arrive in order with little waste. The single long final sentence is somewhat packed, but every clause (cost, defaults, derivation) 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?

There is no output schema, and the description compensates by describing the return shape precisely ('one Markdown evidence pack with numbered [n] sources and their query-pruned passages, quoted verbatim'). Combined with the cost and default-sub-query behavior, an agent has everything needed to invoke and interpret it 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 100%, so the 3 baseline applies, but the description adds real meaning beyond the schema: it spells out the default sub-query derivation logic ('query, query + documentation, and + benchmark or + example'), the credit cost tied to sub_queries, and the intent of 'distinct angles'.

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 ('research a question in one call, server-side') and details the pipeline: concurrent sub-queries, dedupe by URL, cross-encoder ranking, Markdown evidence pack. However, it never distinguishes itself from the closely named sibling contextfetch_deep_research, leaving the agent to guess which research tool to pick.

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 clear operational guidance: pass your own `sub_queries` with distinct angles for better coverage, and explains what happens if omitted. This tells the agent how to drive the tool well, but offers no explicit comparison against sibling tools like contextfetch_deep_research or contextfetch_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?

Annotations already declare readOnlyHint and openWorldHint, and the description adds genuinely useful behavior beyond them: results are pruned to query-relevant passages, formatted as LLM-ready Markdown, and deliberately token-cheap versus raw pages. It does not mention auth/API-key or rate-limit considerations that siblings like contextfetch_balance and contextfetch_get_free_key hint at, keeping it short of 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?

Two tightly packed sentences with zero filler: the first delivers the core verb+output, the second the use cases. Key differentiator (relevant-passage pruning, token savings) is front-loaded before the usage sentence.

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 usefully characterizes the return shape (title, URL, pruned passages) and the safety profile is covered by annotations. It leaves out any mention of authentication or how many results come back by default in prose, minor gaps for a search 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 description coverage is 100%, so the schema already documents query, num_results (range/default) and the include/exclude domain filters. The description adds nothing about parameter syntax or interaction (e.g. include vs exclude precedence), which is the correct baseline-3 outcome 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?

States a specific verb+resource (search the web) plus the distinguishing output format (LLM-ready Markdown, cross-encoder pruned passages). However, it never names the closely related siblings contextfetch_answer, contextfetch_research or contextfetch_deep_research, so an agent still has to guess which of the search-family tools fits.

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 for current events, documentation, APIs, research and fact checking" gives clear positive-use context, but there are no exclusions or alternative-routing statements despite many overlapping siblings (search, contextfetch_answer, contextfetch_research). Usage is implied well enough to call the tool, but the agent gets no guidance on when a different sibling is preferable.

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 only cover read-only and open-world safety, leaving the description to disclose the return payload, which it does by listing {id, title, text, url, metadata}. It does not mention truncation, size limits, or failure modes for an unreachable URL, but the return contract is a meaningful addition beyond the annotations.

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 action and the return shape front-loaded. 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?

For a one-parameter read tool with annotations covering safety and no output schema, the description supplies the action, the id source, and the return fields. It is nearly complete, only lacking notes on text truncation or error behavior for invalid URLs.

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 single parameter is already fully documented by the schema ('An id from `search` (the page URL)'). The description restates the same fact without adding format or validity detail, so the baseline of 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 (fetch) and resource (full text of a search result identified by its id/URL), and even names the return shape. It is reasonably distinguishable from search and crawl, though it does not explicitly contrast itself with the closely related extract_url sibling.

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 implies the tool is used for the second step of a search workflow (id comes from `search`), but it gives no explicit when-to-use/when-not guidance and never mentions alternatives like extract_url or crawl that could serve overlapping 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 and openWorldHint, so the safety profile is covered. The description adds genuine value beyond them by disclosing the return shape ({results: [{id, title, url}]}) and the chaining contract to `fetch`, which is not in the schema.

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 short sentences, front-loaded with the core action, then the return shape and next step. 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?

With no output schema, the description usefully supplies the return structure and the follow-up step. Minor gaps remain (result count limits, pagination, whether queries support operators), but the definition is otherwise sufficient for a simple search 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 description coverage is 100% for the single `query` parameter, so the baseline is 3. The description adds nothing about query syntax or constraints; its mention of `id` pertains to output, not input parameters.

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 web') and even names the downstream sibling `fetch` for retrieving page text. It does not differentiate itself from the other search-adjacent siblings (deep_research, research, crawl), so it falls 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?

Usage is implied by 'Search the web' and the description hints at a workflow by telling the agent to pass an id to `fetch`. However, it gives no explicit when-to-use vs when-not guidance and does not distinguish itself from the many sibling research/search tools.

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