Weio site check

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: it checks both apex and www, enumerates the cause categories returned, and discloses that the tool cannot see non-public sites.

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

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

Front-loads the core purpose and packs the failure-mode list into a single dense sentence, with the scope limit isolated at the end for emphasis. Slightly run-on, but every clause carries information.

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

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

For a single-parameter diagnostic with no output schema, the description covers what is inspected, the scope boundary, and the shape of the returned data (cause code, warning flag, expiry, per-address explanation), which is enough for an agent to call and interpret it correctly.

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

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

Schema coverage is 100%, so the example format is already documented. The description adds meaning beyond the schema by clarifying that one domain value causes checks of both example.com and www.example.com, which is non-obvious input behavior.

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

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

States a specific verb and resource (checking what a visitor sees for HTTPS/TLS on both apex and www), and enumerates the failure modes it detects. This clearly distinguishes it from find_businesses and site_info, which do not diagnose certificate/browser-warning state.

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 trailing constraint 'Public websites only' implicitly rules out internal/authenticated hosts, which is useful. However, it never says when to pick this over site_info, which presumably also inspects a domain, leaving sibling selection 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?

Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false). The description adds useful context beyond them: the 10-record cap, the dated/small index caveat, the exact fields returned, and the deliberate exclusion of email addresses and personal data.

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

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

Front-loaded with the return count and resource, followed by coverage, returned fields, and the non-directory caveat. The first sentence is long with stacked modifiers, but no sentence is 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 carries the burden of describing returns, and it does so ('business name, website, a phone-layout flag and scan/source scope') while also stating exclusions and coverage limits. It omits any auth or rate-limit context, but the annotations already handle the safety profile.

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 category, area, and limit. The description's only parameter-relevant input is the coverage restriction ('dentists/dental only', 'Fresno County, CA only'), which largely restates the schema descriptions rather than adding syntax or format detail.

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 ('Returns ... public business records') with explicit scope (up to 10, dental category, Fresno County, scan date). An agent can distinguish this from the unrelated siblings check_https and site_info without opening either schema.

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

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

The description clearly defines the applicable domain ('Initial coverage is dental-category businesses in Fresno County, California, scanned 2026-09-30') and warns 'This is not a complete directory or ranking.' That tells the agent when the tool is valid, but it names no alternative tool or condition for choosing one, so it falls short of explicit when/when-not/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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: it is a single homepage fetch, restricted to public sites, deliberately excludes personal-name emails, and flags broken HTTPS certificates.

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 long output enumeration is packed into one sentence, but every clause corresponds to a distinct returned fact, so little is wasted. It is front-loaded with the subject and scope before the detail list.

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 burden of describing return values and does so thoroughly. It omits only edge-case behavior (e.g., fetch failure or no-data handling), which is a minor gap for a single-fetch read 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?

Only one parameter (domain) with 100% schema description coverage, so the schema fully documents it and the baseline is 3. The description adds the constraint that only the homepage is fetched but no format or normalization details beyond the schema's own example.

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 ('Reads...returns') and resource (a business website homepage) and enumerates the concrete facts returned, which makes it immediately distinguishable from find_businesses (discovery) and check_https (certificate checking as a standalone). An agent can tell what this does 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?

Provides the operating constraint ('Public websites only; one homepage fetch') which frames appropriate use, but never names the alternatives (check_https, find_businesses) or states when to prefer this tool over them. Usage is implied by the output list rather than explicitly guided.

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