Skip to main content
Glama
Sign In

dns-doctor

by dev.dnsdoctor
OverviewDiscussionsAdmin

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. 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.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • 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 changed
    • 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. Added

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint/idempotent/destructiveHint=false, so safety is covered; the description adds genuinely new behavior: recursion through nested includes for domain mode, own-terms-only for record mode, and the deliberate diagnose-only design ('no SPF fix record is ever returned') with its rationale. Permissions/rate-limit context is absent, but not needed for a read-only validator.

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?

Trigger conditions are front-loaded and the diagnose-only constraint is placed last as a deliberate caveat. However, the middle sentence enumerates return fields (record_valid, findings, has_pass_all, multiple_all, terms, over_limit...) that the output schema already supplies, so some content is redundant rather than earning its place.

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

Completeness4/5

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

With an output schema present and 100% schema coverage, an agent has everything required to invoke this correctly; the description adds the trigger framing and mode-selection rule that schemas can't express. It is complete, though the return-field enumeration slightly duplicates the output schema.

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?

Schema description coverage is 100%, so both parameters are already documented in the schema, including mutual exclusivity and the 'never a domain name' warning. The description restates the same distinction (recursive include counting vs. own terms only) without adding syntax that isn't already in the schema. Baseline 3 applies.

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+resource ('Validate an SPF record and count what it costs') and explicitly positions itself against siblings with 'This is the SPF validator — there is no separate one,' which disambiguates from validate_dmarc_record, audit_spf_includes, and check_record. An agent can tell what it does without opening the schema.

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?

Front-loads concrete trigger conditions ('too many lookups', 10-lookup limit, SPF PermError, record validity) and gives the selection rule for its two modes via 'Pass EXACTLY ONE of domain ... or record'. Usage is fully determined.

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
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources