Skip to main content
Glama
fairquery

Email Validator for Agents

Check email syntax offline (free)

check_email_syntax
Read-onlyIdempotent

Validate email syntax and normalize addresses locally. Use for quick pre-filtering or parsing before deliverability checks, when only format matters.

Instructions

WHAT: Check whether strings are syntactically valid email addresses and normalize them (extracts "Name ", lowercases the domain), entirely locally. WHEN TO USE: fast pre-filtering or parsing before calling validate_emails, or when only the format matters. WHEN NOT TO USE: it does not check that the domain exists, has MX records, is disposable, a role account or a typo - use validate_emails (paid) for deliverability. COST: free; pure local function, no network, no APIFY_TOKEN, deterministic. RETURNS: {count, items}: one "email_syntax" row per input with input, email (normalized), syntax_valid, local_part, domain, reason (null or INVALID_SYNTAX). EXAMPLE: {"emails":["Jane jane@Example.com"]} -> email "jane@example.com", syntax_valid true, domain "example.com".

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
emailsYesRequired. 1-10000 strings to check; each may be a bare address or "Name <addr>" form. Example: ["Jane <jane@Example.com>","not-an-email"]

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
countYesNumber of rows returned
itemsYesResult rows; each has a "type" field (data rows or machine-readable "error" rows)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.0.1

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the bar is lower, yet the description adds substantial value: cost is free, execution is pure local with no network and no APIFY_TOKEN, results are deterministic, and it discloses the normalization behavior (extracting 'Name <addr>', lowercasing the domain). That goes well beyond the structured hints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The WHAT/WHEN TO USE/WHEN NOT TO USE/COST/RETURNS/EXAMPLE structure is tightly front-loaded, with the purpose and routing condition in the first two blocks and no filler sentences. Every section carries distinct information.

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 single-parameter, read-only, local tool the description covers purpose, exclusions, cost, determinism, normalization semantics and the return shape, even though an output schema exists. An agent has everything needed to call it correctly and interpret results.

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 coverage is 100% and the schema already documents the emails array, its 1-10000 bounds and the 'Name <addr>' form, so the baseline is 3. The description adds real semantic detail by explaining what normalization is applied to each input and the per-item reason value, which is more than the schema conveys.

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 precise verb+resource (check syntactic validity of email strings) plus the scope ('entirely locally') and even names the normalization side effect. It explicitly contrasts itself with the validate_emails sibling, so an agent can distinguish them without opening either 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?

The WHEN TO USE / WHEN NOT TO USE blocks are explicit: use for fast pre-filtering or parsing before validate_emails, and do not use when domain existence, MX, disposable/role detection or typo checks are needed. It names the exact alternative and the condition that selects it.

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

Deploy Server

Other Tools