audit.domains - Domain Valuation

Check whether domain names are registered

check_domain_availability

Read-onlyIdempotent

Check up to 25 domain names live against DNS and the registries' own RDAP records and say which are registered and which look available to register, with registration and expiry dates for lists of five or fewer. Pass alternativesFor with one name or label to check it across .com, .net, .org, .io, .ai, .co, .app, .dev and .xyz. Use it before suggesting any name as available: an answer from memory is often wrong. Use inspect_domain instead for the full public record of one name, and appraise_domain for what a name is worth. Status is unregistered (the registry has no record), likely_unregistered (no DNS and no RDAP for that suffix), registered or unknown; a registry can still reserve or premium-price a name that looks available. Read-only, free, no key; makes one or two DNS and RDAP requests per uncached name, runs no valuation.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`domains`	No	Full domain names to check, up to 25, such as brightpath.com. Pasted URLs are accepted; duplicates are checked once.
`alternativesFor`	No	One name or bare label, such as brightpath or brightpath.com, to check across nine popular suffixes. Combined with domains, the total is capped at 25.

Output Schema

TableJSON Schema

Name	Required	Description
`limit`	No	Present with pending: code lookup_limit, retryable, retryAfterSeconds, and retry ({tool, arguments}: send it unchanged after that wait to continue exactly where this call stopped). Where a key lifts the limit, upgrade says how.
`budget`	No	This request's uncached-lookup budget: lane (free or keyed), used, limit, remaining, and keyRejected when a key was sent and refused. Cached names cost nothing.
`caveat`	Yes
`citeAs`	Yes	A structured citation. Quote `text` or build your own from the fields. Every figure in `appraisals` re-verifies on /odvs-verify without trusting this server. Tools whose answer is not an appraisal (a bracket, which withholds estimates by contract, and the recorded-sales tools, whose rows are not hashed) return an empty `appraisals`. A stored interval also has no ODVS record: its artifact digest is provenance, not a standalone proof of these projected fields.
`invalid`	No	Inputs that are not domain names; nothing was looked up for them.
`pending`	No	Names not checked because the lookup limit was reached. limit.retry is the call that checks them.
`results`	Yes
`citation`	Yes
`acquireUrl`	No	Present on a short list whose wanted name is taken and not listed: a request for audit.domains to approach the owner (fee only if bought).
`forSaleCount`	No	Taken names whose owner sells them (a live checkout here or the owner's own _for-sale DNS record); each carries forSale.
`availableCount`	Yes	Names whose status is unregistered or likely_unregistered.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 15, 2026

changedOutput schema / properties / citeAs / description

Previous value: -"A structured citation. Quote `text` or build your own from the fields. Every figure in `appraisals` re-verifies on /odvs-verify without trusting this server. Tools whose answer is not an appraisal (a bracket, which withholds estimates by contract, and the recorded-sales tools, whose rows are not hashed) return an empty `appraisals`."New value: +"A structured citation. Quote `text` or build your own from the fields. Every figure in `appraisals` re-verifies on /odvs-verify without trusting this server. Tools whose answer is not an appraisal (a bracket, which withholds estimates by contract, and the recorded-sales tools, whose rows are not hashed) return an empty `appraisals`. A stored interval also has no ODVS record: its artifact digest is provenance, not a standalone proof of these projected fields."

Changed2 schema fields changedOct 8, 2026

addedOutput schema / properties / results / items / properties / next

Added value: +{
+  "description": "The one step that moves this name forward: {tool, arguments} to call next on this server, or {url} to open; why says what it gets. Null when nothing here does (for a free name, registering it at a registrar).",
+  "type": [
+    "object",
+    "null"
+  ]
+}

changedOutput schema / properties / results / items / required

Previous value: -[
-  "domain",
-  "status",
-  "source",
-  "checkedAt",
-  "reportUrl"
-]New value: +[
+  "domain",
+  "status",
+  "source",
+  "checkedAt",
+  "reportUrl",
+  "next"
+]

AddedOct 8, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/openWorld, yet the description adds substantial context: free, no key, one or two DNS/RDAP requests per uncached name, no valuation performed, and the caveat that a registry can still reserve or premium-price an apparently available name. The status taxonomy is explained rather than assumed.

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

Conciseness4/5

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

Dense but front-loaded: capability, then the alternativesFor expansion, then the usage directive, then routing, then status semantics. Every clause carries information, though the single long paragraph could be slightly tighter.

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?

An output schema exists so return values need not be spelled out, yet the description still defines the four status values and the 5-name limit for dates. Combined with the request/auth behavior notes, 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.

Parameters4/5

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 goes further by enumerating the nine suffixes alternativesFor covers (.com through .xyz) and noting registration/expiry dates are returned only for lists of five or fewer, which the schema does not state.

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?

Specific verb (check) plus resource (domain registration status), with explicit scope limits (up to 25 names, DNS + RDAP sources). It cleanly distinguishes itself from inspect_domain and appraise_domain by naming both siblings and what they do instead.

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?

States when to use ('Use it before suggesting any name as available: an answer from memory is often wrong') and names two concrete alternatives with their differing purposes. The routing guidance is unambiguous.

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

All audit.domains - Domain Valuation 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?