Afriref: cited government reference data

domain_age

Read-onlyIdempotent

PAID ($0.005). Not for registries without RDAP, e.g. .za/.co.za, .me, .de, .io, .eu: refused free (422). Use when you need to know which registrar holds a domain, how old it is, and whether it is a risky newly-registered domain. $0.005. From the registry's RDAP: registrar name and IANA ID (no registrant or contact data), created, expires, last changed, status flags, DNSSEC delegation, nameservers; fail under 30 days old or expired, warn under 180 days, expiring within 30 days or on hold. A registry without RDAP is refused free. MCP: pass api_key (an Afriref key, card credit at https://afriref.dev/pricing); per-call x402/MPP payment is HTTP only, so without a key the result is an api_key_required error naming the HTTP endpoint.

Input Schema

Name	Required	Description	Default
`domain`	Yes	Domain or hostname, e.g. example.com (no URL, no IP)
`api_key`	No	API key (bypasses x402; metered for invoicing)

Output Schema

Name	Required	Description
`fix`	No
`error`	No	Present on a free refusal or error; no charge
`grade`	No
`notes`	No
`domain`	No
`finding`	No
`diagnosis`	No
`no_charge`	No
`price_usd`	No
`checked_at`	No
`how_to_pay`	No
`explanation`	No
`registration`	No
`http_endpoint`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed16 schema fields changedOct 20, 2026

changedOutput schema / description

Previous value: -"Finished-job dossier: verdict or summary, line items, evidence with official sources. On 402 the x402 PaymentRequired object (isError)"New value: +"Registration from the registry's RDAP: grade, finding, fix and registrar, created, expires, status and nameservers. A refusal (invalid domain, registry without RDAP, api_key_required) is isError with error and explanation; nothing is charged"

removedOutput schema / properties / bind_series
```
Removed value: -{}
```
addedOutput schema / properties / checked_at
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / diagnosis
```
Added value: +{}
```
removedOutput schema / properties / disclaimer
```
Removed value: -{}
```
addedOutput schema / properties / domain
```
Added value: +{
+  "type": "string"
+}
```

removedOutput schema / properties / evidence

Removed value: -{
-  "items": {},
-  "type": "array"
-}

addedOutput schema / properties / finding
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / fix

Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / grade
```
Added value: +{
+  "type": "string"
+}
```

removedOutput schema / properties / job

Removed value: -{
-  "type": "string"
-}

addedOutput schema / properties / notes

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

removedOutput schema / properties / payment_required

Removed value: -{
-  "description": "true when the call needs payment; how_to_pay explains x402 or card",
-  "type": "boolean"
-}

addedOutput schema / properties / registration
```
Added value: +{}
```

removedOutput schema / properties / status

Removed value: -{
-  "type": "string"
-}

removedOutput schema / properties / x_next_bind
```
Removed value: -{}
```

AddedOct 19, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, and the description adds substantial context on top: paid pricing, free refusal for non-RDAP registries, fail/warn thresholds (under 30 days, under 180 days, expiring within 30 days, on hold), and an explicit auth failure mode (api_key_required when no key is supplied over MCP). This is rich, non-obvious behavioral detail 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.

Conciseness3/5

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

The description repeats itself: the $0.005 price appears twice and the non-RDAP free-refusal (422) is stated twice. The lead opens with pricing and exclusions before stating the core purpose, so it is not fully front-loaded. Still, each block is on-topic and no filler content is present.

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?

For a paid lookup tool with an output schema already covering return values, the description covers everything an agent needs: purpose, price, auth path (api_key vs HTTP x402), failure modes, TLD exclusions, and the fail/warn decision thresholds. There is no material gap affecting correct invocation.

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?

Schema description coverage is 100%, so the baseline is 3. The description adds real meaning for api_key: that it is an Afriref key with card credit, that per-call x402/MPP payment is HTTP-only, and that omitting it over MCP yields an api_key_required error naming the HTTP endpoint. That materially explains the second parameter beyond the schema's one-line note.

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

Purpose4/5

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

The description states precisely what the tool returns: registrar name and IANA ID, created/expires/changed dates, status flags, DNSSEC, and nameservers, all from the registry's RDAP. It also frames the use case (registrar ownership, domain age, risky newly-registered domains), which differentiates it in practice from a generic check. It never names the sibling domain_check, so sibling differentiation is implicit rather than explicit.

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

Usage Guidelines4/5

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

It gives clear when-to-use ("when you need to know which registrar holds a domain, how old it is, and whether it is a risky newly-registered domain") and a concrete when-not (registries without RDAP, listing .za/.co.za, .me, .de, .io, .eu, which are refused with 422). It stops short of naming the alternative tool to use for those cases, so the routing is incomplete.

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

All Afriref: cited government reference data tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?