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 critical behavioral context beyond that: it costs $0.004 per page billed to an Apify account, unreachable pages are free, crawling multiplies cost, and maxTotalChargeUsd caps spend. It also mentions it runs an Apify actor with APIFY_TOKEN and synchronous timeouts. This fully discloses the cost and execution side-effects, going well beyond the annotation hints.

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 information-dense but well organized: it opens with the core function, then usage triggers, then cost and execution details. Every sentence adds value. It is longer than a single sentence but justified given the cost model and crawling behavior. It is front-loaded with the primary purpose, so an agent can quickly decide if it is the right 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?

For a tool with 6 parameters, no output schema, and cost implications, the description is remarkably complete. It covers the input (URLs), the optional behaviors (broken links, crawl), the output (0-100 score and issue list), the cost model, and the spending cap. An agent has everything needed to decide whether to call it and how to set parameters responsibly. The lack of an output schema is mitigated by the explicit description of the return format.

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 six parameters. The description adds valuable semantics: it explains that maxPagesPerSite defaults to 1 and that higher values crawl internal links, each page charged; it explains checkBrokenLinks as 'optional broken-link checking'; and it ties cost to pages. This enriches the schema meaning without redundancy. A small gap is not elaborating on maxLinksToCheckPerPage, but the schema does.

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 ('Run'), a precise resource ('on-page SEO audit'), and enumerates the exact checklist (title, meta, headings, canonical, indexability, structured data, Open Graph, images, speed, robots.txt, sitemap, llms.txt, AI-crawler blocking) plus optional broken-link checking and crawling. It also gives explicit triggers ('when asked to audit, review or improve a site's SEO, or to compare pages'), clearly distinguishing it from sibling tools like check_domain_authority or check_website_traffic_rank.

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 states when to use the tool ('Use it when asked to audit, review or improve a site's SEO, or to compare pages'). It does not explicitly name alternative tools or exclusions, but the purpose is clear enough and the description adds cost guidance (unreachable pages free, crawling multiplier, spending cap) that helps an agent decide whether to invoke it. A slight gap is not naming sibling tools for contrast, but this is minor.

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 far richer behavioral context: current 'coming soon' status and error behavior, cost per domain, free unranked/invalid domains, performance expectations ('thousands of domains finish in seconds'), the underlying Apify actor and APIFY_TOKEN requirement, and the maxTotalChargeUsd hard cap. Nothing contradicts the annotations; the description exceeds the transparency burden.

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

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

The description is long (~250 words) and front-loads the critical 'coming soon' status and error/charge behavior, then moves through definition, use cases, exclusions, and pricing in a logical order. Nearly every sentence adds a distinct piece of information, but there is slight redundancy (e.g., maxTotalChargeUsd is already described in the schema) and the text could be tightened without losing 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?

There is no output schema, yet the description enumerates the return values in prose: authority score, harmonic-centrality rank, PageRank rank, top-% percentile, subdomain count, and rank change/trend, plus the ranked=false state for unranked domains. It also covers input constraints, cost, timeout, availability, and response behavior, giving an agent sufficient context to invoke the tool and interpret 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%, so the baseline is 3. The description enriches the parameters by explaining input normalization to registrable domains, duplicate removal, the ranked=false threshold (score below 20), and cost/spend-cap semantics tied to maxTotalChargeUsd. It does not add JSON syntax details, but it adds meaningful behavioral 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 uses a specific verb ('Score') and precisely defines the resource and output: a 0-100 authority score computed from the Common Crawl web graph. It further distinguishes itself by stating it is an independent open metric, NOT Moz Domain Authority or Ahrefs Domain Rating, and clarifies that it does not return backlinks or visit websites. Even without naming sibling tools, it is behaviorally unique and clear.

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

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

The description provides explicit use cases: 'Use it for link-building and outreach prospect lists, guest-post or PR vetting, expired-domain research, lead scoring and competitor tracking.' It also gives negative guidance ('does not return backlinks and visits no website'), which tells an agent when not to choose it. However, it never names alternative sibling tools or states 'if you need X, use Y', so it stops short of full tool-selection routing.

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

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

The description goes well beyond the annotations (readOnlyHint=true, destructiveHint=false). It discloses the 'coming soon' status and its error behavior, the fact that it does not visit websites, the ranked=false outcome for unranked domains, cost per domain, and the spending cap behavior. This is rich behavioral context that an agent needs to handle calls correctly.

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

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

The description is long but every sentence conveys necessary information. It is well-structured: it begins with the critical 'coming soon' caveat, then explains the tool's purpose, data sources, outputs, use cases, limitations, and cost. It is not concise in word count, but it is efficient in packing value without redundancy, earning a 4 rather than a 3.

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 4 parameters and no output schema, the description does a thorough job of covering what an agent needs: it describes the output fields (countryRanks, topCountries, ranked=false), error behavior, cost, and how parameters affect results (includeCountries flag). It even notes the behavior for subdomains and timeout handling. The description is complete for correct invocation and expectation setting.

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

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

Schema coverage is 100% and each parameter has a description. The tool description adds extra meaning beyond the schema: it explains subdomain fallback behavior, the default for maxTotalChargeUsd with a server setting, and advises splitting batches to avoid timeout. This adds practical guidance not present in the schema, elevating the value above the baseline of 3.

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

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

The description clearly states the tool's function: checking website traffic ranks and popularity tiers. It specifies the resource (websites) and the verb (check), and details exactly what it outputs (global tier, country tiers, Majestic rank, etc.). It also distinguishes itself from alternatives by noting it gives tiers, not exact positions or monthly visit counts, and that it does not visit websites.

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 lists use cases: lead scoring, competitor and market research, vetting publishers, affiliates, link-building targets, and market sizing by country. It also sets expectations for when results are free (ranked=false) and notes the tool's limitation (tiers, not exact numbers), implying alternative tools are needed for exact data. This is helpful, though it does not explicitly name sibling tools as alternatives.

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 substantial behavior beyond the annotations: cost per document, unsupported/failed files being free, execution via the Apify actor with APIFY_TOKEN, and the maxTotalChargeUsd spending cap. These operational side effects are not inferable from readOnlyHint or openWorldHint.

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

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

The description is dense but well organized: function and formats, return value, use case, then cost and execution details. Every sentence earns its place 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?

With no output schema, the description compensates by naming the return values: Markdown, title, page and word counts, and optional chunks. It also covers cost, failure behavior, and batch limits, giving the agent enough context to invoke the tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description mostly restates schema content such as chunking, file-type detection, and the spend cap rather than adding genuinely new parameter-level meaning.

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?

Clearly states the action: download documents from public URLs and convert them to clean Markdown, followed by a concrete list of supported formats. This separates it from sibling tools like download_images or extract_text_from_image by focusing on document-to-Markdown conversion.

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 'Use it when you need to read, summarize, quote or index a document that is only reachable by link.' It does not name explicit alternatives or when-not conditions, but none of the sibling tools competes directly with this conversion task.

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 readOnlyHint and destructiveHint annotations, the description discloses significant runtime behavior: it 'Runs the Apify actor kantolabs/website-tech-stack-detector with your APIFY_TOKEN,' defines the per-site cost of $0.003, states 'failed or unreachable sites are free,' and explains that maxTotalChargeUsd is a hard spending cap. This gives the agent a clear picture of side effects, cost, and failure handling that annotations alone do not convey. No contradictions with annotations.

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

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

The description is multi-sentence and somewhat lengthy, but every sentence carries information: purpose, fingerprint count, use cases, read-only nature, cost, actor name, token, and spending cap. It is front-loaded with the core purpose, then details. It could be tightened (e.g., merging cost and actor lines), but it is not bloated or redundant. Minimum viable conciseness for the richness of information provided.

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 there is no output schema, the description adequately explains what the tool returns: 'technologies ... with versions and confidence.' It covers the full lifecycle: what it detects, when to use it, safety (read-only), cost, failure behavior, and execution mechanism (actor and token). The 5 parameters are all described in the schema, and the description adds usage nuance like batching. Nothing critical is missing for correct invocation.

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 each parameter with defaults and constraints. The description adds value beyond the schema by explaining the cost model tied to urls ($0.003 per site), the billing to Apify account, and the purpose of maxTotalChargeUsd as a 'hard spending cap.' These operational details are not in the schema and help the agent reason about cost and limits. Baseline 3, but the extra context justifies a 4.

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: 'Detect the technologies a website runs on' and enumerates the categories (CMS, ecommerce, frameworks, analytics, ad tags, CDN, hosting, payment, marketing tools). It explicitly positions it against sibling tools by noting its niche ('website tech stack' detection) and mentions concrete use cases like lead qualification and competitor research, making the tool unmistakably distinct from audit_website_seo, check_website_traffic_rank, and similar siblings.

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

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

The description states specific scenarios: 'Use it for lead qualification, competitor research, sales prospecting or "what is this site built with?" questions.' It also provides operational guidance: 'Reads only the public page, one request per site,' warns about cost, and even recommends splitting large batches in the timeoutSecs parameter. Though alternatives aren't named, the use cases are explicit and sufficient for an agent to route correctly.

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

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

Discloses critical behavioral facts beyond annotations: the actor is not yet public and calls currently return an error with no charge, billing is $0.002 per saved image, duplicates/filtered/failed images are free, and maxTotalChargeUsd caps spend. It also warns about legal use rights and refused sources. Annotations are not contradicted.

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 a dense but well-organized paragraph that front-loads the most important fact (coming soon, not callable yet) before capabilities, use cases, restrictions, cost, and invocation details. It is slightly long, but justified given 14 parameters and no output 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?

For a complex tool with 14 parameters and no output schema, the description explains not only invocation but also the return value (public download URL, dimensions, format, alt text, SHA-256), cost model, legal constraints, and runtime limits. Nothing essential for an agent to decide whether and how to call it 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 schema already documents each parameter in detail. The description adds useful cross-parameter guidance, e.g. 'A page can hold hundreds of images, so set maxImagesPerPage and minWidth to control cost', and clarifies the cost implications of parameters like dedupe and filters.

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: 'Download every image from web pages... and/or from direct image links', with concrete details on sources (img tags, srcset, lazy-load, CSS backgrounds) and processing (filters, de-duplication, conversion/resizing). It clearly distinguishes this bulk-download tool from sibling tools like search_free_images or extract_text_from_image.

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 use cases: collecting product photos, gallery/article images, or re-hosting/converting image links. It also provides exclusions ('social networks and stock-photo sites are refused') and practical guidance on cost control. It doesn't name sibling alternatives explicitly, but the 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?

Goes far beyond annotations, disclosing the current 'coming soon' error state, zero-charge behavior until public, per-enrichment cost, free cases (unreachable domains, unknown names, invalid inputs), use of the Apify actor with APIFY_TOKEN, and the maxTotalChargeUsd safety cap. It also states a privacy guarantee (no personal data), which annotations do not cover. No contradiction with 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?

The description is long but information-dense; it front-loads the time-sensitive 'coming soon' caveat, then follows a logical flow from purpose to output fields to cost and auth. Some redundancy with schema (e.g., spend cap) but most sentences earn their place.

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

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

With no output schema and a tool of this complexity, the description covers input types, output categories, matching limitations, cost, auth, and safety cap. It addresses free and charged cases and the current non-public status, leaving no critical gap for an agent deciding whether and how to call it.

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

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

Schema coverage is 100% with descriptive parameter comments, but the description enriches semantics by clarifying that names only match well-known organizations on Wikidata and that domains give exact matches. It also explains cost implications of maxTotalChargeUsd, adding decision-relevant 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 opens with the core transformation ('Turn domains, website URLs, email addresses or company names into company profiles') and enumerates specific outputs from website and Wikidata, making the purpose unmistakable. It differentiates from sibling domain-analysis tools (lookup_domain, check_domain_authority) by focusing on company profile enrichment rather than standalone technical or SEO metrics.

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

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

Provides explicit use cases (CRM enrichment, sales research, market maps) and input guidance ('pass a domain for an exact match'; 'small businesses usually get the website fields only'). It doesn't name alternative tools or state when not to use it, but the context is clear enough for an agent to choose appropriately.

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 readOnlyHint=true, but the description adds substantial behavior beyond that: it runs an Apify actor, requires APIFY_TOKEN, has per-page billing, enforces a spending cap, and treats PDFs with text layers differently. It even notes failed downloads and empty pages are free. No contradiction with annotations; this is rich, honest disclosure.

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

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

The description is long but densely informative, front-loaded with the core function before cost and backend details. Every sentence earns its place—formats, languages, alternatives, billing, and token usage are all relevant. It is structured logically, though a touch verbose for agents that prefer brevity.

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

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

With no output schema, the description explains the return value ('reading-order text per image or PDF page with an average confidence, and optionally every line with its pixel bounding box'). It covers cost, failure cases, input limits, and batching advice, making it fully sufficient for an agent to call the tool correctly.

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

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

Schema coverage is 100%, so each parameter has a basic description. The tool description adds meaningful context: it ties quality to cost, explains that each image/PDF page is one charged result, clarifies pdfMode behavior, and warns about output size for includeLines. This goes beyond the schema without duplicating it, though it doesn't explicitly walk through every parameter.

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 ('extract the text'), a clear resource (images, screenshots, photos, scanned PDFs), and the exact return (reading-order text with confidence, optional bounding boxes). It also names the sibling it is not ('For digital (non-scanned) PDFs and Office files prefer convert_document_to_markdown'), so an agent can distinguish it from similar tools 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 states when to use it ('receipts, invoices, forms, scanned documents, screenshots and product photos') and when not to ('digital (non-scanned) PDFs and Office files'), naming the alternative tool. It also adds practical guidance on cost and batching, leaving no ambiguity about selection.

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 readOnly and non-destructive; the description adds cost per frame, free failed videos, an error when the actor isn't public, and the 300-second timeout. These go beyond annotation fields and give accurate expectations for invocation.

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?

Long but every sentence carries value: the 'coming soon' warning is front-loaded, followed by supported formats, modes, outputs, use cases, constraints, and cost. No filler or repetition.

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

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

Covers input constraints (direct URLs, formats, exclusions), output (image URLs, timestamps, contact sheet, metadata), cost model, error behavior, and timeout. With 11 parameters and no output schema, this is comprehensive enough for an agent to 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 the schema already documents every parameter. The description mentions the default frame count and cost, but doesn't add syntax or format beyond what the schema provides; the 'not YouTube/TikTok' note is helpful but already implied by 'direct URL'. 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 exactly what it does: extracts still frames from video files via direct URL, lists supported formats and exclusions (YouTube/TikTok), enumerates output (image URLs, timestamps, contact sheet, metadata), and gives use cases. It clearly distinguishes from sibling tools, which are unrelated to video.

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 provides use cases ('let a vision model watch a video, make thumbnails or storyboards, find scene changes') and exclusions ('not YouTube or TikTok pages'). It also advises on batch size due to the 300-second limit, which helps an agent decide when to call.

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 readOnlyHint annotation, it discloses that the actor is not yet public, calls currently return an actor-not-yet-public error and are not charged, billing is 0.003 per topic, unmatched keywords are free, runtime is roughly 5-10 seconds for 3 keywords and about a minute for 10, and maxTotalChargeUsd caps spend. This is excellent behavioral context that annotations do not provide.

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

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

The description is long but dense and well organized: status warning, core function, matching rules, output summary, use cases, limitations, performance, and cost. The coming-soon warning is front-loaded, which is appropriate for an actor that currently returns an error. A few billing and runtime details could be tightened, so it is not a perfect 5.

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

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

With no output schema, the description still summarizes the result shape: per-topic daily/weekly/monthly timeline, absolute views, normalized 0-100 value, totals, peak date, latest value, change percentage, trend, spike days, and language edition breakdown. It also covers data source, date range, matching, cost, runtime, current status, and limitations, making the definition complete enough for accurate selection and invocation.

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

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

The schema already describes all 12 parameters, so the baseline is 3. The description adds genuinely useful semantics for keywords: each keyword is mapped to one article, exact title first, otherwise the top non-disambiguation hit, and the matched article is returned. It also adds operational guidance like sending up to about 30 keywords per call despite the schema allowing 50.

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 action and resource: measure and compare interest in topics over time from Wikipedia pageview data. It also distinguishes itself from the likely sibling get_trending_topics by emphasizing historical timelines and positioning the tool as Google Trends for Wikipedia. 'Over time' clearly separates it from a simple current-trends 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?

It gives explicit use cases such as checking whether interest in X is growing, comparing brands/products/people, seasonality, and finding when a story broke. It also states what this tool is not: it counts pageviews, not Google searches, and has no per-city data. It does not explicitly name a sibling alternative for current trending topics, so it stops short of a 5.

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

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

The description richly discloses behavior beyond the annotations: the tool is not public yet and returns an error, calls are billed per returned article, failed/no-data lists are free, data comes from Wikimedia Pageviews with rounding differences, there is a one-day publication delay, and maxTotalChargeUsd caps spending. This far exceeds what the readOnlyHint and destructiveHint annotations convey.

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

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

The description is long but every sentence carries useful information: availability status, data scope, source, use cases, defaults, pricing, and execution details. The coming-soon caveat is front-loaded. A slight structural split into availability, behavior, and billing would improve readability, but the density is justified.

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

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

Despite having no output schema, the description covers what is returned (rank, views, one-line description), default behavior, error cases, cost, API source, and execution constraints. For a tool with seven optional parameters and billing implications, this is unusually complete and leaves little ambiguity for an agent deciding whether and how to call it.

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 each parameter. The description adds meaningful semantics beyond the schema: the default day is the latest published day, the English edition is listed if neither country nor project is provided, and maxTotalChargeUsd acts as a hard spend cap. This justifies a score above the baseline of 3.

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

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

The description clearly identifies the tool's purpose: listing most-read Wikipedia articles by country and/or language edition, with rank, views, and descriptions. It is specific about the data source and scope, but it does not explicitly distinguish itself from the sibling tool 'get_topic_trends', so differentiation relies on context rather than a direct statement.

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 concrete use cases ('news and social monitoring, content ideas, or 'what is trending in Japan today?') and explains the default behavior when no trendingCountries or trendingProjects are provided. However, it does not explicitly state when to use this tool instead of an alternative or when not to use it, aside from the implied 'coming soon' unavailability.

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 readOnlyHint=true and destructiveHint=false already in annotations, the description goes well beyond by disclosing the cost model ('$0.003 per domain analyzed, billed to your Apify account; invalid domains and failed lookups are free'), the privacy constraint ('No registrant personal data is returned'), and the technical implementation (runs the Apify actor kantolabs/domain-whois-dns-ssl-lookup with APIFY_TOKEN, maxTotalChargeUsd caps spend). These are behavioral traits the annotations do not carry and that materially affect how an agent should invoke the tool. No contradiction with annotations.

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

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

The description is long but every sentence earns its place: purpose is front-loaded (report contents), then usage guidance, then the cost and privacy constraints, then technical details. The structure is logical and front-loaded with the highest-value information first. It could arguably be tightened, but no sentence is filler given the cost and security implications of this 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?

This is a complex tool (7 parameters, 5 report sections, billing implications) with no output schema, so the description must carry the burden of explaining the return value. It does: the return format is described in detail (registration fields, DNS record types, SSL fields, email security score/grade, plain-English issue list). The cost model, privacy constraint, timeout behavior, and input normalization are all covered. Nothing an agent needs 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 the baseline is 3. The description adds meaning beyond the schema by explaining the billing context that makes maxTotalChargeUsd actionable (an agent can estimate spend: 1000 domains × $0.003 = $3) and by describing the full report structure that the include* booleans toggle. It also clarifies input flexibility ('Accepts domains, URLs or email addresses') beyond the schema's bare array of strings.

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 ('look up') and a well-scoped resource (domain WHOIS, DNS, SSL, email security) and enumerates the exact data returned: registration data via RDAP/WHOIS, all DNS record types, SSL certificate details, and email security with score/grade. This specificity clearly differentiates it from siblings like check_domain_authority (authority score) and detect_website_tech_stack (tech stack detection), so an agent can pick it correctly 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?

The description gives explicit use-case guidance: "Use it for 'who is the registrar / when does it expire / is this domain available / is the certificate valid / who hosts their email / is DMARC set up' questions, lead enrichment and domain or certificate monitoring." This is clear when-to-use context. However, it never states when NOT to use it or names alternative sibling tools, leaving exclusions 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?

Beyond the readOnlyHint/destructiveHint annotations, the description discloses critical behaviors: the current 'coming soon' error state, '$0.001 per image returned' with filters applied before charging, no charge on no-match searches, execution as 'the Apify actor kantolabs/free-image-search with your APIFY_TOKEN', and the maxTotalChargeUsd spending cap. This is rich context that annotations do not provide.

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

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

The description is long but well-organized and front-loaded: the 'COMING SOON' warning leads, followed by purpose, output details, filters, use cases, caveats, legal note, and cost. Each sentence contributes value, though a few license-related details repeat information already 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?

With 12 parameters and no output schema, the description fully compensates by enumerating all returned fields (full-size URL, thumbnail, file page, dimensions, license family, attribution requirements, author, attribution line, quality marks, restrictions), plus cost, error behavior, filters, and legal advice. Nothing an agent needs to call or interpret the result 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 baseline is 3. The description adds slight interpretive value by explaining license tiers ('noAttribution' = PD/CC0 only, 'commercialNoShareAlike' = PD/CC0/CC BY) and file-type use cases, but most of that is also present in the schema descriptions. No substantial new parameter meaning is added.

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?

Description uses a specific verb+resource: 'searches the 100M+ freely licensed files on Wikimedia Commons through the official MediaWiki API' and states the exact deliverable (images under free licenses with legal reuse details). This clearly distinguishes it from sibling download_images and other unrelated 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 use cases ('article featured images, product or slide visuals, maps, flags, diagrams, historical photos') and a practical caveat ('abstract stock concepts return fewer matches, so search for the concrete scene'). It does not explicitly name alternative tools or exclusion conditions, 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?

The description adds substantial behavioral context beyond the annotations: the actor is currently non-public and returns an error, pricing per image, call duration limits, max batch sizes, output URL details, transparency handling, and the APIFY_TOKEN requirement. This fully compensates for the lack of output schema and aligns with the non-destructive readOnlyHint.

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

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

The description is long but dense, with the 'coming soon' caveat front-loaded before the core functionality. Every section earns its place: purpose, model choice, output behavior, pricing, limits, and constraints. It is not minimal, but the complexity of the tool justifies the length.

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 8-parameter tool with no output schema, the description is remarkably complete. It covers current unavailability, cost, failure behavior, timeout constraints, input restrictions, output format, and return shape (public download URLs with dimensions). An agent has enough context to decide whether and how to invoke it.

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?

While schema coverage is 100%, the description adds meaningful semantics beyond individual parameter descriptions: standard vs large pricing, input megapixel thresholds, output dimensions at 4x, and guidance on batching (15 standard or 3 large images). Not every parameter is explained in the prose, but the key operational implications are covered.

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: 'Enlarge images 2x or 4x with Real-ESRGAN...' and explains the effect (sharper edges, less blur and JPEG noise). It also distinguishes two model variants and output behavior, so an agent can clearly tell what this tool does.

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

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

Provides explicit use cases: 'make small product photos, thumbnails or artwork print- or store-ready, or to enlarge small text before OCR.' It also explains when larger inputs require allowLargeImages and notes that social-network and stock-photo links are refused, giving clear context without explicitly naming alternatives.

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