Wardzo

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

Annotations already declare readOnly=false, destructive=false, idempotent=false, openWorld=true, so the safety profile is covered. The description adds genuine context beyond that: alerting semantics (email on two consecutive failures and on recovery) and the hard limitation that no form submissions or request bodies are ever sent. It does not mention plan/permission requirements or that a schedule exists with no corresponding parameter.

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 what is monitored and how, then layers optional assertions, then alerting, then the negative constraint. Every sentence carries information; the only mild waste is the brand-name sentence 'Wardzo never submits forms or sends request bodies', which is nonetheless a useful capability boundary.

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 the description never says what is returned (e.g., an endpoint id needed later for remove_endpoint or recheck_site). It also mentions 'on a schedule' without noting that no scheduling parameter is exposed. Adequate for calling the tool, but incomplete for the follow-on workflow an agent will need.

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

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

Schema description coverage is 100%, so every parameter is already documented, including the GET-only qualifier on expect_keyword and the default of any 2xx/3xx. The description paraphrases those same concepts at a high level without adding syntax or interaction detail beyond the schema, 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 resource and scope: monitoring a URL on one of your sites via GET/HEAD on a schedule, which implicitly distinguishes it from add_site (creates the site) and list_endpoints (read). The description describes the behavior of the thing being created rather than saying plainly 'creates a new endpoint check', so the verb is inferred from the name rather than restated.

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

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

Usage is implied rather than stated: 'on one of your sites' signals a site must already exist, and 'Wardzo never submits forms or sends request bodies' sets a real boundary (no POST/form monitoring). There is no explicit when-to-use vs. when-not against siblings such as add_site or recheck_site.

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 this as a non-destructive, idempotent mutation with open-world effects. The description adds useful behavioral context beyond those hints: the site is scanned immediately, re-scanned on the plan schedule, and produces uptime checks and email alerts. It stops short of explaining duplicate-URL behavior or what the response contains.

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. Each clause (immediate scan, scheduled re-scan, uptime checks, alerts) contributes useful 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 simple one-parameter mutation tool with full schema coverage and safety annotations, the description explains what happens on invocation. It lacks only edge-case behavior such as how duplicate URLs are treated and what is returned, which is a minor gap given the annotations and 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?

There is one parameter, and schema description coverage is 100% ('Website URL or domain' with min/max length). The description adds no format guidance beyond the schema, 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 and resource ('Start monitoring a website') and adds concrete scope: immediate scan, scheduled re-scans, uptime checks, email alerts. It does not explicitly differentiate itself from siblings like scan_site or recheck_site, so an agent must infer that this is the persistent-monitoring entry point rather than a one-off scan.

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

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

Usage is only implied: adding a site is how you begin monitoring it. The description does not say when to choose this over scan_site (one-off scan) or recheck_site, nor does it state prerequisites such as plan limits or duplicate handling.

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 readOnlyHint annotation already establishes the safety profile, and the description adds genuinely useful behavioral context by disclosing the shape of the output: remediation steps with framework-specific snippets (Next.js, Vercel, Nginx, etc.) and verification guidance. It doesn't cover rate limits or output format details, but for a read-only explainer this is solid added value.

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 filler; the parenthetical framework list is dense but earns its place by telling the agent what kind of remediation content to expect. Slightly run-on 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?

There is no output schema, so the description carries the burden of describing returns, and it does so adequately (explanation, fix steps, snippets, verification). Combined with readOnlyHint covering safety, an agent has enough to call this 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?

With a single parameter at 100% schema description coverage, the schema already documents issue_id, its length constraints, both accepted formats, and examples. The description adds nothing about the parameter, 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 and resource ('explain an issue') and enumerates the output content: why it matters, step-by-step fix instructions, and verification steps. It is clearly distinct in kind from siblings like list_issues/scan_site, though it doesn't explicitly name them as alternatives.

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

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

Usage is only implied: the schema's issue_id description points at list_issues/scan_site as the source of the ID, so the workflow (list/scan, then explain) is inferable. There is no explicit statement of when to choose this over recheck_site or get_report, and no exclusions.

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

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

readOnlyHint=true is consistent with 'Get the result', so no contradiction. Beyond the annotation the description only adds id provenance; it says nothing about behavior when the scan is still running, unknown ids, or what the report contains — useful given there is no output schema.

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

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

A single front-loaded sentence with the action first and the id-sourcing hint second; no filler or restatement of the title.

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 one-parameter read tool with readOnlyHint and full schema coverage, this is nearly sufficient. The only meaningful omission is what happens for pending/unknown scans, which matters because there is no output schema to describe the return shape.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds provenance the schema lacks: the id is produced by scan_site/recheck_site or appears in a wardzo.com/r/<id> URL. That directly helps the agent supply a valid value beyond the bare 'Scan id or report URL' schema text.

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 ('Get') and resource ('the result of a Wardzo scan') scoped by id, which cleanly separates it from mutation siblings like scan_site and recheck_site. It stops short of explicitly contrasting with read siblings such as get_site_status or list_issues, so differentiation is implied rather than 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?

The parenthetical tells the agent exactly where a valid id comes from — scan_site, recheck_site, or a wardzo.com/r/<id> link — which is the key prerequisite for calling it. It gives no explicit when-not-to-use guidance (e.g., vs. list_issues for browsing problems), but the usage context is clear.

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, so the safety profile is covered; the description adds real value by disclosing the payload contents — change since previous scan, severity breakdown, 24h and 7d uptime, and last-scan deltas. It does not cover behavior for an unknown/unmonitored site or whether the data is cached versus freshly scanned.

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 sentence that front-loads the most important returned value (latest score with change) before the secondary contents. Nothing is redundant with the title or schema, and no filler text is present.

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 carries the return-value burden by enumerating the fields the agent will receive. It is nearly complete for a one-parameter read tool, though it omits error behavior for an invalid/unmonitored site and the units/scale of the score.

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 the single 'site' parameter is already documented as 'Site id, domain or URL'. The phrase 'one of your monitored sites' adds the constraint that the site must already be registered, but no format examples or resolution rules are added 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 enumerates exactly what the tool surfaces for a single monitored site (score + delta, issues by severity, top issues, uptime, recent changes), which is more specific than the title's 'Get site status'. It implies single-site scope, distinguishing it from aggregate siblings like list_sites or list_issues, but never names those siblings directly.

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

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

Usage is only implied: 'for one of your monitored sites' signals a single-site snapshot use case. There is no explicit statement of when to reach for this versus list_issues, explain_issue, get_report, or recheck_site, and no prerequisites (e.g., that the site must already be added via add_site).

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, so the safety profile is covered. The description adds value beyond that by naming the fields returned (current status, last HTTP status, response time), but says nothing about pagination, result volume, or what happens for a site with no checks configured.

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 sentence that front-loads the resource and folds the disambiguating definition and the returned fields into the same clause. Nothing is wasted and nothing important is buried.

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, one-parameter list tool with no output schema, telling the agent which fields come back and what an endpoint check is makes the definition essentially self-sufficient. Only minor operational details (pagination, empty results) are absent.

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 a single required 'site' parameter at 100% schema description coverage, so the schema already defines it as site id, domain or URL. The description reinforces the scoping ('one of your sites') but adds no format or resolution 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 and resource and disambiguates the ambiguous term 'endpoint checks' with a parenthetical (GET/HEAD monitors for URLs like /api/health), plus scopes it to a single site. It clearly separates itself from list_sites and list_issues by resource, though it never names a sibling explicitly.

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

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

Usage is only implied: the tool is clearly the discovery step for per-site endpoint checks, but there is no statement of when to prefer it over get_site_status or list_issues, and no note that the site id typically comes from list_sites. Adequate context, no explicit exclusions or 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?

readOnlyHint already tells the agent this is a safe read, so the description correctly spends its words elsewhere: it discloses the ordering guarantee ('most severe first'), the data vintage ('latest scan'), and a key returned field (issue_id). It doesn't cover result volume or pagination, so not 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?

Two short sentences, zero filler, with the scope and ordering front-loaded and the follow-up hint last. 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?

With no output schema, the description does the right work by naming issue_id and the sort order, which is enough to chain into explain_issue. Minor gap: no mention of the severity parameter or result limits, which an agent might need to know before calling.

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 both 'site' and the severity enum with its 'minimum severity' semantics and default are already documented. The description adds nothing about parameters — notably it never mentions the severity filter, which is the main lever for shaping results. 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 and resource ('List open issues') plus two scoping constraints: the latest scan and a single site. It stops short of explicitly distinguishing itself from siblings like get_report or get_site_status, but the resource is concrete enough to route on.

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 the use case ('from the latest scan of one of your sites') and points forward to explain_issue for per-issue detail, which is useful follow-up routing. However, it never says when to choose get_report instead of this tool, nor any prerequisites such as needing a prior scan.

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?

readOnlyHint=true already establishes the safety profile, and the description usefully adds what a result contains (latest score, open issue counts, uptime). It stops short of saying whether all sites are returned, how results are ordered, or how much data a large account yields.

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?

One sentence, front-loaded with the verb and scope, and every clause adds information about the payload. 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 parameters, no nested objects and no output schema, the description carries the return-value burden and does so by naming the key fields. Only minor gaps remain (volume, ordering, relationship to per-site status tools).

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 has zero parameters, so baseline is 4. The description correctly implies an unfiltered account-wide listing, which is the one meaningful semantic an agent needs here.

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?

Specific verb 'List' plus a precisely scoped resource ('websites monitored in your Wardzo account') and the fields returned. It does not explicitly contrast itself with siblings like get_site_status or list_endpoints, but the aggregate-listing nature is clear enough to place it.

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 mention of scores, issue counts and uptime implies this is the account-overview entry point, so usage is inferable. However, there is no explicit when-to-use, no statement that per-site detail belongs in get_site_status, and no note about ordering or result limits.

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 behavior beyond the annotations: it names the latency budget ('waits up to ~45 seconds') and the return semantics ('report what changed'), which tell the agent this is a synchronous, long-ish call that produces a diff. It does not explain what happens if the 45 seconds elapse, though readOnlyHint=false on a re-scan is consistent with the description of triggering fresh work.

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?

One sentence, front-loaded with the action, followed by the trigger context and latency in a compact clause. 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 should say more about what the result looks like and what occurs on timeout or failure. 'Report what changed' gestures at the return value, but the ~45-second cap is left unexplained and the prerequisite that the site be monitored first is only implicit.

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 already documents the single 'site' parameter as 'Site id, domain or URL'. The description adds only the constraint that the site must already be 'monitored', implying add_site as a prerequisite, but no further format guidance.

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 fresh scan of one of your monitored sites') plus the added value of reporting change, which is more than the title suggests. It does not distinguish itself from the sibling scan_site, leaving an agent to guess which one to pick.

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 parenthetical 'e.g. after deploying a fix' implies a usage trigger, which is better than nothing. But there are no exclusions and no named alternative — scan_site and get_site_status are obvious candidates the description never addresses.

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 destructiveHint=true and idempotentHint=true, so the safety profile is structured. The description adds concrete consequence beyond that: monitoring stops AND history is deleted, telling the agent what data is lost. It could go further on irreversibility or permissions, but it meaningfully extends the 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, both front-loaded and load-bearing: the first names the action and its consequence, the second tells the agent where to get the ID. No filler.

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

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

For a one-parameter destructive tool with no output schema and annotations covering safety/idempotency, the description supplies what an agent needs: the effect, the data loss, and ID provenance. Only minor gaps remain (e.g., whether removal can be undone or batched).

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 the endpoint_id property is already documented as coming from list_endpoints. The description restates that same provenance hint without adding new format or constraint detail, so it sits at the baseline for a fully documented single 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?

States a specific verb pair (stop monitoring, delete history) on a specific resource (one endpoint check). It is unambiguous against siblings like add_endpoint or recheck_site, which act on the same resource with different intents.

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?

"Use list_endpoints to find the endpoint_id" gives a clear prerequisite/routing hint to the sibling that supplies the required identifier. It stops short of explicit when-not-to-use guidance, but the intent is clear and there is no competing removal tool to disambiguate against.

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 well beyond the readOnlyHint/openWorldHint annotations by disclosing the ~45 second wait, the passive outside-in nature, the no-API-key path with rate limiting, and the returned payload. It does not say what happens on timeout or whether a scan registers/persists the site, which is the main behavioral ambiguity left.

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 filler. Purpose and scope lead, latency and auth/rate-limit constraints follow, and the return contents close it out.

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, and the description compensates by naming the return fields (score, issues, report URL). With latency, auth, and rate limits covered, the only material gaps are timeout behavior and whether the scan creates a site record (relevant given add_site/list_sites siblings).

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 and schema coverage is 100%, so the schema ('Website URL or domain, e.g. example.com') already does the work. The description adds no format, normalization, or validation detail beyond it, 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 (passive outside-in scan of a public website) and enumerates the domains covered (security, SEO health, uptime) plus what comes back (score, issues, report URL). However, it never distinguishes itself from siblings like recheck_site or add_site, which an agent could easily confuse with 'scan a website'.

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?

'Works without an API key (rate limited)' implies a first-scan / unauthenticated use case, but there is no explicit when-to-use versus recheck_site or add_site, and no statement of when not to call it. Usage is inferable rather than stated.

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