audit.domains - Domain Valuation

Run a domain-name bracket

run_bracket

Read-onlyIdempotent

Run a single-elimination bracket of 2 to 8 domain names and return the seeded field, every match and one champion. Use compare_domains instead when you need estimated values or want to know which orderings are not separable; this result is ordinal, tiers and winners only. Value decides each match with fixed tie-breaks, so the same field always crowns the same champion. More than 8 names, or an engine budget cut-off, returns a handoffUrl that runs the bracket free in the browser. Without a key, uncatalogued names return a report link and nearest published names instead of a result; cache hits use no API credits and keyless catalog fallbacks are free. A default-profile cache miss with an authorized write-scope paid key (HTTP header Authorization: Bearer ad_live_...) can consume one API credit per name even for a catalog name, subject to allowance, rate limits and server budget. Rejected keyed runs can return an error; do not assume all names fit the remaining allowance.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`domains`	Yes	Names to enter, such as example.com. 2 to 8 run here; 9 to 16 return handoffUrl only.

Output Schema

TableJSON Schema

Name	Required	Description
`next`	No	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).
`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.
`rounds`	Yes	Rounds in order. Each match names both sides, the winner, and why it advanced (value, factors, tiebreak, or bye).
`seeded`	Yes	Entrants in seed order, highest appraised value first.
`champion`	Yes	Null only when the field was handed off without running here.
`citation`	Yes
`handoffUrl`	No	Present when this request could not run every name here (over the tool cap, or cut off by the per-request engine budget): a link to the free page that runs the same deterministic computation for all of them in the reader's browser. Give it to the user rather than retrying.
`notAppraised`	No	Names that did not run here (over the tool cap, or cut off by the request budget). They never entered the bracket - they were not eliminated. See handoffUrl.

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

Changed1 schema field changedOct 8, 2026

addedOutput schema / 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"
+  ]
+}

AddedOct 7, 2026
RemovedOct 6, 2026
First observedSep 30, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only declare readOnly/idempotent/openWorld; the description adds far more: determinism ('the same field always crowns the same champion'), credit consumption ('one API credit per name'), auth requirements (Authorization: Bearer ad_live_..., write-scope key), cache-hit economics, keyless fallback behavior, and honest failure modes ('Rejected keyed runs can return an error'). This is exactly the beyond-annotation context the bar asks for.

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 alternative, then behavior — a sound order, and nearly every sentence carries operational signal. It is dense and billing-heavy toward the end, where the credit/allowance/rate-limit caveats stack up and could be tightened, but nothing is truly wasted.

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, yet the description still names the returns (seeded field, matches, champion) and covers auth, cost, budget cutoffs, cache behavior, and error cases. For a compute tool with a monetization surface, an agent has everything needed to call it and anticipate the result.

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 coverage is 100% and the single parameter's tiered behavior (2-8 vs 9-16) is already documented in the schema description. The prose repeats rather than extends that, so baseline 3 is correct — no added syntax, format, or edge-case detail beyond the structured field.

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+resource+output: 'Run a single-elimination bracket of 2 to 8 domain names and return the seeded field, every match and one champion.' It also names the sibling it is not (compare_domains) and the exact distinction (ordinal tiers vs estimated values), so an agent can separate it from the ~25 other tools here without opening a schema.

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?

Explicit routing: 'Use compare_domains instead when you need estimated values or want to know which orderings are not separable.' It also gives boundary conditions (2-8 run here, over 8 or budget cutoff returns handoffUrl) and the keyed vs keyless paths, so the when/when-not decision is fully specified.

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?