audit.domains - Domain Valuation

Search recorded domain sales

search_recorded_sales

Read-onlyIdempotent

Return up to 5 real recorded domain sales from a fixed public sample, filtered by keyword, TLD, price, year or venue, with counts and aggregates. Runs no appraisal. Use find_comparable_sales instead for the sales nearest one specific name, and appraise_domain for a value. Repeating or varying queries cannot surface more rows than the sample holds. Counts and aggregates describe the full corpus only when at least 25 records match; the population field says which. Aggregates are rounded to two significant figures. An empty result means absent from the sample, not from the corpus. Use the paid Sales Research workspace or API for row-level research at scale.

Input Schema

Name	Required	Description
`tld`	No	Restrict to one TLD without the dot, such as com or io.
`sort`	No	Sort key. Defaults to price, highest first.
`limit`	No	Rows to return, 1 to 5. Defaults to 5.
`query`	No	Substring matched against domain, category and venue.
`venue`	No	Substring matched against the sale venue.
`yearTo`	No	Latest sale year, inclusive.
`maxPrice`	No	Maximum recorded sale price in USD.
`minPrice`	No	Minimum recorded sale price in USD.
`yearFrom`	No	Earliest sale year, inclusive.

Output Schema

Name	Required	Description
`rows`	Yes
`stats`	No	Rounded to two significant figures. Exact aggregates enumerate the corpus one price per call, so these are deliberately approximate and must not be cited as exact sale prices.
`total`	Yes	Matching records. Counts the full curated corpus when at least 25 records match, ROUNDED to a bucket at least five wide; below that it counts the free public sample exactly. Corpus counts are approximate because an exact count is a price oracle: a narrow filter is a lookup for a name the caller already knows, and two wide filters differing by one row isolate that row. Read it with 'population' to know which set it counts.
`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.
`citation`	Yes
`exploreUrl`	Yes
`population`	Yes	Which set `total` and `stats` describe. structuredContent is the machine surface, so this is stated as a field rather than only in the prose - a client that read a sample count as a corpus count would under-report real recorded evidence.

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

Changed7 schema fields changedOct 6, 2026

changedInput schema / properties / limit / description

Previous value: -"Rows to return, 1 to 5 (default 5)."New value: +"Rows to return, 1 to 5. Defaults to 5."

changedInput schema / properties / maxPrice / description

Previous value: -"Maximum recorded price in USD."New value: +"Maximum recorded sale price in USD."

changedInput schema / properties / minPrice / description

Previous value: -"Minimum recorded price in USD."New value: +"Minimum recorded sale price in USD."

changedInput schema / properties / query / description

Previous value: -"Substring matched against domain, category and venue. Optional."New value: +"Substring matched against domain, category and venue."

changedInput schema / properties / sort / description

Previous value: -"Sort key; price descending is the default."New value: +"Sort key. Defaults to price, highest first."

changedInput schema / properties / tld / description

Previous value: -"Restrict to one TLD, for example com or io. Optional."New value: +"Restrict to one TLD without the dot, such as com or io."

changedInput schema / properties / venue / description

Previous value: -"Substring match on the venue."New value: +"Substring matched against the sale venue."

First observedSep 30, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only declare read-only/idempotent/closed-world; the description goes well beyond them by disclosing the fixed-sample ceiling of 5 rows, that aggregates describe the full corpus only at a 25-record threshold (governed by the population field), two-significant-figure rounding, and the meaning of an empty result. These are exactly the non-obvious traits an agent would otherwise misread.

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

Conciseness5/5

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

The core action and its sample limitation are front-loaded, followed by alternative routing and then the aggregation/empty-result caveats. Every sentence carries distinct, decision-relevant information rather than restating table stakes.

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 full annotations, 100% schema coverage and an output schema handling return values, the description still supplies the interpretive context an agent needs (sample vs corpus, threshold behavior, rounding, empty-result semantics). Nothing required to select or call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all nine parameters are already documented, and the description largely restates the filter set (keyword, TLD, price, year, venue). It adds only marginal guidance — the hard cap of five rows — beyond what the schema provides, so the baseline 3 applies.

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?

States a specific verb and resource ('Return ... recorded domain sales') plus the exact scope (up to 5 rows from a fixed public sample) and the filter dimensions. It names the siblings it is not — find_comparable_sales and appraise_domain — so an agent can distinguish it without opening other 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?

Explicitly routes to alternatives by task: find_comparable_sales for sales nearest one name, appraise_domain for a value, and the paid workspace/API for row-level research at scale. It also states the negative case ('Runs no appraisal') and warns that re-querying cannot exceed the sample.

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?