Build a Practical Domain Research Workflow with REST APIs and MCP

Esteve Castells, maker of DomScan, demonstrates a practical domain research workflow using REST APIs and the Model Context Protocol (MCP). The workflow separates availability, WHOIS, DNS security, and valuation checks, preserving partial failures and avoiding false certainty. Castells emphasizes treating every result as timestamped evidence and not converting missing checks into failures.

Disclosure: I’m Esteve Castells, the maker of DomScan. This tutorial uses DomScan because I can explain its behavior and limitations directly. A domain research task often begins with one simple question: is this name available? That answer usually creates more questions. Who registered it? Which nameservers are active? Are email security records configured? Does the domain have certificate or reputation signals worth reviewing? If the domain is a candidate for a product or brand, what other evidence should inform the decision? This tutorial builds a small workflow that keeps those checks separate, preserves partial failures, and avoids turning an unknown result into false certainty. Create a free DomScan account https://domscan.net/login?mode=signup and generate an API key from the dashboard. New accounts receive 10,000 credits every month with no card required. Each operation has its own published credit cost and limits. Store the key in an environment variable: export DOMSCAN API KEY="your api key" DomScan accepts API keys through the X-API-Key header. The availability endpoint accepts a name and one or more TLDs: curl \ -H "X-API-Key: $DOMSCAN API KEY" \ "https://domscan.net/v1/status?name=launchcheck&tlds=com,io,dev" This is more useful than reducing the result to a single boolean. The documented response can include the checked domain, availability state, evidence source, confidence, timestamps, latency, and error information. Your application should preserve three distinct outcomes: An unknown result is not the same as an available domain. Availability evidence also does not guarantee that a registrar will allow registration. Reserved names, eligibility rules, premium status, and policy restrictions can still matter. Once you have a complete domain, request its WHOIS data: curl \ -H "X-API-Key: $DOMSCAN API KEY" \ "https://domscan.net/v1/whois?domain=example.com" WHOIS and RDAP data can provide registration context such as registrar information, dates, nameservers, statuses, and available contact or privacy signals. Treat every field as evidence with a timestamp. Registration records can be redacted, incomplete, or temporarily unavailable. Missing contact data does not prove that no contact exists, and a date returned by one check should not be stored forever without its check time. If you need structured registration data directly, DomScan also documents an RDAP product in the API documentation https://domscan.net/docs . A domain can be registered and reachable while still having weak or incomplete DNS controls. The DNS security endpoint checks documented DNS and email-security signals: curl \ -H "X-API-Key: $DOMSCAN API KEY" \ "https://domscan.net/v1/dns/security?domain=example.com" This can help you review records and controls such as DNSSEC, SPF, DKIM, DMARC, CAA, MTA-STS, and TLS reporting where they are observable. The important implementation detail is not to convert every missing or blocked check into “failed.” A record may be absent, a selector may not have been requested, or a lookup may be inconclusive. Keep the endpoint’s status, evidence, and caveats in your own data model. For a candidate domain, you can request an algorithmic valuation estimate: curl \ -H "X-API-Key: $DOMSCAN API KEY" \ "https://domscan.net/v1/value?domain=example.com" Use valuation as one input, not as a guaranteed sale price or prediction of buyer demand. A useful product can show the estimate beside availability, registration, and naming evidence without pretending they measure the same thing. Here is a small Node.js example that runs several checks and preserves the result of each request: js const baseUrl = "https://domscan.net"; const apiKey = process.env.DOMSCAN API KEY; if apiKey { throw new Error "Set DOMSCAN API KEY before running this script." ; } async function query path { const response = await fetch new URL path, baseUrl , { headers: { "X-API-Key": apiKey, }, } ; const body = await response.json .catch = null ; return { ok: response.ok, status: response.status, body, }; } const domain = "example.com"; const checks = { registration: /v1/whois?domain=${encodeURIComponent domain } , dnsSecurity: /v1/dns/security?domain=${encodeURIComponent domain } , valuation: /v1/value?domain=${encodeURIComponent domain } , }; const entries = await Promise.all Object.entries checks .map async name, path = { try { return name, await query path ; } catch error { return name, { ok: false, status: null, body: null, error: error instanceof Error ? error.message : String error , }, ; } } ; const report = { domain, checkedAt: new Date .toISOString , checks: Object.fromEntries entries , }; console.log JSON.stringify report, null, 2 ; This structure gives each check its own HTTP status and response body. One temporary failure does not erase the successful checks, and your application can decide whether a missing result should block the whole workflow. Before using this in production, add endpoint-specific validation and read the documented response fields rather than assuming every product has the same shape. REST is a good fit when your application already knows which checks to run. MCP is useful when a person or agent is still exploring the question. Compatible clients can connect to the hosted endpoint: https://domscan.net/mcp Modern supported clients can complete authorization when prompted. The current MCP setup guide https://domscan.net/mcp-domain-checker covers common client configurations. A useful prompt should define both the research goal and the evidence rules: Research example.com for a product review. Check registration, DNS, email-security, certificate, and reputation signals where supported. Keep observed, absent, unknown, not requested, and unsupported outcomes distinct. Include timestamps and caveats when the tools return them. Do not treat an unknown result as safe or absent. This is more dependable than asking an agent whether a domain is simply “good.” It gives the agent a bounded task and tells it how uncertainty must be represented. Before shipping a domain research feature: A good research workflow does not need to claim certainty. It needs to show what was checked, what was observed, and what remains unresolved. Canonical CTA: Create a free DomScan account and make your first request https://domscan.net/login?mode=signup You can review the full DomScan API documentation https://domscan.net/docs before integrating.