Siftwright web data

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuinely useful non-annotation context: the billing/quota model ('every 25 reviews returned count as one result, rounded up per request'). It stops short of noting rate limits or how partial failures across multiple apps/countries are reported.

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

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

Two sentences, zero padding. The capability statement comes first and the quota caveat follows, so the reader gets the essential semantics before the cost model.

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

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

With no output schema, the description carries the return-shape burden, and the '25 reviews = one result' rule goes a long way toward setting expectations. Given 8 parameters and multi-app/multi-country scope, it is nearly complete; a note on ordering defaults or cross-app result grouping would close the 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 63%, so the schema documents most parameters (apps, since, keywords, countries, maxReviewsPerApp). The description largely restates those same filters and adds no format or default detail the schema lacks, so baseline 3 applies.

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

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

States a specific verb+resource ('Get Apple App Store reviews for apps') and immediately scopes the accepted identifiers (name, numeric ID, URL), countries, and filter axes. An agent knows exactly what this tool retrieves and at what granularity.

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 filter list (rating, keywords, date, countries), but there is no explicit when-to-use or when-not guidance, and the siblings (ats_jobs, domain_whois, youtube_transcript, etc.) are unrelated enough that no routing note is strictly required. Minimum viable.

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 and openWorldHint, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: multi-provider aggregation into one schema and the non-obvious quota rule (every 3 jobs = 1 result, rounded up per request), which materially affects how an agent should size its calls.

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

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

Two sentences, purpose front-loaded, with the parenthetical field list and quota note following efficiently. Slightly dense but every clause carries information; 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 helpfully enumerates the return fields (title, team, location, remote, salary, apply URL) and explains the quota model, filling the biggest gaps. It is not fully complete for a 9-parameter tool, as several filter parameters and their semantics remain only 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 coverage is 44%, below the 50% threshold, so the description should compensate more. It does name the filter categories (title, location, department, recency), which loosely maps to titleKeywords/locations/departments/postedWithinDays, but leaves remoteOnly, includeDescription, excludeTitleKeywords, maxJobsPerCompany, and the companies input format undocumented in prose.

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

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

States a specific verb (List) and resource (open jobs from company careers pages), names the concrete ATS providers covered (Greenhouse, Lever, Ashby, SmartRecruiters, Recruitee), and enumerates the normalized output fields. It is unmistakably distinct from every sibling, none of which concerns job postings.

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 by describing the filters and coverage, but never states explicitly when to reach for this tool versus an alternative, nor any prerequisites. Since no sibling overlaps, the risk is low, but no when/when-not guidance is actually given.

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 and openWorldHint, and the description adds key behavioral context: crawling up to a few pages per site and that each successful crawl counts as one result. It omits rate limits, auth needs, and failure handling, but meaningfully enriches the safety-only 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?

Two sentences, front-loaded with the core purpose and followed by result semantics. Every sentence earns its place, with no redundant or filler content.

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

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

Given moderate complexity, a fully documented schema, and annotations covering safety and open-world behavior, the description is largely complete. It explains crawl scope and result counting, though it could note error handling or non-company domain behavior; no output schema means return format need not be covered.

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 urls and maxPagesPerDomain are fully documented with bounds and defaults. The description's "up to a few pages" is vague and adds no precise parameter detail beyond the schema, 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?

States a specific verb ("Find") and resource (public emails, phone numbers, social profiles) and scopes it to company websites via crawling. This distinguishes it from siblings like website_screenshot or tech_stack, which serve different purposes.

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 its use case (contact discovery on company sites) but does not explicitly state when to use it versus alternatives or when not to use it. Result-counting semantics are given, but no routing guidance is provided.

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 openWorldHint=true, so safety and external-lookup behavior are covered. The description adds genuinely new information beyond the annotations: the quota model ('every 3 domains with a registry answer count as one result, rounded up per request') and the availability check, both of which affect how an agent batches calls.

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 result fields are front-loaded in one dense sentence, followed by the cost/batching rule. Every clause earns its place, though the long enumeration makes the first sentence slightly heavy.

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 correctly enumerates what comes back, and it covers the batching/cost rule for a tool that accepts up to 50 domains. Nothing critical to invoking 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 description coverage is 100% (both parameters documented, including the 1-50 range and the default-true includeDns flag), so the schema carries the parameter burden. The description restates the record types that includeDns controls but adds no format/syntax detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb (look up) and resource (domain registration/DNS records), then enumerates the exact fields returned (registrar, creation/expiry dates, status, nameservers, DNSSEC, A/MX/SPF/DMARC, availability). An agent can distinguish this from every sibling tool, none of which touch DNS or WHOIS.

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 makes the domain-lookup context obvious but never states when to use this versus an alternative, nor any exclusions or prerequisites. Sibling tools are in unrelated domains, so implied usage is reasonably clear, but there is no explicit guidance.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuine value beyond them by disclosing the return shape and, notably, that each article returned counts as one result — a cost/quota signal an agent needs to size maxItems sensibly. It stops short of describing pagination or rate limits.

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

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

Two sentences, no filler, front-loaded with the action and immediately followed by the output contract. Every clause carries information the agent can act on.

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 usefully compensates by naming the returned fields (title, link, source, published time). Parameter defaults and constraints live in the schema. Only the absence of pagination/result-cap behavior keeps it from a 5.

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 (including defaults for country, language, and maxItems) are already documented in the schema. The description adds no format or interaction detail beyond that, 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?

States a specific verb (Search) and resource (Google News) plus supported query types (keyword, company, topic), and enumerates the returned fields. It is unambiguously distinct from every sibling, none of which touch news 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 the clear purpose, but there is no explicit when-to-use framing, no guidance on country/language selection strategy, and no statement of when a different tool would be preferable. Given the siblings are unrelated categories, ambiguity risk is low, keeping this at minimum-viable rather than poor.

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 declare readOnlyHint=true and openWorldHint=true, so the safety profile is already covered. The description still adds non-obvious behavior: 'Each host that answers counts as one result,' which signals per-host result/billing accounting and that non-responding hosts are silently excluded. It omits timeout, retry, and failure-handling behavior, 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?

A single information-dense sentence that front-loads the core question (post-quantum key exchange) before the secondary checks. The trailing result-counting clause is slightly grafted on, but nothing is wasted.

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 conveys the shape of the result (per-domain findings plus a letter grade) and the result-counting rule. It does not explain behavior for unreachable hosts or what a partial/failed scan returns, which is the remaining gap for a network-facing scanner.

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?

There is one parameter and schema coverage is 100%: the schema documents the 1-20 host array and that URLs are accepted. The description adds nothing about host syntax or the array cap, so the baseline 3 for schema-documented parameters 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 precise verb and resource ('Check whether domains use post-quantum TLS key exchange') and enumerates the exact signals inspected (X25519MLKEM768/ML-KEM, preferred groups, TLS 1.2/1.3, certificate algorithms/expiry, HSTS, letter grade). This is unmistakably distinct from every sibling (domain_whois, tech_stack, etc.).

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 subject matter — an agent can infer this is the tool to call when assessing a domain's post-quantum TLS posture. However, there is no explicit when-to-use/when-not-to-use guidance and no routing to alternatives (e.g., domain_whois for registration data). Adequate but incomplete.

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

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

Annotations already cover the safety profile (readOnlyHint, openWorldHint), and the description adds genuinely new context: results include supporting evidence per detection, and each successfully loaded website counts as one result (a billing/quota semantic not present in the schema). It stops short of covering auth, rate limits, or failure 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?

Two sentences, both front-loaded with the operation and then the result-count semantics; the enumeration of detection categories is informative rather than padding. No wasted clauses.

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 read-only, open-world detection tool with a fully documented 2-parameter schema, the description covers scope, output content, and result accounting. Missing only peripheral details (auth requirements, partial-failure behavior) that an agent could mostly infer.

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 both urls (1-20 sites) and includeDns are fully documented in structured fields. The description's mention of "email and DNS provider" detection loosely maps to includeDns but only repeats what the schema already says; baseline 3 applies.

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

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

States a specific verb ("Detect") plus resource (website tech stack) and enumerates exactly which signals are returned (CMS, ecommerce, frameworks, analytics, ad pixels, hosting, CDN, email/DNS). This is plainly distinguishable from siblings like domain_whois or website_screenshot.

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 purpose statement — you call it when you want to know what a site is built with — but there is no explicit when-to-use, when-not-to-use, or routing to alternatives such as domain_whois for registration data. Adequate minimum viability, nothing more.

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 declare read-only and open-world behavior. The description adds useful context: real-browser capture, a signed fileUrl per page downloadable without a key for 7 days, and per-page result counting. It still omits rate limits, failure modes, and auth caveats.

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 sentences with no waste: capability, return artifact, and billing unit. It is front-loaded and appropriately sized for an 8-parameter 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?

No output schema exists, but the description explains the key return artifact and its 7-day signed URL lifetime per page. It leaves advanced capture parameters to the schema and does not describe error or edge behavior, but it is nearly complete for tool selection.

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 75%, and the description only reinforces the format option (PNG/JPEG/PDF). It adds no meaning for delaySec, fullPage, viewport dimensions, waitForSelector, or pdfPageFormat beyond what the schema provides.

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

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

States a specific verb and resources: capture PNG/JPEG screenshots or render PDFs of public web pages in a real browser. The scope is clear enough to distinguish it from sibling data-extraction 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?

Implies usage for public web pages but gives no explicit when-to-use, when-not-to-use, prerequisites, or alternatives. Sibling tools are unrelated, so no routing conflict is addressed.

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 and openWorldHint, so the description goes further by disclosing the caption-availability constraint, per-video failure behavior, and the billing model ('each video whose transcript comes back counts as one result; failures are free'). It omits rate limits and concurrency behavior, but the added operational context is substantial.

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

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

Two sentences, no filler. Purpose and return shape come first, then the constraint and cost model, which is the right front-loading for a decision-making agent.

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

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

With no output schema, the description carries return-value burden and does so adequately by naming the returned artifacts (text, timed segments, video metadata). Failure and billing behavior are covered; what a 'failed item' looks like in the response is not, which is a minor gap.

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

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

Schema description coverage is 100%, so the schema already documents every parameter including language preference, translateTo, outputFormats and maxVideosPerSource. The description only echoes 'plain text and timed segments' (the default outputFormats) and adds no format, ordering, or translation detail beyond the schema.

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

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

States a specific verb and resource ('Get transcripts (captions) for YouTube videos, Shorts, playlists or channels') plus the two output shapes (plain text and timed segments) and video metadata. This is unambiguous and entirely distinct from every sibling tool listed.

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 tells the agent the precondition that gates use ('Uses the captions YouTube already has; videos without captions return a failed item') and gives billing context that affects whether to call it. It does not name alternatives, but the sibling set is orthogonal, so there is little routing ambiguity to resolve.

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