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

With no annotations, the description carries the full disclosure burden. It partially meets it by stating what is queried and that a 0-100 score is returned, implying a read-only live DNS inspection. It does not disclose that lookups happen against live DNS, whether the call is latency-prone, any rate limits, or how partial failures are handled.

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 front-loaded sentence that names the verb and resource before listing the checks. The enumeration is long but every item is a real inspected signal, so nothing is padding; slightly list-heavy but 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?

With no output schema, the description should hint at return values, and it does via the overall 0-100 score plus the component checks (the schema also notes one result row per domain). For a read-only audit tool this is close to sufficient, missing only the per-component result shape and failure behavior.

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 explains domain, domains (with its override behavior), and checkDkim's cost tradeoff. The description only weakly reinforces the domain scope and DKIM selector probing, adding no syntax or format detail beyond the schema. 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 gives a specific verb ('Check') and resource ('a domain's DNS and e-mail security posture') and enumerates the concrete signals it inspects (SPF, DMARC, DKIM selectors, providers, registrar, domain age). It is clearly distinguishable from the sibling validate_emails in spirit (domain-level posture vs. individual address validation), but that differentiation is never stated.

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 explicit when-to-use, when-not-to-use, or alternative routing. An agent gets no help deciding between this and validate_emails, or knowing that a full score requires the DKIM probe. Usage is only inferable from the enumerated checks.

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. It usefully discloses a cost/performance trait (disabling sections makes runs cheaper and faster), which is genuine behavioral value. It is silent, though, on permissions/auth needs, rate limits, and that it is a read-only operation, so key traits remain undisclosed.

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 capability followed by an actionable cost tip. The section enumeration is long but each item earns its place by telling the agent what output to expect; only the overlapping 'DNS/e-mail security' vs 'TLS/security grade' phrasing is 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 9-parameter composite with no output schema, the description reasonably compensates by enumerating the returnable sections and noting the cost lever. It omits the multi-domain behavior ('one result row per domain') and any auth/permission context, but the description is nearly sufficient 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 description coverage is 100%, so the includes/domain parameters are already fully documented in the schema, establishing a baseline of 3. The description's section list loosely maps to the include flags but adds no syntax or override semantics beyond what the schema already 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 ('Build') and resource ('one-stop company profile for a domain') and enumerates exactly what it assembles: contacts, tech stack, DNS/e-mail security, TLS/security grade, hiring signals, Wikidata facts, and SEO audit. This immediately distinguishes it as a composite/aggregator relative to siblings like extract_contacts, detect_tech_stack, and check_email_security.

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 closing sentence gives real guidance on how to use it ('turn off sections you don't need to make the run cheaper and faster'), which steers toward minimal section selection. However, it never states when to prefer this aggregator over the narrower siblings (detect_tech_stack, extract_contacts) or when-not to use it, so the routing guidance is only implied.

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. It usefully discloses that billing is per page and that output is one Markdown document per page, but it omits other relevant crawl behaviors such as rate limits, robots.txt handling, or error 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, front-loaded with the core action and output, then immediately followed by the important billing constraint. Every sentence earns its place 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?

The tool has no output schema, and the description clearly explains the return unit (one Markdown document per page). With 100% schema coverage, parameter details are adequately handled elsewhere, though the absence of annotations means additional behavioral context could still improve completeness.

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 six parameters are already documented in the input schema. The description only reinforces the billing meaning of maxPages, adding little parameter semantics beyond what the schema provides, which matches 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 names a specific verb and resource: crawl a website from one URL and return one Markdown document per page. It gives useful examples (docs sites, blogs, knowledge bases) but does not explicitly differentiate from sibling tools such as read_url, which may still cause selection ambiguity.

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 the tool is for multi-page documentation, blog, or knowledge-base crawling and warns that billing is per page. However, it does not state when to choose this over read_url or web_search, nor does it specify exclusions or prerequisites.

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. It implies network fetching and page inspection (maxPagesPerDomain, followSubdomains) but never states latency, rate limits, failure behavior for unreachable sites, or that detection is heuristic/best-effort — all material for an agent deciding whether to call it.

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 front-loaded sentence: verb, resource, then the detection scope. No filler. The long comma-separated enumeration is dense but every item earns its place by defining coverage.

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 5-parameter tool with no annotations and no output schema, the description covers capability but says nothing about the return shape (e.g. one result row per site across categories), error handling, or multi-URL result structure. Minimum viable but with real 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 the schema already explains url, urls, categories, followSubdomains and maxPagesPerDomain fully. The description's category list merely mirrors the enum rather than adding syntax, defaults, or interaction rules, so 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 ('Fingerprint') and resource ('a website's technology stack') and then enumerates the detected categories (CMS, analytics, payments, etc.), which makes the tool unmistakable against siblings like read_url or crawl_site_markdown that operate on the same resources for 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?

No guidance on when to prefer this over siblings such as read_url or company_profile, and no exclusions or prerequisites stated. The only routing information (urls overriding url) lives in the schema, not 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 at all, the description carries the full behavioral burden and falls short. It does not mention rate limits, network cost, whether a crawl is long-running, whether failures are surfaced per-URL, or what happens when a site blocks crawling. Only the page-selection scope (home/about/contact) is disclosed.

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, front-loaded sentence with no wasted words; the verb and resource lead and the extraction targets follow. Slightly list-heavy with the parenthetical platform enumeration but still 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 an 8-parameter, zero-annotation, no-output-schema tool, the description covers purpose and extraction scope but omits return shape, batching semantics for urls, and behavioral limits. It is adequate but leaves real gaps an agent would need to know.

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 8 parameters with defaults and ranges. The description adds nothing about parameter behavior (e.g., how url interacts with urls), 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?

States a specific verb (crawl) plus resource (website pages) and enumerates exactly what it extracts, including the specific social platforms. This distinguishes it clearly from siblings like read_url (single page) and crawl_site_markdown (crawling for markdown content rather than contact data).

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 extraction use case but never states when to use this over read_url or crawl_site_markdown, nor when-not to use it. No exclusions, prerequisites, or alternative-routing guidance are given; the agent must infer usage from the name and scope alone.

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 return shape (organic, PAA, related searches) and that results are raw SERP data, but it omits operational traits an agent would care about: rate limits, quota/cost, caching, or whether the service may be blocked. Adequate but incomplete for a zero-annotation 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?

Two tight sentences with the capability front-loaded and the alternative routing second. No filler, though the return-value enumeration slightly overlaps with what the tool obviously returns.

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

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

Ten parameters are fully covered by the schema and there is no output schema, so the description's enumeration of return fields is the right level of detail. Minor gaps in pagination/quota behavior are covered adequately by the maxPagesPerQuery and resultsPerPage schema entries.

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 ten parameters (query/queries override behavior, device, countryCode, languageCode, resultsPerPage, maxPagesPerQuery, include* flags) are already documented in the schema. The description adds no parameter-level meaning, which matches the baseline 3 when the schema does the heavy lifting.

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

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

States a specific verb and resource ('Run a raw Google search') and enumerates the returned SERP structures (organic results, People Also Ask, related searches). It also explicitly differentiates from the sibling web_search, so an agent can route correctly without opening a schema.

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

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

Explicit when-to-use condition ('when you need Google's ranking/position data itself, not just page content') paired with the named alternative ('for that, use web_search'). Both the selection condition and the fallback are 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 behavioral burden. It discloses what health data is checked and that GitHub enrichment is optional, but it does not describe read-only semantics, rate limits, error handling, or the exact return shape. For a read-oriented check tool this is adequate but not rich.

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 compact sentences with no filler. The purpose and covered metrics are front-loaded, followed by a concise registry-prefix example, so every part earns its 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?

For a tool with no annotations and no output schema, the description covers the key returned signals and the registry-prefix input format. It omits details about multiple-package handling and error behavior, though `packages` is covered by the schema. Overall it is complete enough 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 description coverage is 100%, so all four parameters are already documented in the schema. The description reinforces the registry-prefix format and optional GitHub enrichment, but it adds little beyond what the schema provides. 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 and resource: checking health of npm, PyPI, or Crates.io packages, and enumerates the health signals it covers. The sibling tools focus on email, web, tech stack, or companies, so this is clearly distinguishable. An agent can identify the tool's purpose without opening the schema.

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

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

The description implies usage by defining the tool as a package health check and provides a registry-prefix example, but it does not explicitly state when to use this tool versus alternatives or when not to use it. There are no sibling package-checking tools, so the implied usage is sufficient but not strong 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?

No annotations are provided, so the description carries the full burden. It does disclose the return payload (title, author, date, body as Markdown), which is genuinely useful. However, it says nothing about failure modes on non-article or JS-heavy pages, rate limits, or partial-batch 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 tight sentences with zero filler; the capability and output format come first, the sibling routing second. Every clause earns its 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?

Covers purpose, output format, and alternative-tool routing, which is what an agent needs to call it correctly. Gaps remain around batch size limits and behavior on unextractable pages, but these are peripheral for a stateless fetch 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 four parameters are already documented in the schema with defaults and the url/urls override rule. The description only adds the informal 'one or more URLs' framing, 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 (fetch) and resource (article/blog/news URLs) and specifies the return shape (clean readable text as Markdown with title, author, date, body). It is immediately distinguishable from siblings like web_search or crawl_site_markdown.

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 names the alternative and the selecting condition: 'Use this instead of web_search when you already have the exact URL to read.' Nothing is left to inference about when to pick 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, the description carries the full burden. It does disclose the actual operations (syntax, disposable/role detection, live DNS-over-HTTPS MX/A lookup) and that MX checking is optional and slower, which is useful. However, it says nothing about cost, rate limits, external network calls' failure modes, or permissions.

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 tight sentences: the mechanics come first, the use case second, with no filler or redundancy.

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 and no annotations, so the description should ideally characterize what a validation result looks like (per-address verdicts, reason codes, what happens to invalid entries). The operations are covered but the return contract is left entirely unspecified.

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 three parameters including the 'overrides email when non-empty' rule and the checkMx default. The description only restates the MX lookup as optional, adding marginal meaning, so the 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+resource (validate e-mail addresses) and enumerates the three checks performed: syntax, disposable/role detection, and optional MX/A lookup. It does not explicitly differentiate itself from the sibling check_email_security, which is a plausible source of confusion.

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 phrase 'Good for cleaning a lead list before sending' implies a usage context, but there is no explicit when-to-use/when-not guidance and no mention of the neighboring check_email_security tool, which an agent might otherwise choose.

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 burden and does add real behavioral detail: results come back as clean Markdown, direct URLs skip search, and each fetched page is a billed row (cost signal). It still omits rate limits, failure behavior, and how SERP vs fetched content differ when includeSnippetOnly is used.

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 short sentences, each earning its place: capability, dual mode, usage hint, and billing note. Front-loaded with the core verb and output format.

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 annotations and no output schema, the description covers the core modes and billing but leaves gaps: no mention of how many results by default, costs per query, or differences from google_search/read_url. Adequate but incomplete for a tool with this many parameters.

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 parameters are already fully documented in the schema; baseline is 3. The description adds only the higher-level notion that URLs bypass search, which the urls parameter description already 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 (search) and resource (the web) and clarifies the output (clean Markdown of top results), plus a dual mode (direct URL fetch). It doesn't explicitly distinguish itself from the closest sibling google_search, though the URL-skipping mode and Markdown-fetch behavior imply the difference.

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 offers one piece of usage guidance ('Good default choice for what is X / find info about X questions') but never names alternatives like google_search, read_url, or crawl_site_markdown, nor says when not to use it. Usage is implied rather than specified.

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