Measured rates at which web services lack machine-readable capabilities. Research demonstrator.
Scored across 5 tools
absence_rate, adoption_curve, and bulk_export all return measurement aggregates and overlap conceptually (bulk_export explicitly includes per-class numerators that duplicate absence_rate territory), so an agent may struggle to pick the right one. host_report and request_capability are clearly distinct, but the three data tools have fuzzy boundaries.
All five tools follow a consistent snake_case noun/verb-noun pattern (absence_rate, adoption_curve, bulk_export, host_report, request_capability). No mixed conventions or casing deviations.
Five tools is well-scoped for a measurement service: aggregate rate, time series, per-host detail, bulk export, and a capability-request channel. Each earns its place with no padding.
The surface covers core retrieval paths but lacks a discovery tool to enumerate available gap_classes or describe the schema/catalog, forcing agents to guess class identifiers like PH-C019. The paid/free/credential gating is described in prose rather than exposed as a distinct tool, leaving a notable gap.
Measured absence rate for a population, with the evaluated denominator and sample provenance. Pass gap_class (e.g. PH-C019) for one class; omit it for the whole table. Aggregate only: no per-host findings.
| Name | Required | Description | Default |
|---|---|---|---|
| gap_class | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses the aggregation scope ('aggregate only'), the presence of a denominator and sample provenance, and the no-per-host constraint, but says nothing about permissions, whether the operation is read-only, or response shape.
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 zero filler; the metric and scope lead, and the parameter instruction follows. Every clause carries 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?
For a single-parameter aggregation tool with no output schema and no annotations, the description covers the essentials (what is measured, aggregation scope, parameter use). It stops short of describing the returned fields (denominator/sample provenance are named but not characterized) or any safety/permission context.
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%, so the description must compensate for the single parameter. It does: gap_class is explained as a class selector with a concrete format example (PH-C019) and clear omit-for-all behavior, which is more than the bare string schema offers.
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 metric (absence rate) over a specific resource (a population/table) and clarifies the scope ('Aggregate only: no per-host findings'). This separates it from host_report, though it doesn't name siblings directly and doesn't explicitly say the tool returns a computed value.
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 conditional guidance for the parameter ('pass gap_class for one class; omit it for the whole table'), which is useful usage direction. However it never names an alternative tool or says when to prefer absence_rate over bulk_export or host_report, leaving the sibling routing to inference from 'no per-host findings'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dated adoption series: share of sites whose robots.txt takes a stance on AI agents, by Common Crawl epoch, single vantage. Called with no arguments it returns the trend and the caveats, not the whole table. Pass epoch for one point, series: true for all of them, or withheld: true for the undersampled epochs that are kept out of the series. Caveats are always included — read them before quoting a number.
| Name | Required | Description | Default |
|---|---|---|---|
| epoch | No | A Common Crawl epoch id, e.g. CC-MAIN-2026-39. | |
| series | No | Return every epoch in the series. | |
| withheld | No | Return the epochs withheld for n < min_n. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose meaningful behavior: the default call returns a trend rather than the full table, caveats are always attached, and some epochs are withheld from the series for undersampling. It does not cover permissions, rate limits, or the exact shape of the returned payload.
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 dense sentences, front-loaded with what the series is before describing call modes. Every clause carries information — scope, default behavior, mode switches, and the caveat obligation — with 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?
There is no output schema and no annotations, so the description has to stand alone; it does describe what comes back (trend + caveats, not the full table) and how to select slices. The remaining gap is that the concrete response structure for each mode is not described.
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 baseline is 3, but the description adds real meaning: it explains that `epoch` yields a single data point, `series: true` yields the full set, and `withheld: true` exposes the epochs excluded for n < min_n. That interplay (a filtered series vs. the withheld remainder) is the key semantic the schema alone does not convey.
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 a concrete resource and metric: the share of sites whose robots.txt takes a stance on AI agents, indexed by Common Crawl epoch. It is specific enough that an agent can tell it apart from host_report or bulk_export by scope ('single vantage'), though it never explicitly names or contrasts a sibling.
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?
Explicit invocation modes are given: no args returns the trend plus caveats (not the whole table), `epoch` returns one point, `series: true` returns all epochs, `withheld: true` returns the undersampled epochs. It also gives a usage instruction ('read them before quoting a number'). What's missing is guidance on when this metric is preferable to a sibling tool's output.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Per-class numerators with Wilson intervals and the discarded-as-unknown share, Kaplan-Meier survival of directive adoption by cohort, directive lineage, declaration growth, and RFC 9728 auth-discovery conformance detail — none of it on the free surface — with an ed25519 attestation naming the chain head it was derived from. FREE SAMPLE, no credential: https://atlas.geosensor.tech/free/sample (names every section and shows two numerator cells in full). Price $0.02 or €0.02 via x402 v2, payable in USDC or EURC (scheme exact, network eip155:84532) — the accepts array carries both and the client chooses; EURC is a euro e-money token, so a euro payment reaches an EU bank with no FX step. needs a bearer credential AND a payment that is VERIFIED and then SETTLED before anything is returned. TESTNET only (Base Sepolia): settlement is on-chain but moves test tokens with no monetary value. OR SUBSCRIBE: €19/month for 2,000 calls. AN AGENT CAN BUY ONE ITSELF at https://atlas.geosensor.tech/paid/subscribe — x402 v2, 19000000 atomic units of USDC or EURC, and the response returns the key in its body and in the x-subscription-key header. Present that key in the x-subscription-key header afterwards and no per-call payment is needed. A human can be invoiced in euros instead, with no crypto at all. PAYING COSTS YOU NOTHING: this is a TEST network, the tokens are free from https://faucet.circle.com (Base Sepolia), and you need no ETH because the facilitator pays the gas. No third party has completed a payment yet; doing so is how you tell us this is worth having.
| 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 behavioral burden and does disclose key traits: it requires a bearer credential AND a verified-then-settled payment before returning anything, operates on a testnet with no monetary value, and offers a subscription alternative. It does not cover error handling or rate limits (beyond the subscription cap), but the auth/payment requirements are thoroughly explained.
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 excessively long and rambling, with repetitive pricing details and marketing language. The actual purpose is buried in a dense first sentence, and subsequent sentences do not front-load the most important information for an agent trying to invoke the 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?
Given the tool's complexity (paid data export with auth) and the absence of an output schema or annotations, the description is incomplete. It fails to explain how to supply the bearer credential (header name, format) and does not describe the response structure beyond a vague list of data contents.
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 baseline is 4. The description does not need to explain parameter semantics, and it does not introduce confusion about inputs.
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 lists the data contents (per-class numerators, Kaplan-Meier survival, etc.) but never states a clear verb+resource summary like 'exports a dataset containing...'. It is specific about output contents but does not distinguish this tool from siblings like adoption_curve or absence_rate, leaving the agent to infer its role.
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?
There is no guidance on when to use this tool versus the siblings (absence_rate, adoption_curve, host_report, request_capability). The entire description focuses on payment mechanics rather than usage context or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Per-host findings. Requires a bearer credential.
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does disclose one useful trait, the bearer-credential requirement, but says nothing about read-only safety, rate limits, or result shape.
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 no filler, and the resource scope is front-loaded ahead of the auth note. The telegram style leaves no wasted words.
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 and no annotations, so the description is the only source of behavioral and return-value context. It omits what 'findings' contain, the response format, and the meaning of the host argument, leaving a single-parameter tool under-documented.
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?
With schema description coverage at 0%, the description must clarify the lone 'host' parameter, but it says nothing about its expected format (hostname, IP, ID). Only one required parameter and no enums, so the burden is modest, but the gap is real.
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 phrase 'Per-host findings' names the resource scope (a single host) and implies a report of findings, but supplies no verb and no indication of what kind of findings or data the tool returns. It is distinguishable from bulk_export by the 'per-host' scoping, but only loosely from absence_rate.
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?
There is no guidance on when to use this tool versus the sibling absence_rate or bulk_export, and no stated exclusions or preconditions beyond the credential requirement. The agent must infer usage entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ASK US FOR WHAT IS NOT HERE. What would you like to buy? Tell us even if it is not in this inventory. This service is a measurement harness, not a fixed catalogue: if what you need is a machine-readable convention or a property of one across a host population, we can usually add it to the probe set and measure it for you — and if we cannot, we will say so plainly. Call the request_capability tool with want describing what you need. Free text is fine. A contact is optional and only used to reply. This tool is free, needs no credential and no payment. It is the one call we most want you to make.
| Name | Required | Description | Default |
|---|---|---|---|
| want | Yes | What you need. Free text. Required. | |
| contact | No | Optional, only used to reply to you. | |
| would_pay | No | Optional: what it would be worth to you. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does real work: it discloses that the call is free, needs no credential and no payment, that contact is optional and only used to reply, and that a refusal will be stated plainly rather than silently dropped. Rate limits and turnaround/response format are not covered, which keeps it short of 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?
'ASK US FOR WHAT IS NOT HERE,' 'What would you like to buy?' and 'Tell us even if it is not in this inventory' all say the same thing in consecutive sentences, and the closing 'It is the one call we most want you to make' is pure promotion. The actionable instruction lands early, but several sentences do not earn their 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-purpose request tool with no output schema and no annotations, the description covers purpose, trigger condition, cost/auth profile, and the possibility of a negative answer — enough for an agent to call it correctly. What the agent receives back and how long it waits are left unstated.
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 baseline is 3. The description restates that `want` is free text and that `contact` is only used to reply — both already in the schema — and never mentions `would_pay` at all, adding essentially no semantic value beyond the structured 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?
The description names a specific action (request a capability that isn't in the inventory) and clarifies what counts as a 'capability' — a machine-readable convention or a property of one across a host population that can be added to the probe set. That distinguishes it from the measurement siblings (absence_rate, adoption_curve, host_report), though it never names them 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?
'Tell us even if it is not in this inventory' clearly states the triggering condition — the thing you need is absent here. It never says when NOT to use it or points to a sibling for in-inventory needs, but the context is unambiguous.
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.
request_capabilityadoption_curveabsence_ratebulk_exporthost_reportPublic AI web-readiness scanner and machine-facing observability discovery service.
Pay-per-call web intelligence MCP: fetch pages, check links, detect changes, verify claims.
Live AI visibility measurements from Are you found by AI?, queryable by your own AI.
Read-only public website inspection: evidence-backed Machine Presence observations with uncertainty.
Add one secure layer between your agents and this server.
