Ask before you fetch: will this domain serve your crawler, refuse it, or charge it?
Scored across 7 tools
census_facts and census_stats are easy to conflate, and crawl_preflight, scan_site, and site_report overlap in that they each inspect a domain's crawler accessibility. The descriptions eventually separate them by output intent — verdicts vs audit vs stored report — but an agent must read carefully to avoid a wrong call.
All names use snake_case and are readable, but there is no consistent verb-noun rule: scan_site and submit_domains start with verbs, while census_facts, census_stats, agent_profle, crawl_preflight, and site_report are noun-like phrases. This mixed convention is understandable, though it misses the clarity of a uniform pattern.
Seven tools are well-scoped for a census-focused server: they cover agent lookups, corpus statistics, domain verdicts, audits, stored reports, and domain submission. None feels like filler, and the count stays small enough for an agent to navigate.
The core read, audit, report, and submission loop is covered: preflight verdicts, full scanned audits, cached reports, and bulk domain queueing. The only minor gap is a lack of tools to update or delete domain submissions or cached reports, but this does not seriously affect the intended census and crawler workflows.
What this census measures and publishes about one AI crawler: how often it is disallowed in robots.txt, how often live requests carrying its user agent are refused at the network edge whatever robots.txt says, whether its operator documents it as honouring robots.txt, and where to correct any of that. Intended for the operator of the agent as much as for anyone studying it, so it includes the correction channel and the public page a claim can be disputed against.
| Name | Required | Description | Default |
|---|---|---|---|
| agent | Yes | Crawler token, e.g. gptbot, claudebot, ccbot, google-extended. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden and does so well: it discloses what is measured, that live requests are checked at the network edge, that operator documentation is assessed, and that correction/dispute channels are included. It does not explicitly state read-only status or error behavior, but the 'measures and publishes' framing strongly implies a read operation.
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 purpose is front-loaded and the metric list is scannable. The second sentence slightly repeats the correction-channel idea already mentioned in the list, but it adds the audience and the dispute-page detail, so it earns 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?
For a single-parameter tool with no output schema, the description adequately conveys what data the profile returns and that correction channels are included. It could be more explicit about output format or unknown-agent handling, but the essential guidance for selecting and invoking the tool is present.
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 input schema already documents `agent` with examples like gptbot and claudebot at 100% coverage. The description only adds that the tool is about 'one AI crawler,' contributing no new parameter syntax or constraints, 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 opens with a specific verb+resource: 'What this census measures and publishes about one AI crawler.' It then enumerates the exact metrics reported, clearly distinguishing this per-agent profile tool from sibling tools that focus on sites, stats, or submissions.
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 intended use is clear: retrieve published census data about one AI crawler, aimed at both the crawler operator and external researchers. It does not explicitly name alternative sibling tools or exclusion conditions, but the usage context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every headline finding from the census as discrete, dated records rather than prose. Each carries its value, unit, denominator, measurement date, the page it comes from and a ready-made citation line, plus the caveats that apply to all of them. Use this when answering a question about how open the web is to AI crawlers: lifting a percentage out of a rendered page loses the denominator and the date, which is what makes the number wrong when it is repeated.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does so well. It discloses the structure of each returned record, the presence of caveats, and the important failure mode of losing denominators and dates when numbers are repeated. This gives an agent a clear picture of the tool's behavior.
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, well-front-loaded sentences cover what the tool returns, how records are structured, and when to use it. Every clause earns its place, with no filler or repetition.
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 tool with no output schema, the description is remarkably complete: it explains the record fields, caveats, and the specific use case. An agent can understand what it will get back and why it is the right tool without further clarification.
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 input schema has zero parameters, so this is the baseline-4 case. The description focuses on output record semantics rather than parameters, which is appropriate since there is nothing to document.
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 that this tool returns census headline findings as discrete, dated records with value, unit, denominator, date, page, and citation. It distinguishes itself from prose-style reporting, but it does not explicitly differentiate itself from the sibling census_stats, so some overlap remains.
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 an explicit 'Use this when...' trigger tied to questions about how open the web is to AI crawlers, and explains why the dated/denominator-preserving format matters. It does not mention alternatives or when not to use it, so routing guidance is strong but not complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Corpus-level statistics: how many measured domains block each AI crawler, mean access score, llms.txt adoption.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It states what data is included but does not reveal whether it is read-only, how recent the statistics are, whether any parameters or filters exist, or what the response structure looks like. The colon-led list of statistics is content, not behavioral transparency.
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 a single concise sentence that leads with the core concept ('corpus-level statistics') and then lists specific examples. There is no filler or redundant language, making it easy to parse.
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 parameterless tool, the description gives enough to understand what kind of data comes back, but it omits an explicit return format and does not clarify the scope of 'measured domains' or any access prerequisites. The missing output schema means the description could reasonably be expected to say more about the result shape.
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 has zero parameters, so the schema fully covers any input concerns. The description adds value by explaining what the resulting statistics measure, which complements the empty schema without needing to compensate for undocumented parameters.
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 names the resource ('corpus-level statistics') and specifies three concrete metrics: per-crawler blocking counts, mean access score, and llms.txt adoption. This gives an agent a clear idea of what the tool computes, though it does not explicitly distinguish itself from the similarly named sibling census_facts.
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 'corpus-level statistics' implies this is for aggregate data, but there is no explicit statement of when to use this tool versus alternatives like census_facts or scan_site. No when-not conditions or alternative names are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decide whether a crawler may fetch a list of domains before spending requests on them. Works for any crawler token, not only the ones this census tracks: an unrecognised agent is resolved from each domain's stored robots.txt rather than refused. For each domain returns one of: allow (robots permits it and a live request carrying that agent's user agent was served), disallow (robots.txt forbids it), refuse (robots permits it but the edge refused the agent anyway, so the allowance is not real), pay (the origin answered HTTP 402 Payment Required, meaning it will serve this agent on commercial terms), or unknown. The full definition of each, including what it obliges a crawler to do, is published at https://crawlcensus.com/api/v1/verdicts. Built for crawler operators rather than site owners: it prevents wasted fetches against doors that are shut, and flags content an operator is trying to sell rather than withhold.
| Name | Required | Description | Default |
|---|---|---|---|
| agent | Yes | Crawler token, e.g. gptbot, claudebot, perplexitybot, oai-searchbot, ccbot. | |
| domains | Yes | Domains to check. Up to 25 per call anonymously; send an Authorization: Bearer key for more. An over-large batch is refused outright rather than partly answered. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and goes beyond the basics: it reveals that a live request is sent to verify serving, that unrecognised agents are resolved from robots.txt rather than refused, and that 'refuse' means an allowance is not real. It also links to full verdict definitions. Minor omissions like rate-limit behavior are already covered in 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?
The description is dense but every sentence earns its place: purpose, verdict list, unknown-agent behavior, authoritative link, and audience. It is front-loaded with the core decision purpose. Slightly longer than necessary, but no filler or repetition.
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?
The description is complete despite having no output schema: it enumerates all possible return verdicts with definitions, explains edge-case behavior for unknown agents, and provides a link for full semantics. Combined with a 100%-covered input schema, an agent has all needed information to invoke the tool 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%, so baseline is 3. The description adds meaningful context for the 'agent' parameter by explaining it works for any crawler token and how unrecognised agents are handled, which goes beyond the schema's list of examples. It also clarifies the 'domains' parameter's per-domain output semantics.
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?
Description opens with a specific verb+resource ('Decide whether a crawler may fetch a list of domains'), then enumerates the five possible verdicts with precise meanings. It also distinguishes itself from sibling census/site tools by stating it is 'Built for crawler operators rather than site owners' and by handling 'any crawler token, not only the ones this census tracks.'
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?
Explicitly tells when to use the tool ('before spending requests on them') and for whom ('crawler operators rather than site owners'), which excludes site-owner workflows that would be served by other siblings. It also explains the unrecognised-agent behavior, aiding correct selection for non-census crawlers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a live AI-accessibility audit of a domain: robots.txt policy for every tracked AI crawler, live user-agent probes, JavaScript-free readability, structured data and llms.txt. Returns a score out of 100 with per-check detail.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Bare hostname, for example example.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It transparently explains that the tool performs live probes, checks robots.txt and llms.txt, and returns a score with per-check detail. It does not mention potential side effects or operational caveats, but the core behavior is well disclosed.
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 information-dense sentence that front-loads the purpose and uses a compact list to convey scope, then states the return format. No filler or redundancy.
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 tool with one parameter and no output schema, the description is largely complete: it explains what checks are performed and what the return value looks like (score out of 100 with per-check detail). Minor gaps are the lack of alternative routing and any timing/side-effect context, but nothing critical 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 parameter 'domain' is already well documented with an example. The tool description adds no additional parameter semantics beyond what the schema provides, 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 a specific verb ('Run') and resource ('a live AI-accessibility audit of a domain'), and enumerates concrete checks. It does not explicitly distinguish itself from sibling tools like site_report or crawl_preflight, but the scope is specific enough that an agent can infer its function.
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 description implies when to use it: when a live AI-accessibility audit of a domain is needed. However, it gives no explicit guidance on when to choose this tool over siblings such as site_report or crawl_preflight, and offers no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the most recent stored audit for a domain without triggering a new scan. Faster and free of load on the target site.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Bare hostname |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the key behavioral traits: it is a read of stored data, it does not trigger a scan, and it imposes no load on the target. It stops short of describing behavior when no stored audit exists, but the main side-effect profile is clear.
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 with no wasted words; the primary action and the no-scan guarantee are front-loaded, followed by a benefit. Every phrase earns 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?
For a simple one-parameter read-only report tool with no output schema, the description covers the core contract: what is returned, the absence of a scan, and the speed/load benefit. It does not specify the return format or error behavior, but the tool's simplicity keeps these gaps minor.
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 input schema already describes domain as 'Bare hostname' with 100% coverage, so the description adds no additional parameter meaning. Baseline 3 applies because the schema handles parameter documentation.
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 ('Return'), resource ('most recent stored audit for a domain'), and explicitly distinguishes itself from a scan by saying it does not trigger a new scan. This makes its purpose clear and differentiates it from the sibling scan_site.
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 'without triggering a new scan' plus 'Faster and free of load' gives clear context for when to use this tool: when a stored report is acceptable and no active scan is desired. It does not explicitly name scan_site as the alternative, but the intended use case is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Queue domains the census has not measured yet so a later crawl_preflight can answer them. This closes the loop crawl_preflight starts: anything it returns as unknown with measurable true is worth submitting, and the reply names any that were already fresh or that this census will never measure, so a caller looping over its own unknowns converges instead of resubmitting the same set. Queueing is a database write rather than a fetch, so the allowance is far higher than scan_site and submitted domains are measured ahead of the ranked backlog.
| Name | Required | Description | Default |
|---|---|---|---|
| domains | Yes | Hostnames to queue. Up to 50 per call anonymously; an over-large batch is refused outright rather than partly queued. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description correctly discloses the core side effect: 'Queueing is a database write rather than a fetch.' It also reveals reply behavior, naming already-fresh or never-measured domains, though exact rate limits and idempotency semantics are not fully specified.
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 sentences pack the purpose, workflow, and operational distinction without filler. The first sentence front-loads the core action, while the later sentences add necessary context about the crawl_preflight loop and the allowance difference from scan_site.
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 mutation tool with no annotations and no output schema, the description covers when to call, what to submit, the side effect, and the response's role in convergence. It leaves numeric limits and idempotency guarantees implicit, but enough information exists for correct 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?
Schema coverage is 100% with a clear field description, so the parameter itself is well documented. The tool description adds value by defining eligibility: only domains the census has not measured yet, specifically those flagged by crawl_preflight as unknown with measurable true.
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 object: 'Queue domains the census has not measured yet.' It also explicitly ties the tool to crawl_preflight's 'unknown with measurable true' results, distinguishing it from retrieval-focused siblings like scan_site and site_report.
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 an explicit selection rule: anything crawl_preflight returns as unknown with measurable true is worth submitting, and it warns that fresh or never-measured domains appear in the reply so a caller can avoid resubmission. It also contrasts the database-write allowance with scan_site, helping an agent choose between them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
submit_domainsagent_profilecensus_factscensus_statscrawl_preflightscan_sitesite_reportWhether an AI agent may fetch a URL, on what terms, and at what price. Free, no key, no signup.
Checks if a URL path is allowed by robots.txt. x402 payment required (testnet USDC).
Robots-aware website audits, pre-crawl quotes, and structured evidence for people and agents.
What a domain publishes for AI agents: ai-catalog.json, llms.txt, agents.md, robots.txt rules. Free.
Add one secure layer between your agents and this server.
