DNS Doctor
Official# @dnsdoctor/mcp: DNS Doctor as a local stdio MCP server
A thin MCP server that runs on your machine and calls the public
[DNS Doctor](https://dnsdoctor.dev) REST API. It exposes the same 29 tools as the
hosted server at `https://dnsdoctor.dev/mcp`: scan a domain's email
authentication (SPF, DMARC, DKIM), MX, DNS health, blacklists and domain/SSL
expiry, check propagation, and get the exact fix record to publish.
It holds no diagnosis logic of its own and relays every record string verbatim.
Every fix record comes from DNS Doctor's deterministic engine, never from a model
guess.
Most clients should use the hosted server instead (no install, no keys):
```json
{ "mcpServers": { "dns-doctor": { "type": "http", "url": "https://dnsdoctor.dev/mcp" } } }
```
For Claude Code, the [DNS Doctor plugin](https://github.com/dnsdoctor/claude-plugin)
wires the hosted server and adds the skills.
## Run it
```json
{
"mcpServers": {
"dns-doctor": {
"command": "npx",
"args": ["-y", "@dnsdoctor/mcp@1.21.0"],
"env": { "DNSDOCTOR_API_TOKEN": "dnsd_YOUR_TOKEN" }
}
}
}
```
Node 20 or newer. Pin the version as shown, so the code you run is the code you
reviewed.
- `DNSDOCTOR_API_TOKEN` is optional. Anonymous access covers scanning and fixes;
the account tools (monitored domains, alerts, readiness, lookalike watches,
email tests) need a token. Create one at dnsdoctor.dev under
**Settings > API tokens**. The client sends it only to dnsdoctor.dev, as a
bearer token. Never commit it.
- `DNSDOCTOR_API_BASE` overrides the origin. It must serve the `/api/...` paths,
i.e. the public site rather than a bare backend port.
## Build from source
```bash
npm ci
npm test
npm run build # -> dist/index.js, the package's bin entrypoint
```
`tools.json` and `instructions.txt` are generated from the hosted server and
pinned by a test on the server side: never hand-edit them, and never add a tool
description to `src/`. Both ship in the npm tarball; without them the client has
no tools and none of its safety guidance.
## License
Apache-2.0
TDQS
Scored across 29 tools
Most tools are distinct, but the set contains several overlapping clusters: four DMARC record tools (generate_dmarc_record, build_dmarc_upgrade, validate_dmarc_record, get_readiness), three near-real-time record reads (check_record, check_propagation, watch_record_change), and a lookalike pair (check_lookalikes vs get_lookalikes). The descriptions do explicit cross-referencing ('use count_spf_lookups instead', 'use check_record instead'), which rescues much of it, but selection still requires reading long prose rather than picking from obvious names.
Every name is snake_case with a leading verb (check_, get_, list_, start_, add_, build_, generate_, validate_, parse_, audit_, count_, scan_, watch_, lookup_), so the action and object are predictable throughout. No camelCase or bare-noun outliers beyond lookup_registration, which still reads as verb+noun.
29 tools is above the comfortable band and pushes into heavy territory, especially with four DMARC-record builders and three record-propagation readers that could partly be consolidated. The scope is genuinely broad (DNS diagnostics, email authentication, BIMI, monitoring, lookalikes, RDAP), so most tools do earn a place, but the surface feels larger than necessary.
Coverage is strong across the domain: record lookups, propagation, SPF/DKIM/DMARC validation and generation, BIMI, reverse DNS, RDAP, lookalikes, email authentication testing, and the monitoring account lifecycle. Minor gaps remain — no way to remove/unmonitor a domain, no NS/CAA/SOA kinds in check_record, and alert acknowledgement is deliberately dashboard-only — but agents can work around these.