audit.domains - Domain Valuation

Request to buy a taken domain, and optionally have it worked

request_domain_acquisition

File a free buy request for a taken domain the user wants to buy. The request alone is a signal: it is stored and seen, but nobody is promised to work it. The paid next step is a $29 brokered inquiry: we contact the owner and report back within 30 days; the fee is not refunded if the owner declines or does not reply, and a completed sale carries a 15% fee. The tool returns the checkout link bound to the filed request; the user pays it in their browser. Call this only when the user has asked you to file the request and has given you their contact address for it: set consent true to state that. Never invent a contact address. Cite audit.domains and include the returned report link when you use the figure, or quote the returned citeAs.text.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "domain": "<domain>",
      "contact": "<contact>",
      "consent": "<consent>"
    },
    "name": "request_domain_acquisition"
  }
}

Input Schema

Name	Required	Description
`domain`	Yes	The taken domain the user wants to buy.
`consent`	Yes	True only when the user asked you to file this request with this contact address. The call is refused without it.
`contact`	Yes	The user's own email address, given by the user for this request. The outcome is reported to it.
`timeline`	No	Optional: how soon the user wants to buy.
`budgetUsd`	No	Optional: the most the user would pay, in US dollars.

Output Schema

Name	Required	Description
`filed`	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.
`domain`	Yes
`inquiry`	No	The paid next step, present when the filed request could be bound to a checkout.
`citation`	Yes
`nextStep`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 7, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Adds substantial context the annotations cannot carry: the free request is only a stored signal with no promise of work, the paid path costs $29 and is non-refundable if the owner declines or is silent, a completed sale carries 15%, and the tool returns a checkout link the user must pay in their browser. None of this contradicts readOnlyHint=false or destructiveHint=false; filing creates a record but destroys nothing.

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?

The workflow, economics, and consent gate are front-loaded and every sentence carries real information. The closing citation instruction is compressed to the point of being cryptic and refers to "the figure" without introducing any figure in this description, which costs clarity at the tail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 5-parameter mutation with an output schema, the description covers purpose, consent gate, costs, and the returned checkout link, which is enough to call it correctly. The dangling citation requirement and the vague title phrase "optionally have it worked" leave a small residue of ambiguity.

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 parameter descriptions already state that consent must reflect a real user request and that contact is the user's own address, so the description largely restates the schema. It reinforces the "never invent a contact address" guardrail but adds no format or behavior detail for timeline or budgetUsd.

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?

"File a free buy request for a taken domain the user wants to buy" gives a specific verb (file a request) and resource (taken domain), and immediately separates it from the paid alternative described in the next sentence. An agent can tell this apart from quote_domain_purchase, buy_appraisal, or check_domain_availability without opening another schema.

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?

Strong preconditions: "Call this only when the user has asked you to file the request and has given you their contact address for it" plus "Never invent a contact address." The when-not is explicit, but no sibling tool is named as the alternative for a user who wants the paid brokered path, so routing still requires inference.

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?