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

With no annotations, the description carries the burden and does well: it discloses 'No login required', that it runs on Apify as subimpact/bluesky-scraper-api, and an explicit pay-per-event cost model ($0.001/post, $0.002/profile plus platform usage). What's missing is behavior on failure/rate limits (only hinted at in the proxyConfiguration schema field) and what the response looks like.

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 capability statement, then a compact pricing/mode block. The pricing lines earn their place because cost is behaviorally important, though the 'Posts, Profiles, Threads & Followers' heading slightly duplicates the body sentence.

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

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

For a 10-parameter tool with no output schema and no annotations, the description covers cost, auth, and platform but never says what a scraped item contains (post text, engagement counts, author fields, etc.) or how results are paginated. An agent can invoke it, but cannot predict the return shape.

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's only added semantic value is tying per-item pricing to what gets scraped, which helps an agent reason about maxItems, but it adds nothing about the mode/handle/postUri relationships beyond what the schema already spells 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+resource statement: 'Scrape Bluesky posts, profiles, threads, and follower graphs by keyword, hashtag, or handle.' The mode enum and description map cleanly onto those resources, so an agent knows exactly what the tool retrieves and for which platform.

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 no explicit when-to-use/when-not guidance relative to the sibling tools (google_search, youtube, tiktok_hashtag, etc.), even though those are clearly adjacent social/search scrapers. Usage context is only implied by the mode list ('search', 'author_feed', 'thread'), which lives in the schema rather than the description.

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

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

With no annotations, the description carries the full burden. It usefully discloses the pay-per-event pricing model, Apify billing, and that it runs as an Apify Actor, but it does not describe auth requirements, rate limits, persistence of monitoring state across runs, or other operational constraints beyond cost.

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 reasonably short and front-loads the core capability before pricing and platform provenance. Some marketing language such as 'for HR-tech, VCs, and AI agents' is not essential, but the overall structure is efficient.

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 nine-parameter tool with no output schema, the description explains the source coverage and cost model but does not describe what the returned dataset looks like beyond saying it is normalized. It is adequate for invocation but leaves return-shape expectations partly inferred.

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

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

Schema description coverage is 100%, so the input schema already documents all nine parameters thoroughly. The description adds no parameter-specific meaning beyond repeating that monitoring exists and that results are normalized; 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: get live job postings from company career pages/ATS boards, normalized into one schema. It names supported platforms and mentions monitoring, so the core purpose is clear. It does not explicitly distinguish itself from sibling tools like google_jobs or google_maps_places.

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

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

The description implies usage for company career page monitoring and notes it is for HR-tech, VCs, and AI agents, but it does not explicitly say when to choose this over google_jobs or other job-related siblings. The monitoring angle is present, but alternatives and exclusions are left to inference.

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

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

With no annotations, the description carries the full burden, and it does disclose the most consequential trait for a paid scraper: pay-per-event pricing ($0.002/event), that platform usage is billed separately to the buyer's Apify account, and that the tool runs as an Apify actor. It omits auth/token prerequisites, failure behavior on bad place IDs, and runtime characteristics.

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 mode list, then pricing, then execution context — a sensible ordering. It loses a point for restating the $0.002/event cost twice in adjacent sentences, which is redundant rather than harmful.

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 23-parameter tool with no annotations and no output schema, the description covers what the tool does, the main usage modes, and the cost model, and it hints at return content ('venue + organizer data by default'). What it lacks is any statement about the response shape or that results are truncated by _maxItems; given the exhaustive schema, this gap is modest rather than crippling.

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 a mode taxonomy (location search vs URL mode vs organizer mode vs dryRun) that groups the 23 flat parameters into mutually exclusive operating shapes — a distinction not obvious from the schema alone. Individual parameter semantics are left entirely to the thorough schema descriptions.

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 ('Scrape Eventbrite events') and enumerates the operating modes (city/query/category search, URL mode, organizer mode, dryRun), which lets an agent tell it apart from the sibling scrapers (tiktok_hashtag, lazada_products, pinterest). It never names a sibling alternative explicitly, so it falls short of a 5.

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

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

The mode list ('Search by city/query/category, URL mode, organizer mode, dryRun') implicitly tells the agent which parameter family to reach for based on intent. It stops short of stating when not to use it or where the modes conflict (e.g. onlineOnly vs places, places requires radius), leaving that to the schema.

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

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

With no annotations, the description steps up well: it discloses the 60-second long-poll window, the retry loop, the dataset item cap, and the billing implication ('billed to your Apify account like any other run'). It never addresses failure modes for an invalid or expired runId, which keeps it from a 5.

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

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

Three tight paragraphs, front-loaded with the primary purpose, followed by return shape and the retry/billing caveats. No filler sentences.

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

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

With no output schema and no annotations, the description carries the burden and does describe the return (status, total item count, items). Only the error/invalid-run path is unaddressed.

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

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

Schema description coverage is 100%, so all four parameters are already documented in structured data. The description adds only marginal semantics by referencing the offset and _maxItems cap; it does not explain runId format or behavior beyond what the schema states.

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

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

States a specific verb (fetch) plus the exact resource (status and dataset items of an Actor run) and ties it to runs started by the data tools, which cleanly separates it from the sibling tools that initiate runs. An agent knows immediately this is the follow-up retrieval call.

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 the triggering scenario explicitly ('for example a run that was still running when its tool call returned') and the retry protocol ('if still running, call again with the same runId'). It does not name a when-not-to-use condition, but the context is unambiguous.

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

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

No annotations are present, so the description must carry the burden. It usefully discloses pay-per-event pricing, Apify billing, and that no browser is needed, which are important behavioral traits. It still omits some operational details such as rate limiting and proxy requirements, which appear only in the schema.

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

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

The purpose and output scope are front-loaded, making the description easy to scan. However, the pricing is stated twice (once as per-1,000 rates and again as per-event rates), which is redundant and slightly bloats the definition.

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

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

There is no output schema, but the description lists the key ad fields returned and explains region filtering and advertiser lookup. Combined with a fully documented input schema, this is nearly complete for a scraper, though it could more clearly distinguish advertiser rows from ad rows.

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 already 100%, so the schema documents all ten parameters thoroughly. The description only restates high-level concepts like searching by name or ID and filtering by region, adding little parameter 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 description names a specific verb (scrape), a specific resource (Google Ads Transparency Center), and the exact scope (advertisers and ads). It also lists the returned ad fields, so an agent can tell what this tool produces without opening the schema.

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

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

It implies usage by saying you can find advertisers by name or ID and export their ads filtered by region. However, it does not explicitly state when to use this tool versus another sibling, nor does it give exclusions or prerequisites beyond that implied 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?

With no annotations, the description carries the behavioral burden and does disclose useful traits: pay-per-event pricing, billing to the Apify account, free failed and empty queries, uncited answers flagged, and real Android Chrome rendering. It does not cover authentication requirements or broader rate-limit behavior outside the schema.

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

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

The description is front-loaded with what the tool returns and is mostly efficient. However, pricing is repeated twice ('From $0.0018 per answer...' and 'AI Mode search completed: $0.003'), and the 'Runs on Apify as...' line adds little for tool selection.

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 13 parameters, no annotations, and no output schema, the description covers the output shape (answer, structured blocks, citations), billing model, and key behavioral caveats like uncited flagging. It lacks explicit use-case routing versus siblings and auth details, but the rich schema compensates for most parameter gaps.

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

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

Schema description coverage is 100%, so all 13 parameters are already documented in the schema, including caching, concurrency caps, and spending limits. The description adds only high-level pricing context and no parameter-specific meaning beyond what the schema provides; 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 resource and output: real Google AI Mode answers from the udm=50 tab, including full answer, structured blocks, resolved source URLs, and per-paragraph citations. It clearly distinguishes itself from a generic search result, though it does not explicitly name or differentiate from sibling google_search.

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

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

Usage is implied by 'for any country and language' and the emphasis on AI Mode-specific answers, but there is no explicit when-to-use guidance versus google_search or other siblings, nor any stated exclusions. The agent must infer that this is for AI Mode answers specifically.

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

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

With no annotations, the description carries the full behavioral burden and usefully discloses that the tool runs without a browser, runs on Apify, bills per job and for proxy usage, and lists the fields returned. It does not cover authentication details, rate limits, or reliability characteristics, but the cost and execution model disclosure is strong.

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 generally front-loaded and appropriately sized, starting with the purpose and output fields. The pricing is stated twice in slightly different forms, which is redundant, but the overall structure remains efficient.

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

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

There is no output schema, so the description appropriately lists the fields returned, and it also explains the no-browser execution and billing model. Given the fully documented input schema, the main remaining gap is the absence of guidance on alternatives or operational constraints like rate limits.

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 input schema already provides detailed parameter semantics. The description only implies query and country inputs and adds no parameter-level meaning beyond what the schema documents.

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

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

The description states a specific verb and resource: scrape Google Jobs listings by query and country, and it lists the returned fields. It is clear what the tool does, but it does not explicitly distinguish itself from sibling tools such as company_career_jobs or google_search.

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

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

The description explains what the tool does but gives no explicit guidance on when to use it instead of alternatives like company_career_jobs or google_search. Usage is only implied by the purpose statement.

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

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

With no annotations, the description carries the whole burden and does substantial work: it discloses the plain-HTTP/no-browser approach, per-event pricing ($0.001/place, $0.0005/review), the spending-cap mechanism, and that _maxItems truncates only the response, not collection or charges. It omits auth requirements, expected run duration, and failure/rate-limit behavior.

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 extraction capability and fields, followed by pricing and hosting details. The pricing paragraph is somewhat verbose and partly duplicates schema-level cost notes, but every block is separated and scannable; nothing is buried mid-sentence.

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

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

For a 13-parameter, no-output-schema tool the description compensates well by enumerating returned fields and disclosing cost behavior. Remaining gaps are the response shape (dataset item structure), run latency, and how the three input modes (search strings, placeIds, startUrls) relate when combined.

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 value by tying cost semantics to parameters ('$1.00 per 1,000 places', per-review charges), which clarifies the financial impact of maxReviews and maxCrawledPlacesPerSearch beyond their schema text. It does not explain the interaction between lat/lng and searchStringsArray, which the schema does cover.

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 (extract Google Maps places) and enumerates the returned fields (title, address, phone, rating, hours, place ID, etc.). It also distinguishes the two input modes: keyword+location search versus direct place-ID lookup, so an agent can tell it apart from sibling tools like google_search or website_contacts.

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

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

The description implies usage via 'Search by keyword + location or place IDs' and the schema notes hint at exact-lookup vs discovery, but it never explicitly says when to prefer this over siblings such as google_search, nor when not to use it. Guidance is implied rather than stated.

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

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

No annotations are provided, so the description carries the full burden. It does add real behavioral context that structured fields don't: pay-per-event billing to the Apify account, $0.003 per Google SERP, ~$1.80 per 1,000 queries, and the underlying Actor (subimpact/google-serp-ai-overviews). However, it says nothing about failure/partial-result behavior, AI Mode vs classic AI Overview routing, or default retry behavior — all of which materially change what comes back and are buried in parameter text.

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 one-line purpose, then return contents, then scale, then pricing — a sensible ordering with little waste. The pricing and Actor-name lines are sales/origin metadata rather than invocation guidance, which slightly dilutes the signal, but the whole thing is short enough that no sentence is a real burden.

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 21 parameters, no annotations, and no output schema, the description should do more than list result modules. 'One row per query' hints at the response shape but doesn't say what a row's fields look like or what happens on AI-Mode serves, deferred AI Overviews, or Partial rows — behaviors an agent must understand before tuning the many retry/exclusion flags. Adequate as a front door, incomplete for this tool's complexity.

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% across 21 parameters, so the schema already documents each field thoroughly. The description contributes only the batching ceiling ('Batch up to 1,000 queries'), which merely restates the queries array constraint. Baseline 3 is appropriate when the schema does all the semantic 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?

The description states a concrete verb+resource — Google SERP scraping with AI Overviews — and enumerates exactly what is returned (AI Overview answers with lists/citations/sources, organic results, People Also Ask, knowledge graph, top stories, local results) in one row per query. It is clear and specific, but it never distinguishes itself from the sibling google_ai_mode, which an agent could easily confuse with this tool.

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

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

There is no when-to-use / when-not-to-use guidance and no named alternative. The reader must infer from the feature list that this is for bulk SERP retrieval, and the presence of google_ai_mode and google_trends as siblings makes the lack of routing guidance a real gap. Batch size (up to 1,000 queries) and price are stated, but those are limits, not selection criteria.

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

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

With no annotations, the description carries the full burden and does disclose cost behavior ('$2.50 per 1,000 keywords, charged only for delivered keywords', platform usage billed to the Apify account) plus the access profile (keyless, no browser, no captcha) and the batching constraint. It stops short of describing the actual dataset item shape or failure modes, which matters since no output schema 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?

Capability statement is front-loaded, followed by access/cost qualifiers and the actor identifier. Every line carries distinct information (what it scrapes, cost, batching, runtime) with no filler.

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

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

For a 16-parameter tool with no annotations and no output schema, the description covers cost, batching, keyless access, and the three output modes well, and the per-parameter schema is fully documented. What is missing is a description of the returned dataset items/fields, which the agent must infer from the include* booleans.

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 reinforces the '5 keywords per call' comparison limit for the keywords param and the per-keyword billing model, but adds no syntax, format, or interaction detail the schema does not already give.

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 line names a specific verb and resource ('Scrape Google Trends interest-over-time, related queries/topics, and per-region interest for keywords') and enumerates the three output modes. No sibling tool (google_search, google_ads_transparency, youtube) overlaps this scope, so an agent can select it unambiguously.

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

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

Usage is implied rather than stated: 'No API key, no browser, no captcha' and the per-keyword pricing tell the agent this is the cheap keyless route for Trends data, but there is no explicit when-to-use/when-not or named alternative. The batching note ('Up to 5 keywords compared per call') is the closest thing to operational 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?

With no annotations, the description carries the full burden and does disclose useful traits: no browser/API keys/LLM, Apify execution, free first pages, and per-event pricing. It still omits return shape, rate/error behavior, and account/auth prerequisites beyond the implication that billing is tied to an Apify account.

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 capability, followed by differentiators, pricing, and Actor identity. It is fairly tight for a complex tool, though the pricing and platform lines add some length that is only marginally useful to selection.

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?

It conveys the main function, validation scope, graph-resolution behavior, and cost model. But for a ten-parameter tool with no output schema and no annotations, it should explain the dataset-item/result structure and validation-report shape more explicitly.

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 ten parameters in detail. The main description does not map or add syntax for parameters like resolveGraph, validateSchema, estimateOnly, or maxChargeUsd, so the baseline of 3 applies.

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

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

It uses specific verbs and resources: extract JSON-LD, validate against Schema.org, and resolve blocks into a unified knowledge graph. The JSON-LD entity-graph focus distinguishes it from generic page scrapers and SEO audit 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?

Usage is implied by the extraction/validation/graph-resolution purpose and the note that no browser, API keys, or LLM are needed. However, there is no explicit when-to-use, when-not-to-use, or comparison to alternatives such as web_page_markdown or seo_page_audit.

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

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

With no annotations, the description carries the full disclosure burden and does meaningful work: it requires a residential proxy because Lazada blocks datacenter IPs, states billing is a pay-per-event model charged to the Apify account, and names concrete event prices. It stops short of describing failure modes, anti-bot blocking behavior, or what a run returns.

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 lead sentence is well front-loaded, but pricing is stated twice — once in the summary line and again as a standalone 'Pricing (pay per event...)' paragraph that largely repeats the same figures. That redundancy and the marketing tagline consume space without adding 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?

There is no output schema, so the description should say something about what a run yields (product fields, alert payload shape), but it only says alerts POST 'JSON' to a webhook. Cost, proxy, and market coverage are covered adequately, leaving the return-value gap as the notable hole for a 14-parameter tool.

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

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

Schema description coverage is 100%, so all 14 parameters are already documented with defaults, enums, and constraints in the schema. The description adds no parameter-level guidance beyond restating the pricing that maps to maxResultsPerQuery. Baseline 3 applies.

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

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

The opening states a specific verb and resource: scrape Lazada search results and category pages across six SEA markets, plus price/stock monitoring. It is unambiguous what the tool does, though the sibling list contains no other Lazada tool, so no explicit differentiation is needed or provided.

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 frames the tool as scraping plus monitoring but never says when to enable `monitor` versus a one-off scrape, nor when to prefer scheduled runs over a single call. Usage conditions are only implied through the schema's per-parameter descriptions, not the tool description itself.

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

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

With no annotations, the description carries the full burden and does a decent job: it discloses the paid, per-article billing model (Article: $0.001 plus platform usage) and describes the response shape (title, snippet, publisher URL, source, region, topic, language, publish time). It does not cover authentication/setup (Apify account/token) or whether results come back synchronously versus requiring a run/poll workflow, which is a notable gap for an actor-based 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 purpose and return shape, then cost, then platform. The pricing sentence is slightly marketing-flavored but is legitimately useful cost transparency. Four short paragraphs with little waste.

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

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

For a 16-parameter, no-annotation, no-output-schema tool, the description covers purpose, output fields, and cost model, which is most of what an agent needs. What is missing is operational context—whether the call returns dataset rows directly or triggers an Apify run that must be retrieved via get_run_results—which matters given that sibling tool exists.

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 every one of the 16 parameters is already documented in detail (query syntax, delta mode, state keys, lookback, spending cap). The description adds only a high-level mention of keyword searching and returned fields, so per the coverage rule the baseline of 3 applies.

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

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

The description names a specific verb (search) and resource (a curated index of publisher news feeds), and enumerates the returned fields and target use cases (brand/PR monitoring, competitor tracking). That is far more than a restatement of the name. It stops short of explicitly distinguishing itself from general-search siblings like google_search or google_ai_mode, leaving the agent to infer that this tool is news-index-specific.

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

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

It gives clear usage context: 'Built for brand/PR monitoring, competitor tracking and market news in Malaysia, Southeast Asia and worldwide,' which signals when the tool is a fit. It does not name alternatives or state exclusions (e.g., when to prefer google_search over this index), so it is a solid 4 rather than 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?

With no annotations, the description carries the behavioral burden and does well: it discloses the HTTP-only/no-login/no-proxy access model, output content such as full-res images, video variants, board/pinner metadata and repin counts, and per-event pricing. It does not cover rate limiting, failure modes, or full dataset structure, but the core operational traits are present.

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 what the tool does, then layers in key operational traits and pricing without padding. Every sentence contributes useful selection or cost 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?

For a complex 14-parameter scraper with no annotations and no output schema, the description supplies the essential context: access model, billing, and the kinds of data returned. Detailed parameter behavior is covered by the very rich schema, though the description stops short of fully describing the output dataset shape.

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 14 parameters in detail. The description adds high-level context about the supported modes and billing model but does not add parameter-level meaning beyond what the schema provides, making the baseline 3 appropriate.

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

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

The description states a specific verb and resource — scraping Pinterest pins — and names the three supported modes: keyword search, boards, and profiles. The Pinterest focus clearly distinguishes it from the other social/scraping siblings such as tiktok_hashtag or youtube.

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

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

The description implies the tool is for Pinterest pin scraping across search, boards, and profiles, but it does not explicitly say when to choose this over alternatives or when not to use it. Mode selection guidance lives in the schema rather than the description.

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

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

With no annotations, the description carries the burden and does so well on cost/behavior: per-event pricing ($0.001 for each mode), no API keys required, Apify-hosted run, platform usage billed. It stops short of describing failure modes, rate limits, or what the audit record contains, keeping it below a 5.

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

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

Front-loads the capability in the first paragraph before pricing and hosting details. All sentences are relevant, though the pricing/platform paragraph is slightly verbose and could be compressed. No wasted 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 10-parameter tool with no annotations and no output schema, the description covers purpose, cost, and modes but never describes the shape of the returned audit record or SERP preview result (beyond 'truncation flags'). An agent knows how to call it but not fully what to expect back, leaving a meaningful gap.

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

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

Schema description coverage is 100%, so every parameter is already documented (mode enum, pageUrls, _maxItems vs collection distinction, _maxChargeUsd cap). The description adds little parameter-level meaning beyond the pricing context that clarifies the charge cap. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

States a specific verb+resource: 'full on-page audits per URL (meta tags, headings, images, links, structured data, hreflang) plus Google SERP snippet previews.' The two modes and concrete data captured are named explicitly, so an agent knows exactly what it produces. Siblings like web_page_markdown or jsonld_entities overlap thematically, but the description's 'audit + SERP preview' framing is distinctive enough to differentiate.

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 two modes are described in the schema ('onpage = audit URLs; serp_preview = Google snippet preview'), which implies when each applies, but the description itself gives no explicit when-to-use/when-not guidance or routing to overlapping siblings (jsonld_entities for structured data, web_page_markdown for raw content). Usage is implied rather than stated.

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

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

No annotations are provided, so the description carries the full burden; it does disclose the cost model (per-run, per-row, billed to the Apify account), which is genuinely useful behavioral context that the schema only partly complements via the _maxChargeUsd cap. However, nothing is said about authentication, rate limits, failure behavior, or what a 'row' contains — significant omissions for a paid scraping actor.

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 text is short and front-loaded with a label, but the majority of the body is Apify billing and hosting detail rather than functional description. Nothing is padded word-by-word, yet the allocation of space is skewed away from what the tool does.

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 a rich 6-parameter schema with full coverage, a mode enum, and explicit cost caps, plus no output schema, the description is close to sufficient — the pricing disclosure is the one piece of information an agent genuinely cannot get from structured fields. What remains missing is a one-line statement of what a run returns, which is a modest gap for a scraper tool.

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

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

Schema description coverage is 100%, with an enum explaining the three modes and clear descriptions for postSlug, maxItems, _maxItems, and _maxChargeUsd, so the baseline of 3 applies. The description adds no parameter-level meaning beyond hinting at chargeable events ('Post or publication row'), which only loosely maps to maxItems.

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 is a heading — "Posts, Archives & Publication Stats" — plus pricing boilerplate; it names the resource domain but never states a verb or that the tool scrapes/fetches Substack data for a given publication slug. An agent can infer retrieval from the schema's mode enum, not from the description itself. No sibling is a Substack tool, so differentiation pressure is low, but the purpose statement is still too 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?

There is no guidance on when to use this tool versus alternatives, no mention that the publication slug or custom domain is the entry point, and no explanation of when to pick archive vs. post vs. publication mode — that routing lives entirely in the schema. Nothing in the description tells the agent the conditions that select this tool.

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

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

With no annotations provided, the description carries the behavioral burden and usefully discloses pricing ($0.001 per video), pay-per-event billing to the Apify account, and that it runs on Apify. It does not cover authentication needs, rate limits, or data freshness, so it falls short of full transparency.

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 main purpose and includes cost information early. It contains some marketing phrasing such as “ultra-competitive price” and a redundant title-like opening, but remains compact and readable.

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 six-parameter scraper with full schema descriptions and no output schema, the description supplies enough context about what data is extracted and the billing model. It does not mention validation mode or spending caps, but those are already documented in the schema.

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

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

Schema description coverage is 100%, so the input schema already explains all six parameters in detail. The description adds only the high-level idea of hashtag extraction and does not supplement parameter meaning beyond the schema, matching the baseline for high coverage.

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: it scrapes TikTok hashtag data and extracts videos, views, likes, comments, shares, audio details, and creator profiles. It clearly identifies the platform and hashtag-based scope, though it does not explicitly differentiate from any sibling tool.

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

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

Usage is implied by “extract videos... by hashtag,” making it clear this tool is for TikTok hashtag research. However, the description does not say when to use it versus alternatives, nor does it provide prerequisites or exclusions.

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

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

With no annotations, the description carries the full burden and does substantial work: it discloses the per-page cost ($0.001), that billing goes to the Apify account, and critically that extraction is raw HTTP with no browser, which tells the agent JS-rendered pages may fail. It stops short of describing return structure, failure/blocking behavior, or how run outcomes are surfaced.

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

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

The core purpose is front-loaded in the first two sentences, but pricing is stated twice (prose and a separate 'Pricing' block) and the closing 'Runs on Apify as subimpact/rag-web-browser-lite' is packaging rather than 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?

For an 11-parameter, zero-annotation tool with no output schema, the description covers the cost model and the no-browser constraint but never explains what a returned item looks like (SERP metadata plus page content per outputFormats) or what happens on partial failures. That leaves the agent guessing about result shape despite the cost-based, per-page billing model.

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 all 11 parameters in detail, including maxResults being ignored when query is a URL. The description adds no parameter-level meaning beyond what the schema states, so the baseline 3 applies.

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

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

The description states a specific verb pair and resource: it queries Google Search, scrapes the top N pages, and returns Markdown. This corrects an uninformative tool name (web_page_markdown) by revealing that search is part of the operation. It does not, however, explicitly contrast itself with the google_search or seo_page_audit siblings, so an agent must infer the distinction.

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

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

Usage is implied rather than stated: 'for AI agents and RAG pipelines' plus the query field taking either keywords or a URL hints at search-then-fetch use cases. There is no explicit when-to-use/when-not guidance and no mention of when to prefer the plain google_search sibling instead of paying for page extraction.

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

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

With no annotations, the description carries the burden well by disclosing plain HTTP/no browser operation, robots.txt compliance, per-page pricing, no per-lead fee, and Apify billing behavior. It could say more about rate limiting or output structure, but the core behavioral traits are covered.

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

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

The description is front-loaded, with purpose and extraction targets stated first, followed by technical and pricing details. It is appropriately sized, though the title-like first line and Apify actor attribution are slightly 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?

For a nine-parameter scraping tool with no output schema and no annotations, the description covers the essential purpose, safety constraint, and billing model. It stops short of describing the output row structure, but the schema compensates for most input semantics.

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 parameters are already well documented. The description adds cost context such as '$0.80 per 1,000 pages scanned' and 'no per-lead fee,' but it does not add parameter-level 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 states a specific extraction verb and concrete resources: emails, phone numbers, and social profile links from a list of websites. It is clear what the tool does, though it does not explicitly differentiate itself from sibling scraping tools such as web_page_markdown or seo_page_audit.

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

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

Usage is implied by 'from any list of websites' and the robots.txt note, but the description gives no explicit when-to-use, when-not-to-use, or alternative-tool guidance. An agent can infer its role, but the routing guidance is thin.

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

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

With no annotations, the description carries the full burden, and it does disclose the cost model ($1.00 per 1,000 results, per-event billing to the Apify account) and the no-browser/no-API-key execution profile — genuinely useful behavioral context. It does not describe the dataset/row output shape, run latency, or failure modes, leaving meaningful gaps for a 22-parameter scraping run.

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?

Capability statement comes first and is dense and useful. Minor waste: pricing is stated twice ('$1.00 per 1,000 results' and 'Result: $0.001'), and 'Fast … no browser and no API key' is marketing framing rather than decision-relevant detail.

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 22-parameter, nested-object, no-output-schema tool, the description covers input modes and cost but says nothing about the returned dataset structure beyond scattered mentions of 'comment' and 'channel' rows, and nothing about the Apify account/token prerequisite. Adequate to start a run, not complete enough to predict results.

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% with per-parameter descriptions, defaults and enums, so the baseline is a 3. The description lifts it slightly by naming the output modes the parameters switch between — exact likes/date/description via enrichment, comments with replies, channel About rows — giving the agent a reason to flip those flags rather than just their syntax.

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 concrete resource set (videos, Shorts, channels, comments, playlists, channel About data) and the supported access modes (keyword search with filters, channel URLs, playlist URLs). The platform name alone separates it from siblings such as tiktok_hashtag or pinterest, so an agent can route to it without opening the schema.

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

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

Usage is only implied: the description lists the capabilities (search, channel, playlist, comments), from which an agent must infer that it should supply searchQueries or startUrls. There is no explicit statement of when to prefer this over google_search or web_page_markdown, and no exclusions or prerequisites beyond 'runs on Apify'.

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