Skip to main content
Glama

dns-doctor

by dev.dnsdoctor

count_spf_lookups

Read-onlyIdempotent

Validate an SPF record and count what it costs. Returns record_valid (the record parses as RFC 7208 SPF), findings (per-term diagnostics), has_pass_all (a +all that authorizes the whole internet to send as this domain), multiple_all (more than one all, which makes everything after the first unreachable), the parsed terms, and the lookup count against the limit of 10 with over_limit/near_limit and the offending_mechanisms that push it over. Pass EXACTLY ONE of domain (resolves the published record and counts recursively through nested includes) or record (parses a pasted record, its own terms only). This is the SPF validator — there is no separate one. Diagnose-only: no SPF fix record is ever returned, because removing a mechanism can silently de-authorize a real sender — relay the findings and let the domain's owner decide what to drop.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
domainNoDomain whose PUBLISHED SPF record should be resolved and counted recursively (nested includes cost lookups too). Pass exactly one of domain or record, never both.
recordNoA pasted SPF record to parse instead of resolving one, e.g. 'v=spf1 include:_spf.google.com ~all'. Counts this record's own terms only. Pass exactly one of domain or record, never both.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

TDQS

A5/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description discloses critical behavioral traits: the diagnose-only nature with the explicit promise 'no SPF fix record is ever returned,' the rationale about silently de-authorizing senders, and the nested include recursion behavior. This adds significant context the annotations alone don't provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but well-structured, front-loading the main purpose and then flowing through return values, parameter usage, and an important caveat. Every sentence adds functional value, with no fluff or repetition. The length is justified by the tool's complexity.

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?

With a rich description, full schema parameter descriptions, and an output schema present, the tool is fully specified. The description covers the 10-lookup limit, over_limit/near_limit indicators, offending_mechanisms, and the reason for not fixing records — leaving no practical questions about what the tool does and how to invoke it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Even though schema coverage is 100%, the description enriches both parameters by clarifying the exact-one constraint and behavioral difference: 'domain resolves the published record and counts recursively through nested includes' vs. 'record parses a pasted record, its own terms only.' This goes well beyond the schema's field descriptions.

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 specific verb and resource: 'Validate an SPF record and count what it costs.' It clearly distinguishes this tool from siblings by stating 'This is the SPF validator — there is no separate one.' It also enumerates key outputs (record_valid, findings, has_pass_all, etc.), making the purpose unmistakable.

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 provides explicit when-to-use guidance including the two mutually exclusive modes: 'Pass EXACTLY ONE of domain or record' with detailed explanations of each. It also states when NOT to use it for fixes: 'Diagnose-only: no SPF fix record is ever returned' and explains why, positioning it against potential alternatives.

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