IntoDNS.ai DNS & Email Security Scanner

Generate SPF record

generate_spf

Read-onlyIdempotent

Build an SPF (Sender Policy Framework) record — the DNS TXT record that lists which servers may send mail for a domain. Pass the senders as mechanisms: include for a provider's own SPF (Google Workspace is _spf.google.com, Microsoft 365 is spf.protection.outlook.com, SendGrid is sendgrid.net), ip4/ip6 for your own servers, plus useMx/useA to authorise the domain's own MX or A records. The policy decides what receivers do with mail from anywhere else: 'fail' (-all, the production choice), 'softfail' (~all, for testing), 'neutral', or 'pass' (+all, which authorises the entire internet and should never be published). SPF is limited to ten DNS-triggering terms during recursive evaluation. This pure builder counts direct mechanisms; include and redirect targets can add nested lookups, so validate the published record with check_spf before treating the count as final. Returns the record, direct lookup count, whether that direct count or the 255-character limit is exceeded, plain-language warnings, and the DNS entry to publish. Use check_spf to resolve and validate a live record, and flatten_spf only when an existing record is over the limit. Invalid input (an address that is not IPv4/IPv6 for ip4/ip6, a value that is not a domain name, or a second redirect=) is refused with an error instead of a record. Nothing is looked up or stored — this is computation only.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "generate_spf"
  }
}

Input Schema

Name	Required	Description
`useA`	No	Authorise the domain's own A/AAAA records. Costs one DNS lookup.
`useMx`	No	Authorise the domain's MX hosts. Costs one DNS lookup.
`policy`	No	What receivers do with everything else: fail (-all) for production, softfail (~all) while testing. Defaults to fail.
`mechanisms`	No	Senders to authorise, in the order they should appear in the record

Schema Changelog

Changes observed during successful MCP inspections.

First observedAug 21, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already mark it readOnly, idempotent, non-destructive, and openWorld, and the description adds substantial context beyond them: no DNS lookups or storage occur, invalid inputs are refused with an error, the direct lookup count is returned, and nested include/redirect lookups may not be captured. It also discloses the 255-character limit and the ten-term SPF restriction.

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 definition is front-loaded with the core purpose and is generally dense with useful detail rather than filler. It is somewhat long, but almost every sentence carries operational value: mechanism semantics, policy implications, lookup limits, return values, alternatives, and validation behavior.

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?

For a computation-only tool with no output schema, the description covers what is returned (record, direct lookup count, limit flags, warnings, publishable DNS entry), what is not done (no lookups or storage), how invalid input is handled, and how validation should follow. Nothing essential is missing for correct invocation.

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 description coverage is 100%, so the schema already documents the parameters, making 3 the baseline. The description nevertheless adds useful meaning: provider include values such as _spf.google.com, spf.protection.outlook.com, and sendgrid.net; the lookup cost of useMx/useA; and the operational implications of each policy value.

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 states a specific verb and resource: build an SPF DNS TXT record that lists authorized sending servers for a domain. It clearly distinguishes itself from the sibling tools check_spf and flatten_spf by naming when those are used instead. An agent can identify exactly what this tool produces 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?

It explicitly routes validation to check_spf, limits flatten_spf to existing records over the lookup limit, and explains when to use 'fail' versus 'softfail' policy. It also warns that 'pass' should never be published. Alternatives and conditions are stated directly.

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

All IntoDNS.ai DNS & Email Security Scanner tools Inspect

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.