FreeTier Agent API

email-verify

email_verify

Read-only

3 free MCP calls per day (all tools together), then $0.004 USDC via x402 or card credits (paid in-band: params._meta["x402/payment"]). Email verify: Email address check WITHOUT sending mail or SMTP probing: RFC-style syntax check, domain MX/A records via DNS-over-HTTPS, disposable-domain flag (CC0 blocklist, ~9,900 domains), role-address flag (info@, support@...), free-mail flag. Verdict: deliverable_domain | risky | invalid. Cannot confirm that the mailbox itself exists. Addresses are not stored or logged. When to use: Use email-verify to check syntax, MX and disposable domains for one address (DNS only, no mailbox probe).

Input Schema

Name	Required	Description	Default
`email`	Yes	one email address

Output Schema

Name	Required	Description	Default
`mx`	No
`note`	No
`role`	No
`email`	No
`has_a`	No
`domain`	No
`has_mx`	No
`null_mx`	No
`reasons`	No
`sources`	No
`verdict`	No
`free_mail`	No
`syntax_ok`	No
`disposable`	No
`local_part_length`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 26, 2026

changedOutput schema / description

Previous value: -"Inferred from a real response captured on 2026-10-24; extra fields may appear, null-valued fields are untyped."New value: +"Inferred from a real response captured on 2026-10-26; extra fields may appear, null-valued fields are untyped."

Changed1 schema field changedOct 24, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "description": "Inferred from a real response captured on 2026-10-24; extra fields may appear, null-valued fields are untyped.",
+  "properties": {
+    "disposable": {
+      "type": [
+        "boolean",
+        "null"
+      ]
+    },
+    "domain": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "email": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "free_mail": {
+      "type": [
+        "boolean",
+        "null"
+      ]
+    },
+    "has_a": {
+      "type": [
+        "boolean",
+        "null"
+      ]
+    },
+    "has_mx": {
+      "type": [
+        "boolean",
+        "null"
+      ]
+    },
+    "local_part_length": {
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "mx": {
+      "items": {
+        "properties": {
+          "host": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "preference": {
+            "type": [
+              "number",
+              "null"
+            ]
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "note": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "null_mx": {
+      "type": [
+        "boolean",
+        "null"
+      ]
+    },
+    "reasons": {
+      "items": {
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "type": "array"
+    },
+    "role": {
+      "type": [
+        "boolean",
+        "null"
+      ]
+    },
+    "sources": {
+      "items": {
+        "properties": {
+          "license": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "name": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "snapshot": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "url": {
+            "type": [
+              "string",
+              "null"
+            ]
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "syntax_ok": {
+      "type": [
+        "boolean",
+        "null"
+      ]
+    },
+    "verdict": {
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "type": "object"
+}

First observedOct 18, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Beyond the readOnly/openWorld annotations, it discloses that no mail is sent, no SMTP probing occurs, DNS is queried via DNS-over-HTTPS, the mailbox existence cannot be confirmed, and addresses are not stored or logged. It also states the free-call limit and payment mechanism, which are valuable operational details.

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 description is dense but each element—pricing, non-goals, checks, verdicts, data handling, and usage—is relevant to calling or selecting the tool. It is slightly front-loaded with billing information before the tool purpose, but overall it remains compact and information-rich.

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?

Given one simple required parameter, a present output schema, and annotations covering safety and openness, the description is complete. It still adds the key limitations and data-handling behavior an agent would otherwise lack.

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?

There is one required parameter and schema coverage is 100%, with the schema itself describing it as 'one email address.' The description reinforces the single-address scope but adds no format, normalization, or validation details beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource ('Email verify: Email address check') and spells out exactly what is checked: syntax, MX/A DNS, disposable domain, role address, and free-mail flags. It also states the verdicts and the single-address scope, though it does not explicitly name sibling tools such as email_verify_quick or email_verify_batch to distinguish itself.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It includes a clear 'When to use' sentence scoped to one address with DNS-only checking and no mailbox probe. It does not explicitly name alternatives or say when another sibling should be preferred, but the single-address/DNS-only framing gives practical selection guidance.

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

All FreeTier Agent API 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.

Resources

Need Help?