Skip to main content
Glama
dnsdoctor

DNS Doctor

by dnsdoctor
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

count_spf_lookups

Read-onlyIdempotent

Validate an SPF record and count DNS lookups against the 10-limit, identifying over-limit mechanisms and PermError causes so you can pinpoint what breaks email authentication.

Instructions

Use this when the user asks about SPF 'too many lookups', the 10-lookup limit, an SPF PermError, or whether an SPF record is valid. 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.2.1
    • addedInput schema / properties / domain / description
      Added value: +"Domain whose PUBLISHED SPF record should be resolved and counted recursively (nested includes cost lookups too). Pass exactly one of domain or record, never both."
    • addedInput schema / properties / record / description
      Added value: +"A 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."
  2. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

The annotations already mark this as read-only/idempotent, and the description adds meaningful behavioral detail on top: the exact fields returned, the recursive counting behavior, the diagnose-only policy, and the safety rationale for not suggesting removals. It also calls out edge cases like '+all' and multiple 'all' mechanisms, going well 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.

Conciseness5/5

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

The description is long but every sentence earns its place: usage triggers, return fields, parameter constraints, and a behavioral caveat. It is front-loaded with the most important 'when to use' information, then proceeds logically through outputs and input rules. No filler or repetition exists.

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 no output schema, the description fully enumerates the returned fields and their semantics (record_valid, findings, has_pass_all, multiple_all, terms, lookup count, over_limit/near_limit, offending_mechanisms). It also addresses input ambiguity, scope limits, and the non-fixing behavior, making the tool effectively self-contained for an agent to invoke correctly.

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

Parameters4/5

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

Schema coverage is 100% and both parameters are already described in the schema, so the baseline is 3. The description adds value by reinforcing the exclusive-or relationship ('Pass EXACTLY ONE'), clarifying the recursive vs own-terms distinction, and giving a concrete record example that maps to the 'record' parameter.

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 names a specific verb (validate, count) and resource (SPF record), and lists concrete triggers: 'too many lookups', '10-lookup limit', 'SPF PermError', or validity checks. It also declares itself 'the SPF validator — there is no separate one', which clearly distinguishes it from the sibling DNS/DMARC tools.

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?

It explicitly says when to use the tool with user-intent examples and states the only two input modes ('domain' vs 'record'), including the exact-one constraint. It also tells the agent what the tool will not do — return a fix record — and explains why, which is an important usage boundary.

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

Deploy Server

Other Tools