Pay-per-call domain and email security check: SPF, DKIM, DMARC, TLS, DNSSEC, BIMI, with exact fixes.
Scored across 2 tools
domain_age is a focused, cheaper tool for registration/age risk, while domain_check is a comprehensive email/domain security scan. Their use cases are explicitly stated and clearly distinct, even though domain_check also reports domain age as one sub-check, which is a superset not an ambiguity.
Both tools use snake_case with the same domain_ prefix and a clear noun suffix (age, check). There is no mixing of conventions; the naming pattern is fully consistent.
Two tools is slightly below the typical 3-15 range, but each serves a distinct, non-redundant purpose: one focused registration check and one broad security audit. The set is well-scoped and not bloated, though a third tool for a specific gap could be useful.
The surface covers domain registration/age and a thorough email security posture including SPF, DKIM, DMARC, MX, TLS, DNSSEC, CAA, BIMI, and blocklist checks. Minor gaps exist, such as dedicated email address verification or broader DNS enumeration, but core domain and email security workflows are fully covered.
PAID ($0.005). Not for registries without RDAP, e.g. .za/.co.za, .me, .de, .io, .eu: refused free (422). Use when you need to know which registrar holds a domain, how old it is, and whether it is a risky newly-registered domain. $0.005. From the registry's RDAP: registrar name and IANA ID (no registrant or contact data), created, expires, last changed, status flags, DNSSEC delegation, nameservers; fail under 30 days old or expired, warn under 180 days, expiring within 30 days or on hold. A registry without RDAP is refused free. MCP: pass api_key (an Afriref key, card credit at https://afriref.dev/pricing); per-call x402/MPP payment is HTTP only, so without a key the result is an api_key_required error naming the HTTP endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain or hostname, e.g. example.com (no URL, no IP) | |
| api_key | No | API key (bypasses x402; metered for invoicing) |
| Name | Required | Description |
|---|---|---|
| fix | No | |
| error | No | Present on a free refusal or error; no charge |
| grade | No | |
| notes | No | |
| domain | No | |
| finding | No | |
| diagnosis | No | |
| no_charge | No | |
| price_usd | No | |
| checked_at | No | |
| how_to_pay | No | |
| explanation | No | |
| registration | No | |
| http_endpoint | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/openWorld, and the description adds substantial context on top: paid pricing, free refusal for non-RDAP registries, fail/warn thresholds (under 30 days, under 180 days, expiring within 30 days, on hold), and an explicit auth failure mode (api_key_required when no key is supplied over MCP). This is rich, non-obvious behavioral detail beyond the annotations.
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 repeats itself: the $0.005 price appears twice and the non-RDAP free-refusal (422) is stated twice. The lead opens with pricing and exclusions before stating the core purpose, so it is not fully front-loaded. Still, each block is on-topic and no filler content is present.
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 paid lookup tool with an output schema already covering return values, the description covers everything an agent needs: purpose, price, auth path (api_key vs HTTP x402), failure modes, TLD exclusions, and the fail/warn decision thresholds. There is no material gap affecting 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?
Schema description coverage is 100%, so the baseline is 3. The description adds real meaning for api_key: that it is an Afriref key with card credit, that per-call x402/MPP payment is HTTP-only, and that omitting it over MCP yields an api_key_required error naming the HTTP endpoint. That materially explains the second parameter beyond the schema's one-line note.
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 states precisely what the tool returns: registrar name and IANA ID, created/expires/changed dates, status flags, DNSSEC, and nameservers, all from the registry's RDAP. It also frames the use case (registrar ownership, domain age, risky newly-registered domains), which differentiates it in practice from a generic check. It never names the sibling domain_check, so sibling differentiation is implicit rather than explicit.
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?
It gives clear when-to-use ("when you need to know which registrar holds a domain, how old it is, and whether it is a risky newly-registered domain") and a concrete when-not (registries without RDAP, listing .za/.co.za, .me, .de, .io, .eu, which are refused with 422). It stops short of naming the alternative tool to use for those cases, so the routing is incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PAID ($0.01). Use when mail lands in spam, before an email campaign, for vendor due diligence or to confirm a Microsoft 365 tenant: graded SPF, DKIM, DMARC, MX, MTA-STS, DNSSEC, CAA, TLS and domain age, plus BIMI and blocklist info, each with the exact fix record. Non-intrusive. $0.01 per domain. Returns a 0-100 score and, per check (spf, dkim, dmarc, mx, tls = website certificate, m365, registration, mta_sts, tls_rpt, dnssec, caa, bimi, dnsbl = UCEPROTECT blocklist), a pass/warn/fail/info grade, the finding and the exact record or step that fixes it. Info checks do not move the score. Invalid, nonexistent or private-only domains are refused free. MCP: pass api_key (an Afriref key, card credit at https://afriref.dev/pricing); per-call x402/MPP payment is HTTP only, so without a key the result is an api_key_required error naming the HTTP endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain or hostname, e.g. example.com (no URL, no IP) | |
| api_key | No | API key (bypasses x402; metered for invoicing) |
| Name | Required | Description |
|---|---|---|
| fix | No | |
| error | No | Present on a free refusal or error; no charge |
| notes | No | |
| score | No | |
| checks | No | |
| domain | No | |
| letter | No | |
| summary | No | |
| diagnosis | No | |
| no_charge | No | |
| price_usd | No | |
| checked_at | No | |
| how_to_pay | No | |
| explanation | No | |
| http_endpoint | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/openWorld, and the description still adds substantial behavioral context: it is PAID at $0.01 per domain, non-intrusive, refuses invalid/nonexistent/private-only domains for free, and the MCP path requires an api_key (x402 payment is HTTP-only, otherwise an api_key_required error names the HTTP endpoint). That is exactly the auth/cost/error disclosure structured fields cannot carry.
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?
Dense but front-loaded — cost, then use cases, then the check inventory, then the return shape, then payment mechanics. Minor redundancy: the $0.01 price is stated twice ('PAID ($0.01)' and '$0.01 per domain'), and the long parenthetical listing every check code is heavy.
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 paid external-scan tool this is complete: cost, auth path, refusal behavior, return shape (0-100 score plus per-check pass/warn/fail/info grades with fix records) and the note that info checks don't move the score. An output schema exists, yet the description still frames the result usefully.
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 coverage is 100%, so baseline is 3, but the description adds real meaning: api_key is an Afriref key purchasable at https://afriref.dev/pricing, it bypasses x402, is metered for invoicing, and its absence produces a specific api_key_required error. domain format detail (no URL, no IP) is left to the schema.
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+resource — a domain/email security check that grades SPF, DKIM, DMARC, MX, MTA-STS, DNSSEC, CAA, TLS, domain age, BIMI and blocklists. It is unmistakably distinct from the sibling domain_age, which covers only one of the many signals enumerated here.
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?
Explicit trigger scenarios are given: 'when mail lands in spam, before an email campaign, for vendor due diligence or to confirm a Microsoft 365 tenant.' That is strong when-to-use guidance, but it offers no when-not conditions and never references the domain_age sibling as an alternative.
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.
domain_age16 fields changedOutput schema / descriptionPrevious value: -"Finished-job dossier: verdict or summary, line items, evidence with official sources. On 402 the x402 PaymentRequired object (isError)"New value: +"Registration from the registry's RDAP: grade, finding, fix and registrar, created, expires, status and nameservers. A refusal (invalid domain, registry without RDAP, api_key_required) is isError with error and explanation; nothing is charged"Output schema / properties / bind_seriesRemoved value: -{}Output schema / properties / checked_atAdded value: +{
+ "type": "string"
+}Output schema / properties / diagnosisAdded value: +{}Output schema / properties / disclaimerRemoved value: -{}Output schema / properties / domainAdded value: +{
+ "type": "string"
+}Output schema / properties / evidenceRemoved value: -{
- "items": {},
- "type": "array"
-}Output schema / properties / findingAdded value: +{
+ "type": "string"
+}Output schema / properties / fixAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / gradeAdded value: +{
+ "type": "string"
+}Output schema / properties / jobRemoved value: -{
- "type": "string"
-}Output schema / properties / notesAdded value: +{
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / payment_requiredRemoved value: -{
- "description": "true when the call needs payment; how_to_pay explains x402 or card",
- "type": "boolean"
-}Output schema / properties / registrationAdded value: +{}Output schema / properties / statusRemoved value: -{
- "type": "string"
-}Output schema / properties / x_next_bindRemoved value: -{}domain_check17 fields changedOutput schema / descriptionPrevious value: -"Finished-job dossier: verdict or summary, line items, evidence with official sources. On 402 the x402 PaymentRequired object (isError)"New value: +"Domain and email security report: 0-100 score, letter, summary and one entry per check with grade, finding and fix. A refusal (invalid or unknown domain, broken DNS, api_key_required) is isError with error and explanation; nothing is charged"Output schema / properties / bind_seriesRemoved value: -{}Output schema / properties / checked_atAdded value: +{
+ "type": "string"
+}Output schema / properties / checksAdded value: +{
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "check": {
+ "type": "string"
+ },
+ "finding": {
+ "type": "string"
+ },
+ "fix": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "grade": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / diagnosisAdded value: +{}Output schema / properties / disclaimerRemoved value: -{}Output schema / properties / domainAdded value: +{
+ "type": "string"
+}Output schema / properties / evidenceRemoved value: -{
- "items": {},
- "type": "array"
-}Output schema / properties / fixAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / jobRemoved value: -{
- "type": "string"
-}Output schema / properties / letterAdded value: +{
+ "type": "string"
+}Output schema / properties / notesAdded value: +{
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / payment_requiredRemoved value: -{
- "description": "true when the call needs payment; how_to_pay explains x402 or card",
- "type": "boolean"
-}Output schema / properties / scoreAdded value: +{
+ "type": "number"
+}Output schema / properties / statusRemoved value: -{
- "type": "string"
-}Output schema / properties / summaryAdded value: +{
+ "type": "string"
+}Output schema / properties / x_next_bindRemoved value: -{}domain_agedomain_checkOne-call domain audit: MX receiving, SPF/DMARC/DKIM spoofing protection, disposable-address risk.
Check emails before you send, and get a $1 SPF/DKIM/DMARC fix plan for your domain. Pay per call.
Domain checks: SPF, DKIM, DMARC, BIMI, MTA-STS, SSL/TLS and HTTP security headers.
Check SPF/DKIM/DMARC of a domain, get a non-binding Fix & Verify quote, re-verify after the DNS fix.
Add one secure layer between your agents and this server.