Skip to main content
Glama

Agent Utility Suite (x402)

by io.github.vanakenj45
OverviewDiscussionsAdmin

Email address verification

email_verify
Read-onlyIdempotent

Answers "Is this email address valid?", "Will mail to it bounce?" and "Is it a throwaway, a shared inbox or a typo?" before an agent sends mail or saves a lead. Checks, without sending mail: syntax, whether the domain accepts email (MX records, an A/AAAA record as implicit MX, or a null MX that refuses all mail), disposable/temporary providers (a maintained list of thousands of domains), free webmail (Gmail, Outlook, Yahoo, ...), role accounts (info@, support@, noreply@), likely misspellings of big providers with a corrected suggestion (gmial.com → gmail.com), and the domain's SPF and DMARC records and email provider. Returns a verdict (deliverable, risky, undeliverable), a 0-100 score and the reasons. The mailbox itself is not probed (no SMTP), so a catch-all domain accepts any name. An invalid address is still an answer (undeliverable); only a DNS failure is an error, not charged. You are only charged when a result is returned: invalid input (400) and upstream failures (4xx/5xx) are not settled. Costs $0.001 USDC per call via x402. Paid per call with x402 inside MCP (see the server instructions).

Input Schema

NameRequiredDescriptionDefault
viaNoOptional: the tool whose next_calls suggested this call (filled in for you).
emailYesThe address to check, e.g. "jane@acme.com" (a "Jane Doe <jane@acme.com>" form is accepted).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / via
      Added value: +{
+  "description": "Optional: the tool whose next_calls suggested this call (filled in for you).",
+  "maxLength": 64,
+  "type": "string"
+}
  2. Added

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, it discloses key behavioral traits: no SMTP probing, catch-all domains accept any name, an invalid address is still a valid answer, only DNS failures error out, billing semantics (charged only on a returned result; 400/4xx/5xx are not settled), and the $0.001 x402 cost. This is substantially more than the annotations provide.

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 purpose is front-loaded as three crisp questions followed by a scannable list of checks. It is dense and mostly earns its length, though the billing rule is stated twice ("not charged" vs. the explicit 400/4xx/5xx carve-out), a minor redundancy.

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?

With no output schema, the description carries the return contract itself: a verdict (deliverable/risky/undeliverable), a 0-100 score, and reasons. Combined with the check list, billing and cost disclosure, an agent has everything needed to invoke and interpret it.

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 `email` and `via` are fully documented in the schema itself, including the accepted 'Jane Doe <jane@acme.com>' form. The description adds no parameter-level detail beyond the schema, so the 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?

The description opens with the concrete questions it answers ("Is this email address valid?", "Will mail to it bounce?", "Is it a throwaway...?") and then enumerates the exact checks performed. An agent immediately knows this is email-address validation, distinct from any sibling tool.

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 states the triggering context clearly — "before an agent sends mail or saves a lead" — which tells the agent when to call it. It does not name alternative tools or exclusions, but no sibling covers the same ground, so the guidance is sufficient though not exhaustive.

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

All Agent Utility Suite (x402) toolsInspect
Try in Browser
Let your AI agent see the webWeb-to-screenshot MCP for Claude, Cursor and Codex. No cookie banners. Free to start.snap-render.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources