Spytrend

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

Annotations cover safety (idempotent, non-destructive, closed-world), and the description adds real context beyond them: the consent gate that blocks paid tools, the free/no-quota cost profile, and the no-argument mode that returns terms without recording anything. This is the kind of state-transition detail 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?

Front-loads the effect and the safety-critical instruction in four tight sentences; the parenthetical pricing formula is the only dense piece and it is relevant to informed consent. Nothing is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Output schema exists, so return-value explanation is unnecessary; the description nonetheless covers both invocation modes, the prerequisite it unlocks, and the cost profile. An agent has everything needed to sequence the call 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 baseline would be 3, but the description reinforces the semantic distinction between the two modes (without confirm = read terms; with confirm = record) and ties terms_version to its source. It adds workflow meaning rather than restating types.

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 ('Records the account's one-time consent to ... pricing') and frames the consent-gating role that no sibling tool shares. An agent can identify this as the prerequisite step for paid tools without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit two-step workflow: call without confirm to retrieve terms and status, then call with confirm=true and terms_version only after explicit user agreement. It also names the behavioral consequence (paid tools refuse with pricing_consent_required) and an explicit prohibition ('never accept on the user's behalf').

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: explicit per-entity-type credit costs (1 for ad, 10 for creative, free for webmaster/hub/shop), the fact that already-saved items are never duplicated or re-charged, and the one-time consent/pricing multiplier rule. Annotations only assert idempotency generically; the description explains the observable behavior (already_saved reporting) and the cost consequences.

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

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

Front-loads what is saved and where, then dependencies, then billing — a sensible order. It is dense but every clause carries operational information; the main inefficiency is duplicated entity-type enumerations that also appear in 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?

An output schema exists so return values need no explanation, and the description covers everything else an agent needs: valid entity types, id source, the conditional hub parameter, folder defaults, idempotency, and the full billing/consent workflow.

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 cross-parameter logic (hub is REQUIRED only when entity_type=hub) and actionable guidance on folder naming ('PREFER a short descriptive name from the user's search', dated fallback). Some sentences restate schema text verbatim, which caps it below 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?

Opens with a specific verb and resource ('Save a SELECTION of entities to one of the caller's favourites folders'), states the downstream purpose (review later on spytrend.com), and enumerates the entity types. It is clearly distinguishable from the read-side sibling list_favorites.

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 concrete prerequisites: ids must come from the search_* tools, hub slug is mandatory for entity_type=hub, and estimate_cost must be called before invoking with pricing terms accepted. It doesn't name an explicit alternative or when-not-to-use, but the conditions for correct use are clear.

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

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

Beyond readOnlyHint/destructiveHint=false, it discloses that the tool does not execute the target and consumes no quota, that the estimate is a maximum bounded by current balance, that the pricing is 'filters × monthly step', and that undelivered search rows are refunded. These are the exact behavioral facts needed to trust and quote the number.

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 FREE and the return value; every sentence carries content (refunds, pricing formula, Startups exception, non-execution). Slightly dense, with one heavily parenthesized sentence, but 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?

Covers the tricky parts an agent would otherwise get wrong: what the number means (a max/upper bound, not a charge), the refund rule for undelivered rows, and the alternate accounting model for Startups tools. Output schema exists, so return-shape detail is appropriately left out.

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 already documents both parameters with an example, so the description only needs to reinforce. It does add useful framing — the arguments must be *exactly* those of the upcoming call, and it enumerates which tool families expect max_objects rather than max_tokens — which goes slightly beyond the schema text.

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 ('pre-call estimate' of a tool call's cost) and immediately names the return value (max_tokens) plus its Startups variant (max_objects). An agent can distinguish it from get_usage or any paid search sibling without opening a 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?

'Call it BEFORE every paid call and tell the user the number' gives an explicit trigger and a required follow-up action. It also scopes the behavior per tool family (searches = upper bound, Startups tools = objects model), so the agent knows what changes when the target tool differs.

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 the safety profile (readOnly/openWorld/non-destructive); the description adds quota cost per delivered row, tiered pricing, consent requirement, and a non-obvious pagination caveat. The total-semantics disclosure (total is the upstream candidate count, source ad excluded, source_excluded/total_semantics fields expose that) is exactly the kind of behavior annotations cannot 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?

Front-loaded with purpose and the sibling distinction, then behavioral caveats, then commercial terms — a sensible order. Slightly dense and the fanpage/domain basis is restated a second time, but nearly every clause carries decision-relevant 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?

Output schema exists so return values need not be explained, and the description still covers the one return-value subtlety that would mislead (the unadjusted total). For a paginated, quota-metered read tool with four simple params, nothing an agent needs before calling 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 already documents ad_id, basis, limit and cursor including the enum meanings, so the description's restatement of the fanpage/domain basis adds little. It does not explain the interaction between limit and credit cost beyond what the schema row says. Baseline 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?

States a specific verb ('find ads related to one source ad') plus the exact overlap bases (fanpage page_id, exact landing_domain), and explicitly separates itself from find_similar_creatives ('entity overlap, NOT visual similarity'). An agent can route between the two siblings without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit alternative ('use find_similar_creatives for that'), a pre-call prerequisite chain (estimate_cost for the max debit, accept_pricing_terms for consent, inform the user), and when-not-to-use via the visual-similarity exclusion. This is the full when/when-not/alternatives package.

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

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

Beyond the readOnly/openWorld annotations, it discloses the upstream 20-candidate cap and that has_more is conservative at that cap, explains threshold_status and result_status semantics, warns that no media URLs are returned, and lays out quota (1 credit/row) and pricing (×1 after 500 credits/month). This is unusually rich behavioral context for an agent to reason about cost and result completeness.

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 and the key disambiguation (visual vs membership) before the operational notes. Dense but every sentence carries information; the status-code explanations add length though a slightly tighter phrasing could carry the same signal.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values needn't be re-explained; instead the description covers the operational gaps an agent would otherwise stumble on — the 20-row native cap, conservative has_more, absence of media URLs, and the quota/pricing/consent path. Complete for a 3-param, capped similarity search.

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 creative_id, limit, and threshold are already documented including defaults and max values. The description adds marginal framing (threshold_status distinguishes explicit vs default) but no new parameter syntax or format beyond the schema. Baseline 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?

States a specific verb and resource ('Find creatives that look the same as one creative') and explicitly scopes it as visual similarity rather than exact creative membership. It also names sibling tools (search_creatives for the source id, get_media for media) so the agent can place it in the tool graph immediately.

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 distinguishes the use case from exact-membership lookups, directs the agent to get_media for selected ids, and prescribes the pricing workflow ('get the maximum debit from estimate_cost (free) and tell the user' plus one-time accept_pricing_terms consent). When/when-not guidance and alternatives are both present.

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

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

Beyond the readOnly/openWorld/non-destructive annotations, it discloses deterministic ordering, a 5000-row canonical cap, how result_status/result_cap/total_status signal completeness of the bounded set, and the credit/quota model (1 credit per delivered row, ×1 after 500/month). These are exactly the operational facts an agent needs before calling a metered tool.

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

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

The core behavior and the prerequisite tool lead, followed by result-shape, then QUOTA/PRICING blocks. It is dense and mostly earns its space, though the pricing paragraph is long relative to the reminder value it adds.

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?

Covers workflow prerequisite, result-set bounding semantics, ordering determinism, cost model, and consent requirement; an output schema exists, so return values need no further explanation. Nothing an agent needs to invoke 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?

Schema description coverage is 100%, so the schema already documents limit, offset, values, param_key, and webmaster_id. The description only reinforces provenance ('pass one returned param_key', 'optionally narrow to selected values'), so it meets but does not exceed the baseline 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 and resource ('Find other webmasters sharing normalized URL-parameter values with a source webmaster') and scopes it to the URL-parameter-overlap basis, which cleanly separates it from sibling similarity tools like find_similar_ads and find_similar_creatives.

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 gives the required workflow ('First call get_webmaster_similarity_facets, then pass one returned param_key'), the optional narrowing step, and the pre-call pricing sequence (estimate_cost for max debit, accept_pricing_terms consent, tell the user). Alternatives and prerequisites are all named.

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 this as read-only, open-world, and non-destructive, but the description adds substantial behavioral detail beyond them: quota and billing mechanics, absence semantics for body and body_chars, expiring media links, TikTok pricing, multilang carousel behavior, primary creative status, and cloaking caveats. It does not contradict 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 front-loaded with the core purpose, but it is very dense and lengthy, with repeated billing and pricing explanations across multiple sections. The information is relevant, yet some sentences could be tightened or consolidated without losing necessary meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool’s complexity, output schema, annotations, and billing behavior, the description is complete enough to guide correct invocation. It covers media lifetime, quota, billing reconciliation via _meta.billing, multilang content semantics, and primary creative handling, so an agent has the operational context it needs.

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 has 100% description coverage for both parameters, including the source enum and its TikTok credit implications, so the schema already does most of the work. The description reinforces source=tiktok pricing and id provenance, but adds limited parameter-specific meaning beyond the schema.

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

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

The opening sentence states a specific verb and resource: fetch a single ad by id with full details and creative media. It also names the relevant sibling relationship by noting that get_ad and get_media(ad) share the same full detail carousel, which helps an agent distinguish the 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 gives clear operational context: call estimate_cost before invoking, accept pricing terms once, re-fetch when media links expire, and note TikTok-specific credit costs. It does not explicitly say when to prefer get_ad over get_media or search_ads in all cases, but it provides enough routing context for correct use.

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 readOnlyHint/destructiveHint annotations by disclosing the credit cost per breakdown row, reservation-and-refund behavior, the row cap, flattened-with-dimension result shape, nullable totals semantics (null pending vs numeric 0), the status-section filter exception, and the retry protocol. This is unusually full behavioral disclosure for a paid read surface.

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

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

Front-loads the core purpose, then cost, then retry/pricing, so an agent can decide early. It is dense and abbreviation-heavy (Pro-or-higher, PRICING block), and the 20-row cap is stated twice, but nearly every sentence carries operative 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?

Output schema exists, yet the description still supplies what matters for correct invocation: pricing model, credit reservation, nullability rules, truncation metadata, and the retry path. Nothing an agent needs to call this correctly and warn the user about cost appears 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 already 100%, so the baseline is 3; the description earns above that by clarifying max_items_per_section bounds and default, and by stating which parameters are deliberately rejected. It still leaves the 49 filter params to the schema rather than explaining filter interactions or date semantics.

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

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

Names a specific verb and resource (analytics overview for the current Meta /ads selection) and enumerates exactly which breakdown dimensions come back. It implicitly separates itself from search_* siblings by scoping to an already-made selection, but never names those alternatives explicitly.

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 concrete operational guidance: check estimate_cost first, obtain consent via accept_pricing_terms, re-issue the identical call after retry_after_seconds on pending, and don't blindly retry paid calls. It also lists what is not accepted (pagination, sorting, TikTok, raw SQL, etc.), but never explicitly contrasts when to choose this over search_ads or get_trends.

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 read-only/non-destructive profile, and the description adds substantially more: exact quota cost (1 MCP credit), paid-plan multiplier and 500-credit threshold, one-time consent via accept_pricing_terms, ID auto-resolution behavior, and detailed contracts about what category_total_ads and top_creatives[].total_ads actually count. This is well beyond what annotations or schema disclose.

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

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

Front-loaded with purpose and the field list, then ID resolution, then the category-counter contract, quota, top_creatives contract, and pricing. Each block earns its place, though the ALL-CAPS emphasis and repeated contract caveats make it denser than strictly necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite an output schema existing, the description explains the return payload's semantics (what total_ads/active_ads mean, what top_creatives' total_ads counts, how ai_coverage interacts with category counters) — precisely the interpretive context an agent needs to avoid misreporting. Nothing material 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 schema only says 'the resource id to fetch' despite 100% coverage, but the description compensates heavily: the id may be an advertiser UUID (from an ad's advertiser_id or get_trends dimension=advertisers), a Facebook page id (from get_creative's fanpages or an ad's page_id), or a pasted facebook.com URL in any form — all auto-resolved. That is far more actionable than the schema text.

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 single advertiser's FULL card by id') and enumerates the exact fields returned (name, external_id, total_ads, active_ads, top_countries, etc.), making it unmistakable against siblings like search_advertisers or get_ad. It also explicitly contrasts its exact precomputed counts with search_ads' estimated totals.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit routing: 'To list the advertiser's ads, call search_ads with advertiser_id', and warns not to paginate search_ads just to count ads. It also prescribes a pre-call workflow ('get the maximum debit from estimate_cost (free) and tell the user'), naming the sibling tool to use.

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

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

The annotations already establish readOnlyHint=true and destructiveHint=false, but the description adds substantial behavior beyond them: it says transcription is never started, describes bounded breakdown truncation and status aggregation, explains copy_language provenance/confidence states, and gives quota/pricing behavior. These details materially help an agent interpret and safely invoke the tool.

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

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

The description is front-loaded with the core purpose and remains organized around behavior, id/media guidance, and pricing. It is dense and includes some return-status detail that could be tightened, especially given the output schema, but most of the content is relevant to correct invocation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity, the existing output schema, and annotations, the description is highly complete. It covers what is returned, truncation/status behavior, language-transcript caveats, id provenance, media alternatives, and pricing prerequisites.

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 defines the single required id parameter generically. The description adds useful meaning by specifying that the id is a creative UUID from search_creatives, improving parameter semantics beyond the schema.

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

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

The description uses a specific verb/resource pair, 'Fetch ONE creative's metadata plus its canonical bounded breakdown by id,' and enumerates the included breakdown dimensions. It clearly distinguishes this tool from media retrieval by saying media URLs are excluded and should be downloaded with get_media.

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 explains that the id is a creative UUID from search_creatives, names get_media as the alternative for media downloads, and gives pre-call pricing guidance via estimate_cost. It does not explicitly compare when to choose this over other creative/ad detail siblings, but the usage context is clear enough.

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

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

Beyond the readOnly/openWorld annotations, the description discloses negative behavior ('CONTACTS, BIOS, VIDEOS AND POSTS ARE NEVER RETURNED — has_email is only a yes/no'), per-platform field availability, daily free-tier limits, credit cost, and pricing escalation. These are behavioral facts nothing in the annotations or schema conveys.

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 capability and field list are front-loaded, and the all-caps warnings about withheld data earn their emphasis. The QUOTA/PRICING block is verbose and partly instructional policy rather than tool semantics, but it remains dense and purposeful rather than 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 two-param, read-only lookup with an output schema, the description covers cost, consent, rate limits, and the field-difference between platforms. The only mild redundancy is restating return fields that the output schema already defines, which does more good than harm for a paid 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 coverage is 100% and both parameters are enum/typed with their own descriptions, so the schema does the heavy lifting. The description reinforces that slug comes from search_influencers and that platform drives which return fields appear (YouTube-only vs Instagram-only), which is useful but marginal at the parameter level.

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 ('Fetch one creator card from the influencer directory') and states the exact addressing scheme (platform + slug). It explicitly contrasts with search_influencers by saying the card has 'the same fields as a search row plus' extras, so an agent can distinguish it from the sibling search tool without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It specifies the prerequisite ('slug as returned by search_influencers'), the access constraints ('Free accounts can open a limited number of cards per day'), and a concrete pre-call sequence: get max debit from estimate_cost (free), tell the user, then one-time consent via accept_pricing_terms. That is explicit when-to-use and how-to-prepare guidance referencing the correct siblings.

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 readOnly/openWorld/destructive=false; the description adds the non-obvious economics and failure semantics: per-delivered-item quota costs (50/1/10 credits), duplicate ids fetched and billed once, malformed ids never consuming quota, partial batch behavior, and a quota-bounded prefix with an unexamined tail. It also gives an operational rule to retry fallback_urls on 416/404 before treating a URL as unavailable.

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

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

Purpose is front-loaded, but the body is a ~350-word run-on wall covering quota tables, multilang carousel semantics, cloaking detection, and _meta.billing details for a two-parameter tool. Several passages (carousel_position, cloaking_detected, original_landing_domain) are far from the tool's stated job and bury the actionable parts.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite an output schema, the description states the return shape, additive counts, partial/failure reporting and duplicate_count, so an agent can interpret results without guessing. Pricing, retry and batch-partiality behavior cover everything needed to call 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 baseline is 3; the description still adds value by tying 'ad' to search_ads results and 'creo' to search_creatives, and by explaining that malformed/zero UUIDs are reported per item without billing and that duplicates are canonicalized. It stops short of describing id format beyond 'UUID', which the schema already covers.

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

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

The opening sentence gives a specific verb, resource, output shape (image/video URL + thumbnail) and the exact id domain (1-500 UUIDs from search_ads / search_creatives). It also explicitly differentiates from sibling get_ad by stating get_ad already includes media.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the typical flow (search_ads → pick ids → get_media), an explicit when-not-to-use rule ('do not call get_media again for files you already received'), and prerequisites ('before calling, get the maximum debit from estimate_cost (free) and tell the user', one-time consent via accept_pricing_terms). Alternatives and exclusions are both present.

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

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

Beyond the readOnly/openWorld annotations, the description discloses extensive behavior: paging via products_page, what embedded_total vs products_total mean, count non-additivity rules, provenance caveats for domain_created and traffic fields, sample-vs-catalog distinctions, and quota/pricing considerations. These are substantive operational details an agent would otherwise miss.

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

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

The definition is front-loaded with a clear purpose sentence and uses some headings for COUNTS, QUOTA, and PRICING, so it is not unstructured. However, it is extremely long and dense, with many run-on caveats and repeated non-additivity warnings that could be tightened or moved into field documentation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity, the presence of an output schema, and rich annotations, the description is more than complete. It covers purpose, paging, field semantics, count pitfalls, provenance limits, alternatives, quota, and pricing so an agent has enough context to call 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 the baseline is 3, but the description adds useful paging semantics beyond the schema: products are paged by products_offset/products_limit, products_page exposes next_offset, and all other profile fields remain present on each page. It does not add much about the domain parameter beyond what the schema already says.

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 first sentence states a specific verb and resource: 'Fetch one domain surface's full profile' with embedded products. It scopes the tool to a single domain surface and later distinguishes it from catalog-wide browsing via search_products.

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 explicitly routes agents to alternatives: use search_products to browse the rest of the catalog, call search_products with domain=<domain> for per-product ad numbers, and use add_to_favorites to save the shop. It also gives a prerequisite workflow for estimate_cost and accept_pricing_terms before calling.

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

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

Beyond the readOnly/openWorld annotations, the description discloses quota costs, free-plan preview limits, plan-window count restrictions, rate limits, concurrency admission behavior, pricing consent requirements, and media URL absence. It also explains multilang handling and pagination semantics, which are material behavioral traits not covered by 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 opening is front-loaded and many details are necessary for this complex tool, but the description is extremely long and repeats the FREE PLAN COUNTS caveat twice almost verbatim. Some quota and plan details could be tightened without losing decision-relevant 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?

Given 53 parameters, complex dimension semantics, an output schema, and plan-dependent behavior, the description supplies enough context for correct invocation and interpretation. It covers pagination, return-shape caveats, plan limits, quota, concurrency, and alternatives to sibling tools.

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

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

Although schema coverage is 100%, the description adds substantial semantic context beyond the schema: dimension-specific row meanings, zero-value interpretation, sort_by behavior, snapshot tiers, scaling filters, and geo_timeline pagination exceptions. This goes well beyond restating parameter names or types.

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

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

The opening sentence states a specific verb and resource: returns aggregated trend rankings for a named dimension. It enumerates the dimensions and distinguishes rankings/aggregates from individual ad listing via search_ads, so an agent can tell exactly what this tool is for.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says to use this for rankings/aggregates and NOT to list individual ads, directing those to search_ads. It also explains dimension choice, search_arbitrage narrowing, and alternative tools for media or webmaster pagination, giving clear when-to-use and when-not-to-use 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?

Goes well beyond the readOnly/idempotent annotations by disclosing that the call is free and consumes no quota, that billing is per delivered result, that short pages auto-refund, and per-item credit costs. This is exactly the kind of behavioral context annotations cannot 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?

Front-loads what the tool returns, then explains credits. The credit-cost enumeration is dense but relevant to interpreting the returned numbers; slightly verbose for a quota lookup but each sentence 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?

An output schema exists so return values needn't be described, yet the description still tells the agent how to interpret plan tiers and credit numbers. Nothing needed to call or interpret this zero-param tool 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 parameter semantics baseline is 4. Nothing to explain, and the description does not waste space on nonexistent inputs.

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 ('Return the caller's current MCP quota') and enumerates exactly what is returned: plan, credits used, remaining, limit. An agent can distinguish this from estimate_cost or any search tool 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?

The context of checking quota before spending credits is implied by the pricing detail, but there is no explicit 'use this before/after X' or reference to the sibling estimate_cost tool. Usage is inferable but not 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?

Beyond the readOnly/openWorld annotations it discloses quota cost (1 MCP credit per call), that summaries escape the section row allowance, the pricing multiplier after 500 credits/month, the consent requirement, and crucially that funnel contents are NOT returned but every row carries funnels_url. This is exactly the extra context annotations cannot carry.

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: access gating first, then quota, then the funnels_url limitation, then pricing. The ALL-CAPS section labels make it scannable, but the description is long and a few clauses (e.g. the subscriber explanation) 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?

An output schema exists so return values need no explanation, yet the description still flags the one return-value nuance an agent must relay (funnels_url instead of funnel data). Combined with quota, consent and pricing prerequisites, an agent has everything needed to call it correctly and set user expectations.

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. The description restates the breakdown dimensions available (brand, category, domain, page, country, language, month) matching the group parameter and mentions 'with month range and filters', but adds no format or interplay details beyond the schema.

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

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

States concretely that it returns a summary of the web2app (quiz-to-paywall) ad market from the Spytrend ad base, with the dimensions available (brand, category, domain, page, country, language, month). It is distinguishable from generic ad-search siblings by the explicit quiz-to-paywall framing, though it never names a sibling it competes with.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit preconditions and a workflow: the call is refused without the annual-plan add-on, a monthly 'site' subscriber is told MCP requires the annual plan, and the agent must call estimate_cost first and obtain accept_pricing_terms consent. It lacks explicit 'use X instead when Y' routing against siblings, 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 mark the tool read-only, non-destructive, and open-world, but the description adds substantial behavioral context: analytics_pending semantics, fanpages_status caveats, total_ads interpretation, quota/pricing, consent, and TikTok plan/cost differences. There is 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 answer is front-loaded with the core purpose and headline output, and most sentences carry necessary caveats for a complex analytics card. It is dense and long, but the length is largely justified by the tool's many behavioral edge cases.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the rich annotations, full schema coverage, and output schema, the description is complete enough for correct invocation. It covers identity constraints, alternate corpora, pricing, quota, and interpretation guidance for the returned analytics.

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%, but the description still adds decision-relevant meaning: id must be the canonical UUID from search_webmasters and domain/display names are rejected; source switches corpus and cost; date window and countries change the returned card 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?

The description states a specific verb and resource: fetch a single webmaster by UUID, returning aggregate stats plus top_creatives. It clearly distinguishes the entity-card fetch from sibling search tools and explains the headline output.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly routes the agent: use search_webmasters to obtain the canonical UUID, use search_creatives?webmaster_id or search_ads?webmaster_id for the rest of the network, and get_media for downloads. It also gives the TikTok alternative and its different cost/plan requirements.

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, openWorldHint and destructiveHint=false, so safety is covered. The description adds real behavioral context beyond that: it explains what 'similarity' means semantically and that only facets with at least one other match are returned (an implicit filter on results). The 'FREE' note is useful cost information not present in 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?

Four short sentences, each carrying distinct information: purpose, a disambiguation of 'similarity', a result-filter guarantee, and cost. The key semantic disambiguation is front-loaded rather than buried, 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?

An output schema exists so return shape need not be described, the single parameter is fully documented in schema, and annotations cover the safety profile. What remains is a light gap: the relationship to find_similar_webmasters (the natural follow-up call) is never made explicit.

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 single parameter is documented as 'source webmaster UUID from search_webmasters', which already gives origin and type. The description adds no syntax, format, or sourcing detail beyond the schema. Baseline 3 applies when the schema does the work.

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?

Uses a specific verb and resource: 'List the URL-parameter keys and normalized values' that identify related webmasters. It also pre-empts a likely misreading by defining similarity as shared affiliate/tracking parameter values rather than name or domain matching. It never names the sibling find_similar_webmasters, so the boundary between 'discover facets' and 'fetch matches' is left implicit.

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?

'can be used to find related webmasters' implies this is a discovery step preceding find_similar_webmasters, but the relationship is never stated explicitly and no alternative is named. There are no exclusions or prerequisites beyond the required webmaster_id. Usage must be inferred rather than read.

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, destructiveHint=false and openWorldHint, so safety is covered; the description adds non-trivial context: the quota cost, and the fact that output shape changes depending on whether folder is passed. It does not describe pagination or limits, keeping it at 4.

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 but front-loaded: the dual-mode behavior and the filter come first, then the return contents, then the use case and cost. The middle sentence is long, but every clause carries actionable 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?

Despite an output schema existing, the description still spells out what each folder type returns, which is the exact decision-critical detail an agent needs. Nothing needed to call 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 would be 3; the description adds value by mapping each entity_type to the sibling tool that consumes the returned ids (get_creative/get_webmaster/get_ad) and by explaining the disambiguation need when a folder name spans types.

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 (list the caller's favourites folders) and immediately clarifies the dual behavior: folder list vs. items inside a named folder. An agent can distinguish this from siblings like add_to_favorites or get_creative 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 explicit when-to-use ('confirm what add_to_favorites saved', 'read a folder back'), explains the omit-vs-pass condition for entity_type, and the folder-vs-list switch. The 'FREE — does not consume quota' note routes the agent here over quota-consuming siblings when it only needs a read-back.

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 readOnly/openWorld; the description carries far more: per-row credit costs (1 Meta, 10 TikTok, 50 to open a multilang ad), plan gating (Pro-or-higher for TikTok), refunds on short pages, partial delivery when balance is short, a 20-row Meta page cap despite limit=200, and a subtle correctness rule that an 'unavailable' count is PENDING not zero. It also discloses intentional omissions (most_reused_creative group totals) and semantic traps (status_today is current state, not historical).

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 and the highest-value caveats are front-loaded, but the description is a single multi-thousand-word paragraph with no headings or line breaks, making the TikTok block and EU block hard to locate mid-read. Credit pricing is restated at least three times (per-row cost, opening cost, TikTok 10x premium, plus the PRICING clause) and 'Request small limits and narrow filters' appears twice. Informative, but clearly not trimmed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return shapes need not be spelled out, yet the description still explains the pagination contract (has_more/next_cursor, total/total_status with exact/estimated/unavailable and counted_at), the exact-count preconditions (≤31-day closed window, or the single-country cube up to 90 days), TikTok's distinct tiktok_data shape, and EU transparency blocks. For a 55-parameter open-world search tool with real billing consequences, this is as complete as it needs to be.

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 schema sets the baseline at 3, but the description adds real semantics beyond it: date_from is the Facebook LAUNCH axis vs first_seen = indexing date, formats combine with OR (so don't mix base and categorized variants), categories totals cover an AI-labeled subset only and are not comparable to get_trends extrapolations, body_chars length filters exclude textless ads, and max_countries changes meaning depending on whether a country set is selected. Not every one of the 55 params gets this treatment, so not a 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?

The opening sentence names a specific verb+resource (search the spytrend.com ad database) and immediately scopes the return value as METADATA with an enumerated field list (title, body_chars, landing domain, status, geos...). It explicitly differentiates from siblings: body text is fetched with get_ad, creatives with get_media, aggregates with get_trends, advertiser totals with get_advertiser. An agent can pick this tool over its 30 siblings without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit routing rules throughout: use landing_domain NOT query to find ads on a domain; use date_from/date_to not first_seen_from/to for market newness (with the reason: late-indexed old ads); do NOT paginate search_ads for an advertiser's exact count, call get_advertiser/get_webmaster; use get_trends for aggregate rankings; do NOT call get_media for TikTok ids. It also states when-not conditions (unsupported TikTok filters are rejected, not silently ignored) and the cube-path preconditions.

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

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

Beyond the readOnly/openWorld annotations, it discloses the credit cost model (1 MCP credit per delivered result, 20 by default, refunds on short pages), plan balance limits, auth-linking requirement with the failure mode (actionable refusal, not a server error), per-user rate limits with structured error.code=rate_limit_exceeded, and one-at-a-time admission for heavy calls. It even explains the restricted-archive-window behavior so a zero count isn't misread as 'no such advertiser'.

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

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

Purpose and routing are front-loaded, which is good, but the paragraph is very long for a two-parameter tool and carries a large block of cross-cutting operational policy (quota, auth, rate limits, concurrency, pricing) that reads like boilerplate repeated across the server. Every sentence is informative, yet the density makes the tool-specific signal harder to extract.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return shapes needn't be explained, yet the description still names the key fields (external_id, advertiser_id, advertiser_ids, ad_count) that drive the follow-up calls it recommends. Combined with cost, auth, and failure-mode disclosure, nothing an agent needs to invoke 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?

Schema coverage is 100%, so the baseline is 3; the description still adds real meaning — that links in any form resolve to the canonical fanpage with the exact match first, that either id namespace works, and that under search_arbitrage/sa_* the query becomes optional and pasted links are not resolved. One defect: the description says 'pass `limit` (1–200)' while the schema caps it at 1–50, a range inconsistency an agent could trip over.

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

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

The opening sentence names the verb and resource and enumerates the three accepted query forms (name, numeric page id, pasted facebook.com link). It explicitly separates this tool from get_advertiser (single card by id) and search_ads (an advertiser's ads), so an agent can route without opening schemas.

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?

Alternatives are named with the exact condition that selects each: get_advertiser for one advertiser's full card, search_ads with page_id/advertiser_id for ads, get_trends with dimension=advertisers for rankings and filters. It also flags the arbitrage-only mode (search_arbitrage=true or sa_* filters) as a distinct usage context.

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 behavioral context beyond annotations: paid add-on dependency, refusal behavior, shared daily/monthly quotas, quota exclusions for get_web2app_market, pricing multiplier, consent requirement, and estimate_cost prerequisite. These details materially affect whether and how an agent should call the tool.

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

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

The description is dense but mostly front-loaded, with labeled sections for paid add-ons, quota, and pricing. Some access and pricing details are repeated across sentences, making it longer than ideal, but the information is largely relevant to correct invocation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's commercial access model, quota sharing, pricing terms, and the presence of an output schema, the description covers the operational constraints an agent needs before calling. It lists the returned row fields and points to estimate_cost and accept_pricing_terms, leaving little critical context missing.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters. The description maps lp_category to vertical, lp_subcategory to niche, and lp_product to offer, but it does not mention q or limit beyond the schema, so it adds only modest meaning over structured data.

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

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

The description states a specific verb+resource: 'Find Meta ads whose landing pages are nutra or crypto affiliate offers,' and names the exact filtering dimensions. This is clear enough to distinguish it from general searches in practice, but it does not explicitly contrast itself with sibling tools such as search_ads.

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 important access context—paid add-on required, refusal without it, and monthly site subscriber messaging—plus prerequisite steps like estimate_cost and accept_pricing_terms. However, it does not explicitly say when to choose this over search_ads or other search tools, so usage guidance is implied rather than fully specified.

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?

Discloses far more than the readOnly/openWorld annotations: masked authors, captions, titles and links; first-page-only with limit ≤ 10; imprecise 'total'; low_relevance and filters_applied flags; per-account daily search limits; cache behavior for repeated queries; and specific gate errors (subscription_required, busy with retry). Nothing contradicts readOnlyHint=true.

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

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

Purpose is front-loaded in the first clause and nearly every sentence carries actionable information (masking, cost, flags, errors). It is a dense single-paragraph block, though, and some schema-redundant field enumeration could be trimmed for readability.

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 paid, quota-metered, read-only search tool the description covers the full call lifecycle: required precondition (estimate_cost), consent, cost model, result-shape caveats, failure modes and what not to claim. Return fields are enumerated even though an output schema exists, which is redundant but not harmful.

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 parameter documentation is already strong; the description still adds meaning by stating that empty platforms means all, that published_within_days only accepts 7/30/90 windows, that limit is capped at 10 with no paging, and that each delivered row costs a credit. Most of this is reinforcement of the schema rather than new semantics, keeping it just short of a 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 and resource — semantically search short-video content ideas across Instagram Reels, TikTok and YouTube Shorts — and scopes it as 'Content AI (lite)'. Clearly distinct from sibling tools like search_ads, search_creatives or search_influencers, which cover other entity types.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use context (free-text topic/niche/hook lookup), names the alternative behavior for going deeper ('repeat the search with a sharper query instead' since there is no paging), and routes the agent to siblings estimate_cost and accept_pricing_terms before calling. It also says what to do when low_relevance=true and filters_applied=false.

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 assert readOnly/openWorld/non-destructive; the description adds substantial unseen behaviour: per-delivered-result credit billing with auto-refund on short pages, separate 50/10/1 credit opening charges, validation that rejects invalid/open/reversed periods before quota work, refusal instead of returning a false zero when ads_in_period is missing, the period_axis contract, and the multilang/decoy-slide caveat. This is exactly the context annotations cannot carry.

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 body is roughly 700 words of run-on prose that restates the same period-window rule at least four times (opening paragraph, PERIOD PARITY CONTRACT, AXIS CONTRACT, and again in each of date_from/date_to/period_from/period_to parameter descriptions). Critical operational facts such as "Request small limits and narrow filters" and the pricing-consent requirement are buried mid-paragraph rather than surfaced.

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 35-parameter search tool with an output schema, the description covers what matters: billing model, consent prerequisite, filter interaction rules, sort semantics, date-axis ambiguity, and failure modes. An agent could invoke this correctly from the description plus schema, which is the standard that matters here.

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

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

Schema coverage is already 100%, yet the description adds semantics the schema cannot express: date_from/date_to are aliases of period_from/period_to and do NOT filter rows (contrasted with search_ads.date_from), sort_by=ads_in_period ranks by measured in-period count while total_ads stays lifetime, and slice.ads_in_slice is the ordering key for advertiser/webmaster slices. It also explains meta.period_window and pagination.sort_semantics echoes.

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

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

Opens with a specific verb+resource+scope: "Browse and filter Meta creative families (source=meta only...)" and immediately delimits it against the sibling search_ads for TikTok. It also states the output shape ("return metadata only"), so an agent knows exactly what this tool is versus search_ads, search_hubs, or get_creative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit routing rules and alternatives: TikTok must use search_ads with source=tiktok and dedupe=true; download via get_media, save via add_to_favorites; get a max debit from estimate_cost before calling and tell the user. It also names the exclusions that change behaviour (ads_in_period_from not yet combinable with country, hub_category not combinable with country/channel).

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?

Adds rich context beyond the annotations: the catalog call is free, profile rows cost 1 MCP credit each, plan-window restrictions surface as total_status=restricted, and rate-limit/concurrency behavior is described. These details do not contradict readOnlyHint=true or destructiveHint=false.

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 and catalog-vs-drill-in distinction are front-loaded, but the description expands into long platform-wide sections on quota, rate limits, concurrency, and pricing that are generic and likely repeated across tools. It is organized but not tight.

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 13 parameters, an output schema, and read-only annotations, the description covers the remaining critical context: costs, plan-window restrictions, account linking, rate limits, and concurrency. An agent has enough to call the tool correctly without needing return-value 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%, so the schema already documents most parameters and the baseline is 3. The description still adds value with the limit range (1–200) and the combined country+relevance+exclude_cloaking recipe, which the schema does not spell out.

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?

Starts with a specific verb and resource: “Explore HUBS — where ads send traffic, grouped by destination,” and clearly separates the free catalog mode from the drill-in mode. It never names a sibling tool such as search_shops or search_ads, so it is clear but stops short of explicit sibling differentiation.

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 says “Call WITHOUT hub … FREE” and “Call WITH hub set to a slug …” and gives a concrete recipe combining country + sort=relevance + exclude_cloaking for per-geo rankings. It does not tell the agent when to choose a different sibling tool instead.

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 readOnly/openWorld; the description adds substantial non-obvious behavior: contacts are never returned, total_estimate is an estimate, subscription_locked produces teaser rows with stats_hidden and no second page, quota is 1 credit per row with refunds, and pricing scales with the number of filters set. This is exactly the context the annotations cannot supply.

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

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

Front-loads resource and required parameter, then filters, then rows, then commercial terms — a sensible order. It is dense and long, with some schema-restating detail (row field list) that could be trimmed, but nearly every sentence carries operational value.

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-parameter, paid, quota-metered search tool this covers everything an agent needs: pagination constraint (limit ≤ 10, offset multiple of limit), locked-subscription degradation, cost preview workflow, and output limitations. The output schema exists, yet the description still flags the fields callers must not expect (emails, bios).

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?

Even at 100% schema coverage the description adds real meaning: country matches the creator's country not the audience's, category/niche are exact-match directory labels with enumerated YouTube examples, sort is followers-only on Instagram, and Instagram rows lack niche/avg_views/lang_hint. It also clarifies lang_hint is a writing-script hint, not a language.

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

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

Opens with a specific verb+resource and scope: 'Search the INFLUENCER directory (the website's /influence page)', and defines the unit ('One row = one creator') plus the two supported platforms. This clearly separates it from get_influencer (single-creator lookup) among the siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete routing advice inside the tool: use q instead of category/niche 'when unsure of a label', platform is required, and specifies prerequisite workflow steps (estimate_cost for max debit, accept_pricing_terms consent). It does not explicitly contrast with sibling search tools or get_influencer, so it stops short of full when-not 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?

Beyond the annotations, it discloses quota costs, credit charging, rate limits, concurrency admission behavior, pricing mechanics, teaser blanking, free-plan archive restrictions, and the active_as_of snapshot semantics. These are material behavioral traits that an agent would otherwise not know from schema or 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 content is relevant and front-loaded, but the description is a very long, dense paragraph that is difficult to scan and repeats some schema details. Global pricing, quota, and concurrency notes are useful but make the definition heavy for a single tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 19 optional parameters, rich annotations, and an output schema, the description covers the operational context an agent needs: filtering semantics, pagination, totals, snapshot dates, quota costs, and edge cases. No critical calling information appears to be 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?

Although schema coverage is already 100%, the description adds substantial semantic guidance beyond the schema: q is a handle substring and not a title search, country is the shop's main visitor country and not the ad country, first_seen_days takes precedence over first_seen_from, and date_from/date_to describe launch-window matches including relaunches. It also clarifies total vs returned rows and special restricted-count 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?

The description opens with a precise verb and resource: searching e-commerce products that ads lead to. It defines the row granularity as one product page per shop and contrasts product counts with shop-level counts from search_shops/get_shop, so an agent can distinguish it from sibling 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?

It gives explicit when-to-use guidance for many ambiguous cases: q vs domain, first_seen_days vs first_seen_from, date windows vs first-seen filters, and active_only combined with first_seen_days. It also warns against using shop-level active_ads/total_ads as product counts and explains how to handle named products missing from handle 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 readOnly/openWorld/no-destruction, and the description adds substantial non-obvious behavior: per-result credit cost, free-sample preview caps, restricted pagination windows (total_status=restricted, plan_window_cutoff), and an empty page carrying an explanatory note. However it also spends a large share of its length on account-level concerns (quota balances, consent, concurrency admission, rate-limit error codes) that apply to many tools rather than this one, so the tool-specific behavioral signal is diluted.

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?

Roughly 700 dense words with the actual filtering guidance interleaved among pricing, quota, rate-limit and concurrency paragraphs that repeat verbatim-style boilerplate rather than telling the caller anything about search_shops. Several clauses restate the schema (fb_signal status list, sort_by enumeration, created_from/to semantics) instead of adding to it, so the high-value routing sentences are buried.

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 40-parameter open-world search with an output schema, the description still covers the things structured fields cannot: the free-sample distortion, the archive-window zero-means-nothing-in-window caveat, cost per delivered row, and the has_more/offset pagination contract. Nothing an agent needs to call or interpret results 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; the description earns above that by adding cross-parameter meaning the schema states only in isolation: sort_by=ads is active_ads not total_ads, country matches top_country (main visitor country) rather than any traffic, min_growth filters to growth_qualified rows, and traffic_start_max is meant to be paired with traffic_end_min.

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

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

Opens with a specific verb+resource and an explicit boundary: the /shops catalogue, not every domain (google.com, youtube.com excluded). It also names siblings it is not — 'do NOT use search_ads for this' and 'Use get_shop for the full source payload' — so an agent can route without opening another 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 an explicit recipe for a real task ('shops with fresh/active ads in Mexico': country + has_ads=true + sort_by=ads) and names the wrong tool to use. Also states a hard precondition (sort_by=relevance requires ai_category and is rejected otherwise) and where to go for detail (get_shop).

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 destructiveHint=false, but the description adds substantial behavioral context beyond them: 1 MCP credit per delivered row, 10 credits per delivered TikTok row, plan-based quota, rate-limit refusal semantics, concurrency gating, and the fact that unlinked agents receive an actionable connect-account refusal rather than a server error. It also discloses subtle correctness semantics — exact identifier lookups use current membership only, and plan-window narrowing makes a zero mean 'nothing in the archive window', not 'nothing 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?

The opening paragraph is well front-loaded, but the description then balloons into a multi-section manual covering pricing, rate limits, concurrency policies for unrelated tools (get_trends, search_ads, search_creatives), and a long field-by-field description of TikTok AD row shape that does not apply to this tool's webmaster-cluster output. Sentences such as the media-tt thumbnail and 'no TikTok engagement counters' notes do not earn their place here and actively blur what this endpoint returns.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present and 100% schema coverage, the description is more than complete on inputs, billing and access requirements. The gap is coherence rather than missing information: the long tiktok_data field enumeration describes ad rows, then the text later corrects itself with 'With source=tiktok rows are TikTok webmaster clusters', leaving the agent briefly unsure which return shape applies.

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. The description adds cross-parameter semantics the schema does not: sort_by=relevance requires countries, min_geo_share gates geo dominance vs mere presence, and Meta-only filters (languages/platforms/status_today/folder_id/saved) are rejected under source=tiktok before charging. It does not, however, explain every non-obvious parameter (e.g. saved=all vs folder_id) beyond what the schema already says.

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 first sentence gives a specific verb and resource and then defines the entity ('a webmaster is a whole ad NETWORK'), which is essential context an agent cannot get from the name alone. It also names the sibling tools that handle follow-on work (search_creatives, search_ads, get_webmaster.top_creatives, add_to_favorites), so the agent can place this tool in the workflow.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states an explicit copy workflow (search by domain, take the canonical UUID, then query search_creatives/search_ads with webmaster_id) and gives selection rules between modes, e.g. 'pass source="tiktok" to query the TIKTOK ad corpus' and 'For a geo ranking combine countries + min_geo_share + sort_by=relevance'. It also warns which filters are rejected in TikTok mode, which is unusable guidance without this text.

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