Northline WebKit

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

Annotations already declare read-only and open-world behavior, so the description appropriately focuses on what they cannot convey: cost, payment mechanics, and returned fields such as TTLs and the DNSSEC validation flag. It does not cover rate limits or non-payment failure modes, but the payment behavior is a meaningful addition.

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: the first defines the lookup and returned data, the second covers cost and payment. There is no filler, and the enum list, while long, is relevant to the tool's capability.

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 usefully discloses that responses include TTLs and a DNSSEC validation flag. It also explains the unusual payment model. It could say more about output shape or partial failures, but it is largely complete for a two-parameter lookup 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?

Schema coverage is 50%: the domain parameter is described in the schema, while the type parameter is an enum with a default. The description lists the same record types as the enum but does not explain the type parameter's default or add 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 resource and scope: DNS records for a domain over DNS-over-HTTPS, listing the supported record types. It is clearly distinct from domain_whois and domain_report in practice, but it does not explicitly name or contrast those siblings.

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 and by the payment note, but there is no explicit guidance on when to choose this tool over domain_whois or domain_report. No exclusions or alternative-selection conditions are stated.

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, the description discloses the payment model in concrete detail: $0.005 USDC on Base per call via x402, unpaid calls return PaymentRequired, and compatible x402 MCP clients pay automatically. It also enumerates the behavioral outputs, including risk flags such as newly_registered_lt_30d, which materially improves transparency for an agent deciding whether and how to invoke it.

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 front-loaded with the main value proposition, then compactly lists coverage areas and payment behavior. Every clause earns its place, and the cost/payment caveat is placed at the end without obscuring the core 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 complex multi-check aggregate tool with no output schema, the description is largely complete: it enumerates the report sections and risk flags and explains the x402 payment flow. It does not describe response structure, error behavior beyond payment, or data freshness, so it falls just short of fully complete.

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 fully documents the single required domain parameter with an example. The description does not add format, normalization, or validation details beyond what the schema provides, so 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 description states a specific aggregate operation—a one-call domain due diligence report—and enumerates the exact coverage areas: RDAP, DNS, email setup, HTTPS security headers, and risk flags. It clearly distinguishes itself as an aggregate report rather than a single-purpose lookup, though it does not explicitly name the sibling tools it replaces.

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 phrase 'one-call domain due diligence' and the coverage list make the intended use clear: gathering a broad domain risk snapshot in one call rather than making separate DNS, WHOIS, email, or URL checks. It does not spell out when-not-to-use conditions or explicitly route agents to dns_lookup, domain_whois, or email_domain_check for narrower needs.

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 and openWorldHint, so the description's real contribution is the cost and payment behavior: $0.002 USDC on Base per call, unpaid calls return x402 PaymentRequired, and x402 MCP clients pay automatically. That is exactly the kind of operational trait annotations cannot express. It omits failure behavior for invalid/nonexistent domains, which keeps it from 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?

Front-loaded with the core capability and return fields, then the cost/payment caveat in a short second sentence. Dense but every clause carries information; 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 output schema, enumerating the returned fields is the right compensation, and the payment/error flow is disclosed. An agent knows what it gets back, what it costs, and what happens on non-payment, which is everything needed 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?

There is a single parameter with 100% schema description coverage ('Domain name, e.g. example.com'), so the schema already carries the semantics. The description adds nothing about accepted formats (bare domain vs URL vs subdomain), 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?

Names a specific verb+resource (WHOIS lookup via RDAP) and enumerates the exact data returned (registrar, dates, age, status codes, nameservers, DNSSEC, abuse contact), which clearly separates it from dns_lookup or domain_report. It stops short of explicitly naming the sibling it differs from, so it lands at clear-but-not-differentiated.

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?

'Spot newly registered (phishing) domains' implies a use case, and the payment note implies when x402 clients should call it. However, there is no explicit guidance on when to prefer this over domain_report, dns_lookup, or email_domain_check, so routing is left 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 only say readOnly/openWorld; the description adds the critical non-obvious behavior: a $0.002 USDC cost on Base via x402, that unpaid calls return PaymentRequired, and that a compliant x402 MCP client pays automatically. That is exactly the payment/auth context an agent needs before invoking and is not derivable from the 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?

Two sentences, no filler; the check list is front-loaded and the payment caveat is placed after the core purpose. The capability enumeration is dense but each item maps to a real returned signal, so little could be cut without losing 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 useful work by naming the returned signals (MX status, disposable flag, provider, SPF/DMARC, risk flags). It stops short of describing the shape of the result (e.g., how risk flags are represented or what an inconclusive domain-only check returns).

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 parameter is already documented as 'Email address or bare domain'. The description's 'email address or domain' restates the schema rather than adding format, validation, or normalization guidance, 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?

Specific verb ('check') plus resource ('email address or domain') followed by an enumerated capability list: syntax, MX, mail acceptance, disposable/free provider, provider identity, SPF/DMARC, risk flags. This is clearly distinguishable from siblings like dns_lookup or domain_report, which do not cover mailbox-level deliverability signals.

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?

'before you send' gives an explicit trigger context: pre-send deliverability validation. It does not, however, name what to use instead for related tasks (url_check for URLs, domain_report for broader domain intelligence), so routing against siblings is left 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 only declare readOnlyHint and openWorldHint, yet the description discloses the $0.001 USDC cost on Base, the x402 payment flow, and that unpaid calls return PaymentRequired with automatic payment by x402 clients. It also enumerates what the response contains, which goes well beyond structured metadata.

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 core question and answer format, then payment details. Dense but every sentence carries information; the payment sentence is slightly long but justified for a paid tool.

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 must describe return values, and it does: allowed true/false, matching rule, sitemaps, and the 14 AI crawler checks. Combined with the payment behavior, an agent has everything needed 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 50%: url is documented in the schema while userAgent has only a default and no description. The description mentions 'your user agent and path', giving partial context, but does not clarify the '*' default or how path is derived from the URL.

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 ('parses robots.txt and answers allowed true/false') and frames the exact question an agent would ask ('May I crawl this URL?'). Clearly distinct from siblings like dns_lookup, url_check, and url_metadata.

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 framing 'May I crawl this URL?' makes the use context obvious, and the mention of user agent vs path clarifies scope. It does not explicitly name when to prefer a sibling or any exclusions, keeping it just under 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?

Annotations only say readOnly and openWorld; the description adds the material facts an agent needs: a $0.001 USDC charge on Base per call, that unpaid calls return an x402 PaymentRequired response, and that any x402 MCP client pays automatically. That is real operational context beyond the structured data, including the failure mode.

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: the first front-loads the capability and its outputs, the second front-loads the pricing and payment behavior. Nothing is repeated from the name or schema.

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 a single well-documented parameter, no output schema, and annotations covering the safety profile, the description supplies everything else an agent needs — result fields, cost, and the payment handshake on failure.

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 schema already documents it at 100% coverage ('Public http(s) URL (scheme optional)'). The description adds no further syntax, normalization, or validation detail, so the schema carries this dimension entirely — baseline 3.

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?

Opens with a concrete question ('Is this URL up?') and then enumerates the exact returned facts: HTTP status, redirect chain, final URL, response time, content type, server/CDN, security-headers grade. That specificity clearly separates it from siblings like url_metadata, url_links, or robots_check that also take a URL.

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 'Is this URL up?' framing plus the output list makes the use case obvious, and the x402 payment note explains what happens on an unpaid call. It stops short of naming an alternative sibling or an explicit when-not-to-use condition, 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?

Beyond the readOnlyHint/openWorldHint annotations, the description discloses the 500-link cap and, critically, the payment model: $0.002 USDC on Base per call via x402, with unpaid calls returning PaymentRequired and x402 clients paying automatically. That cost/auth behavior is exactly the operational context an agent cannot infer from annotations or 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?

Three tight sentences: output content first, then use case, then cost. Nothing is redundant and the most decision-relevant facts are front-loaded.

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 two-parameter read-only extraction tool with no output schema, the description covers what comes back (URLs, anchor text, internal/external), the volume limit, the intended use, and the payment requirement. An agent has everything needed 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%, with both parameters documented, including the only/exclude enum, so the baseline is 3. The description's 'internal vs external' phrasing corroborates the external filter's meaning but adds no format, default, or edge-case detail beyond what the schema already says.

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 precisely what the tool returns: every unique outgoing link on a web page, including absolute URLs, anchor text, and the internal/external split, capped at 500. That is far more specific than the title '/v1/url/links', though it never names a sibling (url_metadata, url_to_markdown, url_check) to differentiate itself 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?

It gives a clear positive use case: 'Use it to crawl a site or find related pages,' which tells an agent the intended scenario. There is no when-not guidance or routing to the adjacent url_* siblings, so it stops short of full alternative coverage.

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 redirect-following, the exact per-call price ($0.002 USDC on Base), the x402 payment flow, and the concrete failure mode (unpaid calls return PaymentRequired). This is exactly the context an agent needs before calling a paid 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 sentences, both dense with information: what is returned first, then payment mechanics. Zero filler and no redundancy with the schema.

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 listing the return fields explicitly. Redirect behavior and the payment prerequisite are both covered, so an agent has everything needed 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?

Only one parameter and the schema already documents it at 100% coverage ('Public http(s) URL (scheme optional)'). The description adds no syntax, normalization, or size limits for the URL, so it is at the baseline for high schema coverage.

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 (URL) and enumerates exactly what is returned: title, description, canonical, language, OG/Twitter cards, favicon, feeds, JSON-LD. This distinguishes it from siblings like url_check (availability) and url_to_markdown (content extraction).

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 'link preview and SEO metadata' framing makes the use case clear, and the pricing sentence gives an agent a reason to weigh the call's cost against alternatives. There is no explicit statement of when to prefer url_links or url_to_markdown instead, so it stops 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?

Annotations only cover readOnly and openWorld; the description adds genuinely new behavior: a $0.003 USDC charge on Base, the x402 payment flow, and the fact that unpaid calls return PaymentRequired rather than failing silently. This is high-value context that structured fields do not carry. Minor gap: no statement on truncation semantics when maxChars is hit or on non-HTML URLs.

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?

Three tight sentences: capability and return shape first, use case second, cost/payment mechanics last. No redundancy with the title and nothing that fails to earn its place.

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, so the description carries the return contract — and it does, naming Markdown content, title, word count and final URL. Combined with the payment disclosure, an agent has everything needed to call this correctly and handle the 402 case.

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 parameters are already documented with ranges and defaults. The description adds only an indirect hint about redirect handling via "final URL"; it adds nothing about url format or maxChars behavior beyond what the schema provides, 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 (Fetch) and resource (public web page) and precisely names the return artifact: main-content-only Markdown plus title, word count and final URL. That clearly separates it from siblings like url_metadata, url_links and url_check, which an agent can rule out without opening schemas.

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?

"Ideal for feeding pages to an LLM" gives a clear use context, and the main-content-only framing signals when this beats a raw fetch. However, it never explicitly names alternatives (url_metadata, url_links) or states when-not to use it, so routing between siblings is left 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 declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description still adds real context the annotations don't carry: the tool is free (cost transparency) and it also explains the x402 payment mechanism, which is otherwise invisible to the agent. It doesn't mention response size or whether the catalog can be stale, keeping it out of the 5 tier.

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 tight sentences with no filler: the free/cost note is front-loaded, the contents are itemized, and the action directive follows. Slight improvement possible by moving "Call this first" to the opening clause, since it is the most actionable instruction.

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 zero-parameter, annotation-covered tool with no output schema, the description says what the call returns (price, required inputs, example, x402 explanation) and when to make it. Nothing an agent needs to call it correctly 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?

The tool takes no parameters, so there is nothing for the description to disambiguate and the 0-param baseline of 4 applies. No parameter naming or format detail is needed 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?

States a specific verb and resource (lists every WebKit tool) and enumerates the exact payload: price, required inputs, an example, and the x402 payment flow. That makes it unmistakably distinct from the sibling DNS/URL/WHOIS tools, which all operate on a target rather than returning catalog metadata.

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?

"Call this first" gives explicit ordering guidance, which is the key usage decision for a discovery tool. It does not state exclusions or name alternatives, but there is no sibling that could substitute for a catalog, so little is left to inference.

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