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

Goes well beyond the annotations: states that it creates a persistent daily monitor, discloses exactly what is read (headers, generator meta tag, versioned script paths, open ports), the alerting behavior and cadence (P1 immediate, P2/P3 digests per org rules), plan quota consumption, and idempotent re-add semantics. Consistent with readOnlyHint=false/destructiveHint=false/idempotentHint=true.

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

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

Front-loads the action and packs the essential behaviors into one dense paragraph with no filler. It is slightly overstuffed with parenthetical clauses, which hurts scannability a little, but every sentence 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 compensates by describing the return payload (source, components read, already-open findings with priority and fix) and by covering scope, cadence, and quota. An agent has enough to call it and set expectations.

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 parameters are already documented, including the URL-to-host reduction rule and the optional display name. The description adds only contextual meaning ('one public website'), not parameter-specific detail, 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 ('Start vulnerability monitoring of one public website') and immediately bounds scope ('one public website', 'no scan beyond one page'), which distinguishes it from the one-off scan siblings like scan_before_use and scan_url and from watch_dependencies. An agent can tell what this creates 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?

Clear usage context: use it to begin recurring daily monitoring, it consumes one watched source of the plan, and re-adding is free. It lacks explicit exclusions or named alternatives (e.g. 'use scan_before_use for a one-time check'), so the when-not is implied rather than stated.

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