email-verify
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| verify_emailA | Verify whether an email address is real and deliverable, live. Checks: syntax (RFC-shaped, typos like gmial.com), the domain's live MX records (can it receive mail at all), whether the domain is a known disposable/temporary provider (Mailinator, temp-mail, 10minutemail, ...), whether the local-part is a role/shared mailbox (info@, admin@, support@), whether it's a consumer free-webmail address, catch-all detection, and — when deep=true — a live SMTP RCPT-TO probe of the real mail server to confirm the specific MAILBOX exists WITHOUT sending any email. Returns a VALID / RISKY / INVALID verdict, a 0-100 deliverability score and explained reasons. Use this before adding an email to a list, accepting a signup, or sending mail you don't want to bounce. |
| verify_manyA | Verify a batch of email addresses at once (e.g. a whole mailing list). Returns one verdict per address. Useful to clean a list before a campaign — flagging invalid, disposable, role-based and risky addresses that would bounce or hurt deliverability. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
The two tools are clearly distinct: one verifies a single email address, the other verifies a batch. There is no ambiguity or overlap.
Both tools follow a consistent verb_noun pattern: 'verify_email' and 'verify_many'. The naming is predictable and clear.
Two tools is appropriate for the focused domain of email verification. While more tools could be added (e.g., domain check), the current count is reasonable for the core functionality.
The server covers both single and batch verification, which are the primary use cases for email verification. No obvious gaps in the tool surface for its stated purpose.