Lordevo Shop (x402 pay-per-call)

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

Annotations already mark it read-only, idempotent, and open-world, but the description adds substantial context beyond that: pricing ($0.01, USDC on Base), the x402 payment handshake, latency (~1-3 s), and the shape of the result (grade, spoofable flag, fixes). This is exactly the behavioral detail an agent needs before invoking.

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?

Dense but front-loaded: purpose is stated first, then payment mechanics, then the specific checks and outputs. The price sentence is slightly long but earns its place because it prevents a blind first call. No filler sentences.

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 naming the return values (grade, spoofable flag, fixes). Combined with the payment flow and latency note, an agent has everything needed to call this correctly on the first attempt.

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'), and the input schema documents it fully, including that a URL or email address also works. The description adds no syntax or format details beyond the schema, 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 and resource ('Check a domain's email authentication and spoofing risk from public DNS') and enumerates the concrete checks (SPF, DMARC, DKIM selectors, MTA-STS, TLS-RPT, BIMI). Clear enough to distinguish it from siblings like security_headers or security_scan_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?

The use case is clear: assess a domain's email-spoofing posture from public DNS. It also gives practical invocation guidance for the x402 payment flow (first call returns terms, pay and retry with _meta). It does not explicitly say when to prefer this over overlapping siblings, but the context is well-defined.

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 safety (readOnlyHint=true, openWorldHint=false), but the description adds two useful facts: the call is free and the output is illustrative rather than real data for a resource. It does not say whether the sample is static/fixed or rate-limited, which matters for a preview endpoint.

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 with the cost signal ("Free.") front-loaded ahead of the purpose. Nothing is wasted and the key differentiator leads.

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 preview endpoint with safety annotations and no output schema, the description covers what is needed to decide to call it. Minor gaps: whether the sample varies by input, and its approximate shape/size.

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 0% and the single `tool` parameter is undocumented in the schema, but its enum values are self-descriptive tool names matching the siblings, so minimal explanation is needed. The description only implies the parameter selects which tool to preview, adding little beyond the enum itself.

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 ("returns an example" of a tool's output) and frames its role relative to the paid siblings as a free preview. An agent can tell it is a preview tool, though it never names the sibling tools it previews or what the sample contains.

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?

"so you can decide before paying" gives a clear usage condition: call this before committing to a paid tool. It does not state when not to call it (e.g., once the paid tool is already chosen), so it stops short of explicit alternatives/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?

The description adds context beyond the annotations: the call is free and the response carries price, endpoint and input for each service, which the readOnlyHint alone would not convey. It does not cover ordering, list size, or whether auth is needed for the listed endpoints, but the annotations already establish this is a safe read.

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 leads with 'Free.' before naming the resource and contents. No filler, no repetition 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?

With no input or output schema, the description must stand alone, and it states what is returned and that the call is free. Minor gaps remain about ordering and whether the listed prices/endpoints are current, but nothing prevents a correct call.

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 tool takes zero parameters, so the baseline is 4 and there is nothing to mis-specify. The description's mention of what each entry contains (price, endpoint, input) usefully frames the output in the absence of any schema fields.

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 ('Lists every Lordevo pay-per-call service') and enumerates the categories covered (quick checks, AI verdicts, LITE tiers, SEO/security/content services). This cleanly separates it from every sibling, which are single-purpose action tools rather than a catalogue.

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?

'Free' plus 'pay-per-call service' implicitly tells the agent this is the zero-cost discovery step before invoking any of the priced sibling tools. It lacks an explicit 'call this first to pick a service' instruction or named alternatives, so it stops short of full 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?

Annotations only declare readOnly/openWorld/idempotent; the description adds the critical non-obvious behavior: paid at $0.005 per call via x402, first call returns payment terms and must be retried with _meta["x402/payment"], and robots.txt is obeyed. Cost, auth handshake, truncation limit, and latency are all disclosed beyond 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?

Front-loads the cost/payment requirement, which is the thing an agent must know before calling, then covers output, limits, and latency in tightly packed clauses. Dense but every sentence earns its place; the parenthetical payment mechanics are slightly clunky but necessary.

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 fully specifies the return shape (Markdown body plus title, description, lang, canonical, word count), the 60k truncation, and the payment retry loop. An agent has everything needed to call it correctly and interpret the result.

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 url parameter already documents the http(s) or bare-domain format, so the schema does the heavy lifting. The description only adds that the target must be a *public* page subject to robots.txt, which is real but marginal added meaning.

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?

"Fetch one public web page and return its main content as clean Markdown" states a specific verb, resource, and output form, and the listed return fields (title, description, lang, canonical, word count) separate it from metadata-only or audit siblings like page_meta and seo_page.

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?

"Cheapest way to give an LLM a page" plus the explicit 60k character ceiling and ~1-3 s latency give a clear sense of when this is the right call. No explicit when-not or named alternative (e.g. page_meta for metadata-only), so it stops short of 5.

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 readOnly/openWorld/idempotent annotations: discloses per-call cost and currency ($0.01 USDC on Base), the x402 payment handshake (first call returns terms, pay and retry via _meta["x402/payment"]), robots.txt compliance, and expected latency of ~1-3 s. These are exactly the operational facts an agent needs before calling a paid external 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 dense sentences with no filler; the cost and payment mechanism are front-loaded ahead of the return payload, which is the right priority for a paid tool. The long comma-separated field list is efficient, though it reads as a spec dump rather than prose.

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 fully enumerates the return payload, and it covers the non-obvious operational dimensions (cost, payment protocol, robots.txt, latency). An agent has everything needed to decide and to call 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% for the single url parameter, whose description already covers accepted formats (public http(s) URL or bare domain). The description adds nothing about URL handling, redirects, or normalization, so the schema carries the load.

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 verb and resource are precise (read one public web page), and the enumeration of returned fields (title, canonical, OG/Twitter tags, headings outline, JSON-LD, missing-alt images, word count) makes it implicitly distinguishable from page_markdown, which returns Markdown alone. It never names the sibling, so the agent must infer the split from the payload list.

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 subject matter (fetch and analyze one page), and the payment retry flow is spelled out. But there is no explicit when-to-use/when-not guidance against seo_page, page_quality, page_markdown, or seo_audit_lite, which cover overlapping ground.

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?

Beyond the annotations (readOnly/openWorld/idempotent) it discloses a non-obvious x402 payment flow including the exact retry mechanism (_meta["x402/payment"]), the per-call price, robots.txt compliance, that inference is on a local model with no cloud AI, and a ~3-20 s latency window. These are exactly the operational facts an agent cannot infer from structured fields.

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 dense block with no wasted clauses; every sentence carries information (pricing, verdict fields, metrics, environment, compliance, latency). The only weakness is ordering: the payment mechanics occupy the front of the description ahead of the core purpose, which is slightly awkward for an agent scanning for what the tool does.

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 enumerates the return contents itself (verdict, score, topic, strengths, problems, summary plus blended metrics), and it covers cost, payment handshake, latency, and robots.txt behavior. Nothing an agent needs to invoke it correctly and interpret the result is missing.

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% and the single `url` parameter already documents that a public http(s) URL or bare domain is accepted. The description adds nothing about the parameter itself, 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: an AI verdict on one page's content quality, with the return shape (high/medium/low, 0-100 score, topic, strengths, problems, summary) spelled out. It implicitly separates itself from siblings like page_markdown or seo_page by emphasizing content quality blended with measured metrics, but never names those siblings to make the distinction explicit.

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: evaluate the content quality of a single page. There is no when-to-use / when-not-to-use guidance and no pointer to an alternative sibling (e.g. seo_page for on-page SEO or page_markdown for raw extraction) even though the sibling list is crowded and overlapping.

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?

Beyond the readOnly/openWorld/idempotent annotations, the description discloses pricing, the x402 payment flow and retry mechanism, passivity, expected runtime, and what is returned. These are exactly the behavioral details an agent needs before invoking a paid remote check.

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 description is dense but every clause earns its place: cost/payment mechanics, scope, checks performed, return value, and runtime. It is front-loaded with the critical payment condition and remains compact.

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 well by stating that the tool returns a grade A+..F and fixes, and by listing the checks behind that grade. It does not describe the response shape in more detail, but it is sufficiently complete for correct selection and invocation.

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 single url parameter is fully documented in the schema, including the public http(s) URL or bare-domain format. The description reinforces the 'public website' scope but adds no further parameter semantics beyond the schema.

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 states a specific verb and resource: a passive check of a public website's HTTPS setup, with an explicit list of what is examined and a grade returned. It is clear what the tool does, though it does not explicitly name or distinguish itself from sibling tools such as security_scan_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?

The word 'passive' and the HTTPS/security-header focus imply when the tool is appropriate, but there is no explicit when-to-use guidance or named alternative for broader active scans. An agent can infer usage, but sibling selection remains ambiguous.

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 only cover safety (readOnly/openWorld/idempotent); the description adds the material behavior an agent needs: the x402 payment handshake (first call returns terms, retry with _meta["x402/payment"]), the $0.15 cost, the 3-10 s latency, and that it is non-intrusive versus the ownership-verified Deep scan. These are exactly the traits annotations cannot express for a paid, network-facing 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?

One dense paragraph, front-loaded with the thing an agent most needs to know for a paid endpoint (price and payment retry mechanics), then scope, then alternatives. The check enumeration is useful but the parenthetical list is long; nearly every clause earns its place, though it could be split into shorter sentences for scanability.

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 cost, the two-step payment flow, runtime, what is and isn't scanned, output shape (grade + top 10 findings), and escalation options. With no output schema and a trivial single-param input, nothing an agent needs to call this correctly and interpret the response is missing.

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 (url) and the schema already documents it at 100% coverage with an example format, so the description is not required to compensate. The description adds nothing about URL handling (e.g., redirects, bare-domain normalization) that would extend the schema's meaning, 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 website security scan) and enumerates the exact checks performed (headers, TLS, cookies, SPF/DKIM/DMARC, CAA, IPv6, security.txt), plus the outputs (A-F grade, top 10 findings). It distinguishes itself as the LITE tier versus the $1 Safe check and $5 Deep scan, but never differentiates from the closely related sibling security_headers, which is a subset of this 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?

Clear context for when this is the right call: passive, non-intrusive, fast (~3-10 s), cheap ($0.15), and no ownership verification needed. The upgrade path makes the when-not condition implicit (choose Safe/Deep for more depth), but it does not explicitly tell the agent when to pick security_headers or seo_audit_lite over this.

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 readOnly/openWorld/idempotent annotations: it discloses the x402 payment handshake (first call returns payment terms, then retry with _meta["x402/payment"]), the $0.10 price, and the ~5-15 s runtime. It also enumerates exactly what gets checked (404s, mixed content, headings, structured data, OG, robots.txt/sitemap/llms.txt) and how issues are ranked.

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 non-obvious payment mechanics, then scope, deliverables, runtime, and the upsell. The long list of checked items is dense but each item earns its place; the only mildly redundant bit is restating the LITE-vs-$2 framing twice.

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 compensates by enumerating the returned issues and inspected surfaces, plus the price, runtime, and payment flow an agent needs before calling a paid open-world tool. Nothing material for correct invocation is missing.

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 only one parameter and schema description coverage is 100%, so the schema already defines 'url' as a public http(s) URL or bare domain. The description adds no format or edge-case guidance beyond that, 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+resource+scope: a LITE one-page SEO audit returning the top 10 issues ranked by severity and effort. It explicitly distinguishes itself from the full $2 SEO Audit tier, but says nothing about how it differs from sibling tools like seo_page or page_quality that also analyze a single page.

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?

"LITE version of the $2 SEO Audit: one page" plus the explicit upgrade line gives a clear cost/scope tradeoff for choosing this over the full audit. It stops short of naming when to prefer sibling single-page tools (seo_page, page_quality, page_meta) instead.

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 far beyond the readOnly/openWorld/idempotent annotations by disclosing the x402 payment flow ($0.03/call, first call returns terms, retry with _meta['x402/payment']), robots.txt obedience, and a ~2-5 s latency budget. These are exactly the traits an agent needs before invoking a paid network call.

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?

Information-dense and mostly front-loaded, but it opens with billing mechanics before saying what the tool does, which delays the purpose statement. The long comma-chain of checks is readable but could be grouped.

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 value (score 0-100 with issues and fixes) and the full check inventory. Payment, latency, and compliance constraints are all covered, leaving nothing an agent must guess.

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% for the single `url` parameter, so the schema carries the format detail. The description reinforces scope ('of one URL') and implicitly requires a public http(s) target via the robots.txt note, but adds no new syntax.

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 ('on-page SEO check of one URL') and enumerates the exact checks performed, which clearly separates it from site-wide siblings like seo_audit_lite or site_verdict. The scope word 'one URL' is unambiguous.

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?

Scope implies usage (single page), but it never says when to prefer this over seo_audit_lite or page_quality, nor any prerequisites beyond a public URL. The robots.txt compliance note is helpful context but not routing 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?

Goes well past the annotations by disclosing the paid model ($0.05/call via x402, USDC on Base), the exact retry protocol (first call returns payment terms; pay and retry with _meta["x402/payment"]), and expected latency (~3-8 s). These are operational facts an agent cannot get from readOnlyHint/idempotentHint/openWorldHint and would otherwise fail on.

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 tight four-sentence block with no filler; each clause carries either scope, use case, or payment mechanics. The payment sentence is dense but load-bearing, though leading with price ahead of what the tool does slightly buries the purpose.

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 composite read-only tool with no output schema, the description covers the four result families, the price/payment flow, and runtime — enough for an agent to call it and handle the 402-style handshake. It stops short of describing failure modes (unreachable sites, non-public URLs) or the result shape, which is acceptable given the annotation coverage.

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 single parameter is already fully documented (public http(s) URL or bare domain). The description only adds 'for a website', which does not extend meaning beyond the schema — the baseline 3 for high-coverage schemas 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?

Names a specific resource (a website) and enumerates exactly what is returned: on-page SEO score/issues, security headers/TLS grade, tech stack, and SPF/DKIM/DMARC. That enumeration cleanly separates it from the single-purpose siblings (seo_page, security_headers, tech_stack, email_auth) and from the verdict-style site_verdict.

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?

Gives concrete use cases (lead qualification, vendor due diligence) and a clear positioning rule: 'a first look before a full audit', which implies the deeper audit tools come later. It does not name a specific alternative or state exclusions, so it falls short of a 5.

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 description adds substantial behavioral context beyond the annotations: it discloses cost ($0.02), the x402 payment flow including the first-call payment-terms behavior, expected latency (~3-20 s), and that processing runs on Lordevo's local model rather than cloud AI. It also lists the public signals used, giving the agent a clear sense of what the tool evaluates.

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 description is dense but mostly earns its length by covering payment, outputs, signals, processing model, and latency. It is less front-loaded than ideal because it opens with pricing and payment mechanics before stating the core purpose, but the information remains useful and organized in a single readable paragraph.

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 adequately explains return values: verdict labels, a 0-100 trust score, and short reasons. It also covers cost, payment flow, and latency, but does not describe failure modes or what happens for unreachable or invalid URLs, leaving a minor gap.

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 only one parameter, and the input schema has 100% description coverage, fully defining the url field as a public http(s) URL or bare domain. The description does not add further URL syntax or validation semantics, so the baseline of 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 description clearly states the resource and outcome: an AI trust verdict for a website, with concrete labels (likely_legit / caution / suspicious), a 0-100 score, and short reasons. It distinguishes itself from sibling audit tools by focusing on legitimacy/trust signals rather than general SEO, security, or page metadata, though it does not explicitly name those 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 implied by the title and description: use this when you need a trust/legitimacy verdict for a website. However, there is no explicit when-to-use guidance versus siblings such as security_scan_lite, page_quality, or site_snapshot, and no stated exclusions or conditions.

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 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.