Model Context Protocol (MCP) server that empowers AI assistants (Claude, Cursor, Windsurf, autonomous agents) with automated domain appraisal, real-time authoritative WHOIS verification, and outbound sales evaluation.
This MCP server provides 3 primary tools to AI agents:
appraise_domain:
Algorithmic valuation engine analyzing TLD weights, SLD character length, hyphen/number penalties, and commercial liquidity.
Provides estimated wholesale and retail end-user price ranges.
check_whois:
Real-time socket connection to authoritative registries (e.g. Verisign Registry) to confirm exact registration status.
evaluate_outbound_potential:
Applies the disciplined 2-minute domain investment filter: evaluates Category vs Trademark risk, Flip vs Build model, and strategic pricing.
Related MCP server: Whodis MCP Server
Add this snippet to your claude_desktop_config.json:
{
"mcpServers": {
"domain-appraisal": {
"command": "npx",
"args": ["-y", "mcp-server-domain-appraisal"]
}
}
}Under MCP Settings, add a new stdio transport:
Command: npx -y mcp-server-domain-appraisal
npm install -g mcp-server-domain-appraisalOr run directly without installing:
npx mcp-server-domain-appraisalMIT License. Developed for the global domain investing and AI agent ecosystem.
Evaluates the market value, commercial viability, quality tier, and liquidity score of a domain name.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | The domain name to appraise (e.g. 'aiagent.com', 'portbonython.com') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden for behavioral disclosure. It implicitly suggests a read-only evaluation (by using 'Evaluates') and lists what it assesses, but it does not explicitly state that it is non-destructive, nor does it describe any side effects, external calls, or limitations. For a simple analysis tool this is adequate, though not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the core verb and immediately lists the specific evaluation dimensions. Every word carries meaning, and there is no redundant or irrelevant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one well-documented parameter and no output schema, the description is mostly complete: it tells the agent what the tool evaluates and implies what output to expect. It does not describe the return format or how scores are scaled, but given the low complexity and that the four evaluated aspects are listed, it is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers 100% of the single parameter, including its type and an example, so the baseline is 3. The tool description adds no additional parameter-level detail beyond referring to 'domain name,' which does not improve on the schema's clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Evaluates') and names the domain name as the resource, then enumerates four distinct outputs (market value, commercial viability, quality tier, liquidity score). This clearly differentiates it from sibling tools like check_whois (whois lookup) and evaluate_outbound_potential (outbound sales potential), so an agent can select it without confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when an appraisal of a domain's value and quality is needed, and the sibling names suggest alternative purposes. However, it gives no explicit 'use this when' or 'not when' guidance, nor does it mention any prerequisites or conditions for choosing this tool over the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Performs an authoritative real-time registry WHOIS lookup for availability and registration status.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | The domain name to check (e.g. 'mabuiag.com', 'gulfprovince.com') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It adds useful traits like 'authoritative', 'real-time', and 'registry' to signal a live network lookup, but it does not disclose output format, potential failure modes, or whether results may be redacted or limited by TLD. This is adequate but has clear gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. Every word adds value, and the key action and outcome appear first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a low-complexity tool with one fully documented parameter and no output schema. The description adequately states the purpose and result ('availability and registration status'), which is enough for an agent to invoke it correctly. Minor omissions like output formatting or error behavior prevent a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single 'domain' parameter with examples, so schema coverage is 100%. The description does not add any parameter-specific meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Performs'), a specific resource ('authoritative real-time registry WHOIS lookup'), and the outcome ('availability and registration status'). This clearly distinguishes it from sibling tools like appraise_domain and evaluate_outbound_potential, which are about valuation and outbound potential rather than raw lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for availability and registration status' gives a clear context for when this tool is appropriate. It does not explicitly name alternatives or exclusion conditions, but the intended use case is evident and distinguishable from the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Runs the disciplined 2-minute outbound filter: tests Category vs Brand risk, Flip vs Build model, and buyer persona strength.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | The domain name to evaluate for outbound sales | |
| vertical | Yes | The business industry or niche (e.g. 'Hydrogen Energy', 'Coastal Tourism', 'AI Software') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals the evaluation logic (three tests) but does not state whether the tool is read-only, what output or verdict it returns, or whether any external data is fetched. This is a meaningful gap for a tool with no annotation safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a single, front-loaded sentence with no filler; every phrase identifies a distinct evaluation criterion. The only cost is unexplained internal terminology, but that is a clarity issue, not a conciseness issue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity 2-parameter tool the description is usable, but with no output schema and no annotations it should clarify what the filter produces (e.g., a recommendation, score, or pass/fail). Without that, the agent knows the tool's inputs and intent but not the shape of its result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the description adds no parameter-level detail beyond the schema. The description lists high-level criteria but doesn't explain how domain/vertical map to those tests, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States it 'runs the disciplined 2-minute outbound filter' and names three tests, so an agent knows it evaluates outbound sales potential rather than doing generic appraisal or WHOIS lookup. However, 'Category vs Brand risk' and 'Flip vs Build model' are unexplained jargon, and it never explicitly contrasts itself with siblings, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'outbound' and the buyer-persona test imply the tool is for outbound prospecting, but there is no explicit when-to-use or when-not-to-use guidance, nor any mention of appraise_domain or check_whois as alternatives. An agent must infer the decision context from the name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0appraise_domaincheck_whoisevaluate_outbound_potentialScored across 3 tools
Each tool targets a distinct aspect: appraise_domain for valuation, check_whois for registration status, and evaluate_outbound_potential for resale viability. No overlap or ambiguity.
All tools follow a consistent verb_noun pattern (appraise_domain, check_whois, evaluate_outbound_potential) with lowercase snake_case, making them predictable.
Three tools are tightly scoped for a domain appraisal server, covering core functions without bloat. Each tool earns its place.
The surface covers appraisal, WHOIS lookup, and outbound potential. Minor gaps exist like domain search or batch operations, but the core lifecycle is complete for the stated purpose.
Custom domains for SaaS and AI agents: search, register, connect DNS, and issue HTTPS over MCP.
MCP server for OnceAsk, the AI-native current-address layer for people and agents.
Agent-native MCP server over 49M+ US public and government records, privacy-first, always current.
Domain intel for AI agents: RDAP registration, DNS, email deliverability, tech stack.
