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

The annotations only declare readOnly/openWorld/idempotent, and the definition adds genuinely non-obvious operational context: a $0.02 x402 USDC charge, the first call returning payment terms with a retry via _meta['x402/payment'], robots.txt compliance, and a ~1-3 s latency window. These are important caveats an agent would otherwise not know, though the definition does not say how failures or blocked-by-robots cases 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?

The definition is two dense but purposeful sentences; the enumeration of detectable categories earns its place as scoping information. The payment mechanics are front-loaded ahead of the actual purpose, which is defensible since billing is a hard precondition but slightly delays comprehension.

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 definition still conveys what comes back — roughly 90 signatures, evidence-based matches, and versions where visible — plus latency and robots.txt behavior. It stops short of describing the result structure (per-technology evidence fields, confidence) and error paths, which 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 coverage is 100% with a single documented url parameter, so the schema already explains format. The definition only adds that detection reads the homepage and headers, a scope note rather than new parameter meaning — 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?

The definition uses a specific verb ('Detect what a website is built with') on a precisely scoped resource (homepage HTML and headers) and enumerates the detected categories — CMS, ecommerce, JS framework, analytics, CDN, hosting, language — which makes it unmistakable against siblings like page_meta or seo_audit_lite.

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: call it when you need a technology fingerprint. However, the definition never states when to prefer page_meta, page_quality, or site_verdict instead, nor does it set any exclusions such as requiring a live public homepage.

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