audit.domains - Domain Valuation

Suggest domain names that look available

suggest_available_names

Read-onlyIdempotent

Build domain-name candidates from one to five keywords (the keywords joined, paired, and with common brand prefixes and suffixes such as get, try, hq, labs and app), screen up to 60 of them live against DNS and the registries' RDAP records, and return only those that look available to register, up to 12, plus the ones found taken. Same keywords and options, same candidates in the same order. Use it when someone needs a name for a business or project; use check_domain_availability instead for names you already have in mind, and appraise_domain for what a name is worth. Looks available is a registration fact, not a price: a registry can reserve or premium-price a name. Read-only, free, no key; one DNS request per uncached candidate and an RDAP request per free-looking one, runs no valuation.

Input Schema

Name	Required	Description
`tlds`	No	Suffixes to try, in order of preference, from com, net, org, io, ai, co, app, dev and xyz. Defaults to com, io, ai, co, app.
`count`	No	How many available names to return, 1 to 12. Defaults to 8.
`cursor`	No	nextCursor from an earlier call with the same keywords and options: continues screening where that call stopped, for more names or after a lookup limit.
`keywords`	Yes	One to five keywords or a short phrase, such as "solar bakery" or ["bright", "path"]. Filler words (the, for, company) are dropped.
`maxLength`	No	Longest label to suggest, before the suffix, 4 to 20 characters. Defaults to 15.

Output 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.
`taken`	No	Screened candidates that are registered, first 10.
`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.
`pending`	No	Names not checked because the lookup limit was reached. limit.retry is the call that checks them.
`citation`	Yes
`keywords`	Yes
`screened`	Yes	Candidates looked up.
`nextCursor`	No	Pass as cursor to continue screening the same keywords from where this call stopped (more names, or after a lookup limit). Null when every candidate has been screened.
`suggestions`	Yes

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."

AddedOct 8, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the readOnly/idempotent/openWorld annotations, it discloses the screening cap (up to 60), the return cap (up to 12 plus taken names), per-call request costs (one DNS per uncached candidate, one RDAP per free-looking one), that no key is required, and the important caveat that 'looks available' is a registration fact, not a price — a registry may reserve or premium-price.

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?

Front-loaded with purpose, then usage routing, then constraints — every sentence carries information. It is dense and somewhat long, and 'Read-only, free, no key' partly restates the readOnlyHint annotation, but there is little true waste.

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 a full output schema present, return values need not be described, and everything an agent needs to invoke correctly — inputs, screening behavior, cost model, and the availability-vs-price caveat — is covered.

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 adds semantics the schema does not: how keywords are transformed (joined, paired, with brand prefixes/suffixes like get/try/hq), the relationship between keyword count and the 60-candidate screen, and the determinism of candidate ordering for cursor reuse.

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?

Opens with a specific verb+resource: build domain-name candidates from keywords and screen them against DNS/RDAP, returning available ones. It explicitly distinguishes itself from check_domain_availability and appraise_domain by name, so an agent can route correctly without opening schemas.

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 the triggering scenario (a name for a business or project) and names two alternatives with the condition that selects each: check_domain_availability for names already in mind, appraise_domain for valuation. No ambiguity about when to pick this tool.

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?