SocialCrawl

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

Beyond the readOnlyHint and idempotentHint annotations, the description discloses meaningful behavior: the exact GET endpoints, that "both cost 0 credits," that a valid SOCIALCRAWL_API_KEY is required, and the ledger semantics including upfront holds being refunded down. This goes well beyond what annotations alone 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?

The description is two dense sentences with no filler. It front-loads the core purpose, then delivers endpoint details, use-case guidance, cost, and authentication requirements in a compact, readable structure.

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?

Even without an output schema, the description covers what each view returns, when to use each, cost, authentication, and the purpose of the ledger. The schema covers pagination details via cursor and limit, so nothing essential for calling the tool 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 the parameters are already well documented. The description adds value by explaining the purpose of the view switch and how request_id relates to confirming actual metered charges, but it does not add additional semantics for limit or cursor beyond what the schema already 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 clear, specific action: "Check the credit balance and the credit ledger for the authenticated SocialCrawl account." It additionally names the two underlying endpoints, making the tool's scope unmistakable and easily distinguishable from siblings like socialcrawl_request or socialcrawl_pricing.

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 clearly explains when to use the balance view versus the transactions view, especially for "dispute-grade itemised receipts" and confirming what a metered endpoint actually charged. It does not explicitly contrast this tool with sibling tools, but the siblings are functionally distinct enough that the internal view guidance is the main decision point.

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 description adds substantial behavior beyond the annotations: lifecycle calls cost 0 credits while queries are metered with reservation and refunds, query is async and returns 202, matching is literal and deterministic with no stemming or fuzzy inference, and coverage is returned even for members with zero matches so partial crawls are not misread. It also discloses privacy handling and the API key requirement. No contradiction with 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?

The description is long but dense and front-loaded. The first sentence states the core purpose and differentiation, the action list embeds lifecycle order, and separate sentences address matching behavior, credit costs, and privacy. Every sentence contributes useful decision or invocation signal; 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?

Despite having no output schema, the description covers the essential return shape (items plus coverage), the asynchronous query flow via query_status, the credit reservation model, and the required API key. Combined with the highly detailed input schema and action enum, an agent has enough context to select, invoke, and interpret this multi-action tool 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% and the schema already documents each parameter in detail, so the baseline is 3. The description adds meaningful cross-parameter context: estimate_cost is local and sizes max_credits, add_members upserts on external_id, query_results carries items plus coverage, and matching semantics clarify keywords/date constraints. It does not individually elaborate every parameter, but the schema already carries that weight.

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 concrete question and explicitly positions the tool as 'the opposite of open social listening'. It states the resource (a cohort of up to 10,000 public handles), the action (keyword mention search), and the result (matching posts plus coverage), making it easy to distinguish from open-listening 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?

The description clearly tells an agent when to use this tool: when the target set is a known panel of specific identities rather than the open social graph. It also provides a helpful lifecycle order for the actions. However, it does not explicitly name sibling alternatives like socialcrawl_discover or socialcrawl_monitors, so the exclusion guidance is implied rather than direct.

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, and non-destructive behavior. The description adds substantial context beyond those: live registry answers avoid drift, bundled fallback behavior without an API key, status requiring no key, zero-credit utility access, and paged rather than truncated output. This richly discloses operational behavior without contradicting 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?

The description is long but organized around the six action modes, and it front-loads the core purpose: the API describing itself live at zero credits. Every sentence contributes useful behavioral or usage context, though the density makes it somewhat heavy as a single block.

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 having no output schema, the description explains what each action returns, including quickstart content, catalog format, endpoint guides, llms corpus options, freshness comparison, and status circuit-breaker data. It also covers auth fallback, paging behavior, and billing context, making the tool effectively self-sufficient for an agent to invoke 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?

The input schema has 100% parameter coverage with detailed descriptions, including enums and per-action explanations. The description adds high-level context around live versus bundled data and when to use actions, but it does not add significant per-parameter meaning beyond what the schema already 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 clearly identifies the tool as live self-discovery of the SocialCrawl API at zero credits, covering the /v1/utility/* family and enumerating each action mode. It is specific about the resource and behavior, though it does not explicitly differentiate itself from sibling tools like socialcrawl_get_docs or socialcrawl_list_endpoints by name.

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 gives actionable guidance: use these live endpoints when correctness matters more than latency, when an endpoint looks unknown, and read 'status' before retrying persistent 502/503 errors. It does not explicitly name sibling alternatives or state when not to use the tool, but the context is clear enough for an agent.

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, idempotentHint, and destructiveHint, covering the safety profile. The description adds that retrieval needs no API key, which is useful operational context, but it does not disclose output shape or how long responses are paged; the pagination detail is present in the schema, not the description. No contradiction with 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?

The main purpose is front-loaded and every parenthetical earns its place by clarifying a topic. It is dense and somewhat hard to scan as a single long sentence, but there is no filler or redundant repetition of schema fields.

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 schema and annotations, the description covers topic semantics, defaults, pagination behavior, and auth requirements, leaving little needed to invoke the tool correctly. The main gap is the lack of explicit guidance about sibling tools that share topic names, which could cause a misrouted call if the agent wants live data rather than documentation.

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 schema already documents both parameters with 100% coverage, so the baseline is 3. The description adds real value by defining each topic in parentheses and introducing the 'platform slug' concept with examples, which goes beyond the schema's bare enumeration.

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 starts with a specific verb and resource: 'Retrieve SocialCrawl API documentation.' It then enumerates every topic value with a gloss, so an agent knows exactly what kind of content is returned and can distinguish this doc-lookup tool from sibling data/action tools.

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 clearly implies the tool is for documentation lookup and adds a useful prerequisite ('No API key required'). However, it never explicitly addresses overlaps with sibling tools like socialcrawl_pricing, socialcrawl_monitors, or socialcrawl_discover, even though those topics appear in the same docs. The agent is left to infer that live data should come from siblings rather than from this documentation tool.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: 'No API key required' addresses authentication, and the mention of 'per-endpoint pricing (including metered bands)' and 'cache TTL' tells the agent what to expect in return. This exceeds the baseline set by 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: four sentences, each earning its place. The primary action and return contract are front-loaded, followed by query modes, filters, and the auth note. There is no filler or redundancy with the schema.

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 having no output schema, the description enumerates what the returned full parameter contract contains, and the schema richly documents all six optional parameters including pagination behavior. The combination of description, schema, and annotations gives an agent everything needed to call this tool correctly for reference lookups and cross-platform searches.

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 each parameter already has a detailed description in the schema. The main description mostly restates the schema's guidance (platform vs. search, method and maxCost filters) without adding new parameter-level meaning. The '65 platforms / 572 endpoints' statistic adds scope context but not semantic detail, so a 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?

The description opens with a specific verb and resource: 'List endpoints with their full parameter contract.' It enumerates exactly what the contract includes (types, ranges, enums, couplings, pricing) and distinguishes this from siblings like socialcrawl_list_platforms by focusing on endpoints rather than platforms. No ambiguity about what the tool does.

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 clearly states the primary query modes: 'Pass a platform for that platform's reference, or a search term to find an endpoint across all 65 platforms / 572 endpoints' and 'Filter with method and maxCost.' This provides clear context for use, though it does not explicitly name sibling alternatives or state when not to use this tool.

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 the tool read-only, idempotent, and non-destructive. The description adds useful context beyond that by noting that no API key is required and by describing the response shape: grouped by category with endpoint count, credit range, and available data. This goes beyond what the annotations alone reveal.

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 core purpose is front-loaded effectively, but the description becomes one very long parenthetical enumeration of categories and examples. While informative, this reduces scannability; the same information could be delivered more concisely as a short category list or shorter summary.

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 zero-parameter, read-only catalog listing tool with no output schema, the description is largely complete: it states the full scope, the output contents, the grouping scheme, and the lack of an API key requirement. It lacks explicit sibling-routing guidance, but that is not essential for understanding this particular 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?

This tool has zero parameters and 100% schema coverage, so there is no parameter documentation burden. The description appropriately adds no invented parameter details and instead communicates access context and result contents.

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: 'List all 65 platforms available through SocialCrawl.' It then clarifies the scope by enumerating covered categories and stating the returned fields, making it clearly distinguishable from a sibling like socialcrawl_list_endpoints.

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 useful for browsing the platform catalog and selecting platforms by category, credit range, or available data. However, it never explicitly explains when to choose this over related tools such as socialcrawl_list_endpoints or socialcrawl_discover, and it provides no exclusions or alternative 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 mark the tool as mutable/destructive and non-idempotent, and the description adds substantial behavioral context: monitors are stateful, management costs 0 credits while scheduled runs add a 1-credit premium, webhook delivery is signed, alerts and time-series accumulation exist, and a valid API key is required. This goes well beyond the annotation hints and gives the agent important operational expectations. No contradiction with annotations exists.

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: core purpose, tagline, action enumeration, billing model, and auth requirement. The description is compact relative to an 18-parameter multi-action tool and front-loads the primary function before operational details. There is no fluff or repetition of schema content.

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 complex multi-action tool with no output schema, the description provides strong operational context including billing, auth, stateful behavior, and webhook signing. The parameter schema handles the detailed field semantics. The only notable gap is that the description does not explain the return shapes for list/get/runs/timeseries, which would be useful given no output schema is declared.

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 input schema covers all 18 parameters with descriptions, so the baseline is 3. The tool description reinforces high-level concepts like cadence, webhook delivery, alerts, and time-series, but it does not add per-parameter meaning beyond what the schema already provides. The schema itself carries the full semantic load for individual 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?

The description opens with a specific verb and resource ('Create and manage stateful monitors') and immediately scopes the behavior: re-running recipes on cadence, delivering signed webhook results, raising alerts, and storing time-series. It lists all eight actions explicitly and distinguishes the tool from one-shot recipe execution via the tagline 'Prism answers once; monitors watch it for you.' This is clearly differentiated from siblings like socialcrawl_request.

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 provides clear context for when to use this tool: when a recipe must be re-run on a cadence, delivered to a webhook, or monitored for metric changes. It contrasts with one-shot execution using the tagline, and it clarifies billing implications. It does not explicitly name sibling alternatives or state hard exclusions, but the usage context is strong enough for an agent to select it correctly.

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 mark it read-only and idempotent; the description adds meaningful context: no API key required, output includes cache TTLs and the refund matrix, and list evaluation rules for metered costs. It does not discuss staleness or rate limits, but those are minor given 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?

Dense and front-loaded: first sentence states the tool's exact scope, then each action's deliverable is listed, ending with an example. Every sentence earns its place; no filler or tautology.

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 complex 10-parameter, 4-action tool with no output schema, the description covers every action mode, the contents returned by each, auth requirements, and representative use cases. The parameter schema handles the remaining syntax details.

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% with thorough parameter descriptions, so baseline is 3. The description adds value by grouping actions, noting that endpoint/platform actions require the platform parameter, stating the default action is 'overview', and giving real query examples.

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 purpose: exact credit pricing for all 572 endpoints, and enumerates four actions with exact outputs. This clearly separates it from sibling tools like socialcrawl_request or socialcrawl_check_balance.

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 usage context ('Use this before spending credits') and concrete query examples for the list action. It does not explicitly name sibling alternatives or state when not to use it, so it falls just 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?

The description adds several behaviors beyond the annotations: local validation prevents malformed calls from costing credits, responses report endpoint price and metered rules, and idempotencyKey enables retry-safe behavior with 0-credit replays. None of these contradict the annotations, and they substantially enrich the agent's understanding of call semantics.

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 well-organized: it opens with purpose, then covers HTTP method conventions, alternatives, authentication, validation, pricing, and retry semantics in a logical order. Each sentence conveys distinctive information needed for a generic 572-endpoint gateway, with 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?

For a tool with no output schema and enormous endpoint variety, the description covers every essential operational aspect: platform/resource identification, GET/POST handling, body/params mapping, required API key, free local validation, cost reporting, idempotency, and routing to the correct sibling tool. It appropriately defers exhaustive endpoint details to list_endpoints.

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. The description adds meaningful interaction-level semantics: it clearly distinguishes when to use `params` versus `body`, gives concrete examples for each, and explains the role of idempotencyKey beyond the schema's field description. This exceeds baseline by helping the agent assemble requests correctly.

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: making an API request to any of the 572 SocialCrawl endpoints, and lists the broad data categories and platforms it covers. It distinguishes itself from the socialcrawl_web sibling by explicitly excluding web scraping/crawling/browser automation use cases.

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 gives clear usage guidance: most endpoints are GET with query params in `params`, while batch endpoints are POST with body in `body`. It explicitly directs users to the socialcrawl_web tool for web scraping alternatives and references socialcrawl_list_endpoints to determine where parameters belong.

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 carry destructiveHint=true, readOnlyHint=false, and openWorldHint=true, so the bar is lower. The description adds valuable behavioral context beyond them: API key requirement, per-action credit costs, async submit-then-poll behavior, monitor re-check cadence, and idempotency semantics. It does not detail destructive consequences, but destructiveHint and action names like delete/cancel/close provide the baseline warning.

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 every clause earns its place: it front-loads the purpose, organizes 23 actions into sync, async, monitor, and browser groups, and attaches pricing, docs pointer, and auth requirements. For the breadth of this tool, the length is justified 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?

For a tool with no output schema and a large action surface, the description is remarkably complete: it covers workflows, auth, costs, and points to get_docs for the full per-action parameter list. It leaves response shapes and detailed error semantics to the docs, which is a reasonable trade-off given the scope.

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 baseline is 3 even without parameter information in the tool description. The description enriches action semantics but does not add per-parameter detail beyond what the input schema already provides for action, id, input, and idempotencyKey.

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 clear, agent-facing purpose: 'Full web scraping, search, and browser automation (Firecrawl-backed),' then enumerates the action groups and their outputs. It is specific enough about what the tool does, though it does not explicitly contrast itself with sibling tools like socialcrawl_request or socialcrawl_monitors.

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 gives strong internal routing guidance: sync reads vs. async jobs, monitor cadence with webhook, interactive browser sessions, and even a free crawl_preview dry-run. It does not state explicit 'when not to use' conditions or compare against sibling alternatives, but for this broad umbrella tool the action-level guidance is quite usable.

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