tools_spf_record_checkerFree public API. Look up and validate the SPF record for a domain. Counts void/total DNS lookups, flags syntax issues, validates against RFC 7208's 10-lookup limit.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to check SPF for. |
| Name | Required | Description | Default |
|---|---|---|---|
| ok | Yes | Always true here; failures return an isError result instead. | |
| data | Yes |
Changes observed during successful MCP inspections.
Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "description": "The domain's SPF record, parsed and validated.",
+ "properties": {
+ "data": {
+ "additionalProperties": true,
+ "properties": {
+ "domain": {
+ "type": "string"
+ },
+ "issues": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "level": {
+ "description": "error | warning | info.",
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "level",
+ "message"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "lookupCount": {
+ "description": "DNS lookups consumed; RFC 7208 allows at most 10.",
+ "type": "number"
+ },
+ "mechanisms": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "qualifier": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ },
+ "value": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "qualifier",
+ "type"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "present": {
+ "type": "boolean"
+ },
+ "record": {
+ "type": "string"
+ },
+ "records": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "domain",
+ "present",
+ "lookupCount",
+ "issues"
+ ],
+ "type": "object"
+ },
+ "ok": {
+ "description": "Always true here; failures return an isError result instead.",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "ok",
+ "data"
+ ],
+ "type": "object"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive, open-world behavior, so the bar is lower. The description still adds real value by disclosing what the validation actually computes: void vs. total DNS lookup counts, syntax issue flags, and enforcement of RFC 7208's 10-lookup limit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with no redundancy, and the validation criteria are listed compactly. Leading with the 'Free public API.' fragment is slightly awkward since it delays the purpose statement, but it is brief enough not to hurt.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only lookup with an output schema that documents the return shape and rich annotations covering the safety profile, the description supplies everything needed to invoke it correctly. Only the accepted domain format is left unstated, which is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single parameter with 100% schema description coverage ('Domain to check SPF for'), which sets the baseline at 3. The description adds no syntax guidance such as whether a bare domain, subdomain, or full email address is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('look up and validate') and resource ('the SPF record for a domain'), and the SPF resource type inherently separates it from the DKIM, DMARC, and generic TXT siblings. It never explicitly names or excludes those alternatives, so it stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the purpose: use it when you need to validate a domain's SPF configuration, and the 'Free public API' note hints at unrestricted experimentation. However, there is no statement of when to prefer this over tools_txt_record_lookup or tools_dmarc_record_checker, and no prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.