Skip to main content
Glama
Sign In

hexadata-tools

by io.github.4robot
OverviewDiscussionsAdmin

Validate e-mail address and domain (MX, disposable)

validate_email_domain

Use this when you need to know whether an e-mail address is well-formed and its domain can receive mail before storing a contact, sending an invoice or onboarding a supplier. Checks RFC 5322 syntax, looks up the domain MX records in DNS (no message is sent, nothing is stored), flags disposable domains (public CC0 blocklist, ~10k domains) and well-known free providers. Returns valid, reason, normalized address, domain, hasMx, mxHosts, disposable, freeProvider. It does not verify that the mailbox exists.

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": "validate_email_domain"
  }
}

Input Schema

NameRequiredDescriptionDefault
emailNoE-mail address to check, e.g. "billing@example.com". Only the domain is queried in DNS; no message is sent.
itemsNoBatch mode: up to 500 items, each with the same fields as a single call. Omit when validating a single value through the top-level fields.
checkMxNoQuery DNS for MX records (default true). Set false for a purely offline syntax + disposable check.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses that no message is sent, nothing is stored, the domain is queried in DNS, the disposable list is a public CC0 blocklist of ~10k domains, and that mailbox existence is out of scope. Remaining gaps are operational traits like rate limits, latency, or failure behavior on DNS errors.

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 'Use this when...' trigger, then checks, then return fields, then the limitation — a sensible order with no filler. The return-field enumeration is somewhat list-like but earns its place given there is no output schema.

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?

For a read-only, no-side-effect tool with no annotations and no output schema, the description covers inputs, side effects, return shape, and the key caveat. It is nearly complete; only batch-mode behavior and error/DNS-failure handling are left unaddressed.

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 the schema already documents email, checkMx, and the batch items array. The description adds only the DNS-scoping note, which the email parameter description already states, and never mentions batch mode or the checkMx toggle. Baseline 3 is correct when the schema does the heavy lifting.

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 ('know whether an e-mail address is well-formed and its domain can receive mail') and enumerates the three checks performed: RFC 5322 syntax, MX lookup, and disposable/free-provider flagging. The resource (e-mail) is distinct from every sibling validator (IBAN, tax ID, phone, postal code), so an agent can discriminate without opening schemas.

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?

Gives concrete triggering scenarios ('before storing a contact, sending an invoice or onboarding a supplier') and a clear negative boundary ('It does not verify that the mailbox exists'), which prevents over-trusting the result. It stops short of naming when to skip the call or pointing at a sibling for related checks.

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

All hexadata-tools toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources