Skip to main content
Glama

dns-doctor

by dev.dnsdoctor

audit_spf_includes

Read-onlyIdempotent

Audit a domain's SPF supply chain: walks every include and redirect it delegates to, and reports who can transitively send as it. Returns the resolved tree, per-node lookup attribution, the total authorized IPv4 address count, and typed findings — include_broken (a target that no longer publishes SPF, a PermError today), include_registrable (a delegated-to domain that does not exist, so a stranger who registers it becomes an authorized sender), include_expiring (registration lapsing within 30 days), pass_all_nested (a +all deep in the chain) and spf_record_unusable (the audited domain's OWN record is missing or does not parse, so there is no chain to walk). A domain we could not verify is reported as unverified and NEVER as available — never tell anyone a name is free on this tool's say-so unless the finding is include_registrable AND carries registry_confirmed: true. A registry_confirmed: false finding rests on DNS alone, which cannot tell an unsold name from one in redemption or on clientHold: report the mechanism as broken and the takeover risk as possible, but never as an available domain. Findings are risk analysis, not instructions: no SPF fix record exists here or anywhere else in DNS Doctor, because dropping a mechanism can silently de-authorize a real sender — relay the findings and let the domain's owner decide. Use count_spf_lookups instead when the question is only the 10-lookup limit.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
domainYesThe domain to check, e.g. example.com. Bare registrable names and subdomains both work; scheme, path or port do not belong here. Unicode names are accepted and normalized to punycode.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

TDQS

A4.6/5.0
Behavior5/5

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

The annotations already indicate a safe, read-only tool, but the description adds critical behavioral nuances: unverified domains are never reported as available, registry_confirmed must be true for include_registrable to claim availability, and it warns about the dangers of SPF changes. This goes far beyond the structured annotations.

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 description is lengthy but each sentence adds critical information for a complex audit tool. It is front-loaded with purpose and flows logically into return values, findings, and caveats. However, it is one dense paragraph and could benefit from structural breaks, so a 4.

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

Completeness5/5

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

Given the complexity of SPF supply chain auditing, the description covers the return shape, all finding types, edge cases (unverified, registry_confirmed), warning about availability, and the alternative tool. The presence of an output schema reduces the burden, but the description still explains the key outcomes thoroughly, earning a 5.

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?

The input schema already fully describes the domain parameter, including format, subdomains, unicode normalization, and exclusions. The description doesn't add new parameter semantics; it only references domain in the context of verification failure. With 100% schema coverage, the baseline is 3.

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?

The description opens with a clear verb and resource: 'Audit a domain's SPF supply chain' and specifies what it does: 'walks every include and redirect it delegates to, and reports who can transitively send as it.' This distinguishes it from siblings like count_spf_lookups and scan_domain by focusing on transitive delegation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly names an alternative tool: 'Use count_spf_lookups instead when the question is only the 10-lookup limit.' It also strongly advises on how to interpret findings: 'Findings are risk analysis, not instructions' and 'relay the findings and let the domain's owner decide.' This is clear guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All dns-doctor toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool targets a distinct DNS or email authentication task. Despite multiple DMARC-related tools, their purposes are clearly differentiated: build_dmarc_upgrade upgrades policies, generate_dmarc_record creates new ones, validate_dmarc_record validates pasted records, and scan_domain vs get_report differentiate fresh vs cached scans.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., build_dmarc_upgrade, check_record, scan_domain). No mixing of naming conventions, making the set predictable and easy to navigate.

Tool Count5/5

With 11 tools, the server is well-scoped for a DNS/email authentication diagnostics tool. The number covers essential operations without being overwhelming or sparse.

Completeness4/5

The tool set covers core workflows: DMARC management (generate, validate, upgrade, parse reports), DNS checks (propagation, reverse DNS, SPF lookups), and DKIM selector checks. Minor gaps exist, such as the absence of SPF validation or DKIM signature verification, but the main diagnostic and monitoring use cases are supported.

Resources