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 cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower, and the description still adds real context: no authentication required and the fact that long topics are paged rather than truncated with a page-count footer. It omits any note on response size or topic-recency, but the incremental value is solid.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action, followed by a single dense topic enumeration and a one-line access note. The topic list is long but each item earns its place as a selection aid; no filler sentences.

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 does the work of explaining that content is paged with a footer indicating page count, and it gives the full topic vocabulary. Complete enough to invoke correctly, though it could say more about the shape of the returned 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?

Schema coverage is 100% and the description's topic list largely mirrors the schema's enum (even dropping a couple of entries), so it adds little for 'topic'. The paging contract it mentions is also already stated in the 'page' schema description, meaning the description largely restates structured data. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Retrieve SocialCrawl API documentation') and enumerates the exact topic space, so an agent knows precisely what comes back. It does not, however, differentiate itself from overlapping siblings such as socialcrawl_pricing (also a documented topic), socialcrawl_discover, or 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?

Implies usage (fetch docs before calling the API) and adds a practical access note ('No API key required'), which is genuinely useful for a cold-start agent. It never states when to prefer this tool over the doc-adjacent siblings (pricing, discover, list_endpoints), and gives no explicit when-not.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds useful behavioral context beyond that: 'No API key required' (auth profile) and the shape of what a listing contains (pricing incl. metered bands, cache TTL, pagination style). It stops short of describing result ordering or size limits, so not 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 sentences, front-loaded with the resource and its payload, then the selection modes and filters. Dense but each clause carries information; the long enumeration of contract fields is the only mild bloat.

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 return-value burden and does so reasonably: it tells the agent the listing includes parameter contracts, pricing bands, pagination style, and cache TTL. For a discovery tool with 7 optional params and full schema coverage, this is nearly sufficient; only the response envelope/format specifics are absent.

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 seven parameters in detail, including hydrating's include= semantics. The description restates method/maxCost/hydrating and adds a small gloss on hydrating ('can fill their own rows in one call'), but contributes little meaning not already present in the schema. Baseline 3 is correct.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (List) and resource (endpoints) with scope detail: 'full parameter contract' across '65 platforms / 575 endpoints'. An agent can tell it is the endpoint-level reference tool. It does not, however, explicitly distinguish itself from nearby siblings like socialcrawl_list_platforms, socialcrawl_get_docs, or socialcrawl_discover, leaving the boundary to be inferred.

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?

Clearly states the two selection modes ('Pass a platform for that platform's reference, or a search term to find an endpoint across all platforms') and names the three filters (method, maxCost, hydrating). Missing explicit when-not-to-use guidance relative to siblings such as list_platforms or discover, 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 declare readOnly, idempotent, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds useful behavioral context beyond annotations: the response is grouped by category, includes endpoint counts and credit ranges, and no API key is required.

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, but the long parenthetical enumeration of dozens of categories and platform names is bloated and partly duplicates what the tool's output should provide. It is information-dense but not tightly concise.

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, so the description needs to convey return contents; it does so reasonably well by stating the grouped-by-category format and the metrics included per platform. It also confirms no API key is required, though pagination and ordering remain unstated.

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 has zero parameters, so the baseline is 4 by rule. There are no parameter semantics to clarify, and the description correctly does not invent any.

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: 'List all 65 platforms available through SocialCrawl.' The scope (all platforms, grouped by category) and sibling differentiation from endpoint-level tools is clear from the contrast between platforms and 575 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?

No explicit when-to-use, when-not-to-use, or alternative tool is named. The phrase 'List all platforms' only implies discovery usage, and it does not route the agent relative to socialcrawl_list_endpoints, socialcrawl_discover, or socialcrawl_get_docs.

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 declare readOnly/idempotent/non-destructive, and the description reinforces with 'No API key required' and 'Costs nothing to ask' — useful context beyond the annotation bar. It explains the metered ceiling-then-refund mechanic, which is genuine behavioral detail. No rate limits or error behavior disclosed, keeping it off 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?

Front-loaded with the core purpose, then action-by-action detail plus a workflow hint. Dense but well-organized; only mild redundancy between the description and the `action` enum prose keeps it from a 5.

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 12-param, 5-action read-only pricing tool with no output schema, the description covers action selection, parameter interaction, and the cost-quoting workflow completely. Missing only the shape of returned data, but output_schema absence makes that a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% so baseline is 3, but the description adds cross-parameter semantics: how `include`+`rows` convert a band into an exact hold, what `endpoint` requires (platform+resource), and how `method` disambiguates the web platform. This meaningfully exceeds the schema's field-by-field docs.

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 — exact credit pricing across 575 endpoints — and enumerates the five actions with their distinct outputs. The distinction from siblings (check_balance, list_endpoints) is implicit but strong: this is the cost-quoting tool, not a balance reader or endpoint lister.

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 instructs 'Use this before spending credits', names the intended workflow (pass `include`/`rows` to turn a band into an upfront hold), and provides concrete usage examples like 'everything I can call for 1 credit'. When-to-use and how-to-use are both covered.

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

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

Goes well beyond the annotations (readOnly/openWorld/idempotent/no-destructive) by disclosing local validation of platform/resource/params/oneOf/enums/CSV limits, credit pricing reported per response, join hold quoting via include=, and idempotencyKey replay semantics. These are exactly the cost/safety traits an agent needs and cannot infer from 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?

The core routing rule is front-loaded, but the long parenthetical enumerating data categories and the multi-clause final sentence about pricing/joins/idempotency are dense and mix several distinct behaviors into one paragraph. Useful content, but not tightly structured.

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 generic passthrough tool over 575 endpoints with no output schema, the description covers the essential contract: GET vs POST, auth requirement, local validation, cost reporting, and idempotency. It omits response shape and error format, but those are largely unknowable per-endpoint.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds useful routing logic (scalars to params, arrays/objects to body; body ignored for GET) but restates what the schema's own property descriptions already say, so the marginal value over structured data is limited.

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 (make an API request to any of 575 SocialCrawl endpoints) and enumerates the data categories and 65 platforms. It explicitly distinguishes itself from socialcrawl_web for scraping/crawling/browser automation, so an agent can route correctly 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?

Gives clear when-to-use context (GET vs POST batch endpoints, which param goes where) and an explicit exclusion pointing to socialcrawl_web. It does not, however, direct the agent to list_endpoints/list_platforms/pricing for discovery, which would complete the 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 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.