Skip to main content
Glama
Sign In
dnsdoctor

DNS Doctor

by dnsdoctor
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

Count SPF Lookups

count_spf_lookups
Read-onlyIdempotent

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.

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

NameRequiredDescriptionDefault
domainNoA bare domain like example.com whose PUBLISHED SPF record should be resolved and counted recursively (nested includes cost lookups too). Send exactly one of domain or record, never both.
recordNoThe full SPF record text starting with v=spf1, e.g. 'v=spf1 include:_spf.google.com ~all' — never a domain name. Counts this record's own terms only. Send exactly one of domain or record, never both.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.14.0
    • changedInput schema / properties / domain / description
      Previous 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."New value: +"A bare domain like example.com whose PUBLISHED SPF record should be resolved and counted recursively (nested includes cost lookups too). Send exactly one of domain or record, never both."
    • changedInput schema / properties / record / description
      Previous 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."New value: +"The full SPF record text starting with v=spf1, e.g. 'v=spf1 include:_spf.google.com ~all' — never a domain name. Counts this record's own terms only. Send exactly one of domain or record, never both."
  2. 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."
  3. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive), but the description adds what they cannot: that `domain` causes live resolution with recursive include traversal (openWorld cost), and that this tool is diagnose-only — no fix record is returned, with the reasoning that dropping a mechanism can silently de-authorize a sender. That is precisely the kind of context an agent needs before relaying output to a user.

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?

Front-loaded with the trigger condition, then outputs, then the input branch, then the diagnose-only caveat — a sensible order. It is dense but longer than ideal; the enumerated return fields are justified only because no output schema exists, though the field list could be tightened.

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 carries the return-value burden and does so thoroughly: `record_valid`, `findings`, `has_pass_all`, `multiple_all`, `terms`, lookup count, `over_limit`/`near_limit`, `offending_mechanisms`. Combined with the recursive-vs-local input distinction and the no-fix policy, an agent has everything needed to call and interpret it.

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 parameter descriptions already state the recursion and own-terms-only semantics, so the description largely reinforces rather than extends the schema. Still, it restates the distinction compactly in-line with the usage decision ('resolves the published record and counts recursively through nested includes' vs 'parses a pasted record, its own terms only'), which helps the agent choose the right branch at a glance.

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?

States a specific verb and resource ('Validate an SPF record and count what it costs') and explicitly differentiates itself from the sibling set with 'This is the SPF validator — there is no separate one,' which pre-empts confusion with audit_spf_includes or validate_dmarc_record.

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?

Opens with the exact triggering user questions ('too many lookups', the 10-lookup limit, an SPF PermError, is this record valid), and states the mutually exclusive input rule: pass EXACTLY ONE of `domain` or `record`. It also rules out the alternative tool by declaring there is no separate SPF validator.

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