Desvela ARD Registry — free preflight(domain)

Test what a domain actually serves AI crawlers

crawler_block_test

What the domain's CDN really does, as opposed to what its robots.txt says. Sends each AI crawler's real user-agent at the homepage and compares the response against a browser: a site can allow GPTBot in robots.txt and still have its CDN answer it a 403, and robots.txt cannot tell you that. Verdicts per crawler: ok, blocked, throttled (429, which is "too fast" and not "not you"), degraded (a 200 with a fraction of the bytes, the shape of a JS-gated page), or error. When measurable is false the site refused the control request too and there is no verdict to give. Live probe, ~6 requests. Free. Use preflight for the declared policy; use this for the observed one.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`domain`	Yes

TDQS

A4.9/5.0

Behavior5/5

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

With no annotations, the description carries the full burden, and it delivers: it discloses live network probing, request count, cost, verdict categories (ok, blocked, throttled, degraded, error), the meaning of 429, and the no-verdict case when measurable is false. This goes well beyond the boilerplate.

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

Conciseness5/5

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

The definition is front-loaded with the core distinction and then builds with verdict semantics and a usage pointer. Every sentence and fragment carries load—there is no filler, and the fragmented 'Live probe, ~6 requests. Free.' is economical.

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

Completeness5/5

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

With no output schema and no annotations, the description still provides everything needed to invoke and interpret results: verdicts, 429 meaning, degraded-page shape, the measurable=false error case, and expected request count. It is complete for this single-parameter live probe.

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

Parameters4/5

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

The schema provides only the domain pattern, and the description does not enumerate the parameter, but it repeatedly defines the role of domain: the site whose CDN behavior is probed at its homepage. For a single self-evident parameter, this functional explanation is valuable compensation for 0% schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: what the domain actually serves AI crawlers, and immediately contrasts it with robots.txt declarations. It details an observable method (sending real user-agents and comparing against a browser), making the purpose concrete and clearly distinct from sibling preflight and search/watch.

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

Usage Guidelines5/5

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

The final sentence explicitly routes usage: 'Use preflight for the declared policy; use this for the observed one.' It also gives operating constraints through 'Live probe, ~6 requests. Free,' so an agent knows when this tool is appropriate and what it costs.

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

All Desvela ARD Registry — free preflight(domain) tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0

Disambiguation5/5

Each tool serves a clearly distinct purpose: preflight checks declared AI-agent artifacts, crawler_block_test measures observed CDN behavior, search queries the registry index, and watch subscribes to change notifications. There is no meaningful overlap or ambiguity between them.

Naming Consistency3/5

Tool names are readable and intuitive, but they follow mixed conventions: crawler_block_test uses a descriptive snake_case phrase, preflight is a single noun, and search/watch are imperative verbs. There is no consistent verb_noun or noun_noun pattern across the set.

Tool Count5/5

Four tools is well-scoped for this registry-focused service: one for declared policy, one for observed behavior, one for discovery/search, and one for change monitoring. Each tool offers a distinct capability without redundancy or bloat.

Completeness5/5

The domain is covered end-to-end: preflight provides the declared artifacts, crawler_block_test reveals actual blocking behavior, watch monitors changes over time, and search lets users discover registry entries. The internal webhook management endpoints are appropriately handled outside the MCP surface, so there are no obvious dead ends.

Resources

Need Help?