verify-the-email-instantly
Server Details
Verify the email instantly: Identify the spam email while authenticating your users.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
TDQS
Scored across 1 tool
There is only one tool, so there is no possibility of confusion between tools. The description clearly indicates the tool verifies an email, making its purpose unambiguous.
The single tool follows a conventional verb_noun pattern (get_email), but the verb 'get' does not precisely match the server's purpose of 'verify'. While there is no internal inconsistency, the naming could be better aligned with the server's function.
A single tool feels thin for a server, even for a narrow purpose. The calibration notes that 1-2 tools is borderline, so this score reflects that while the scope is consistent, the tool count is minimal.
The server covers the essential action of verifying an email. However, it lacks related features such as bulk verification or history records, which could be expected in a more complete email verification service.
Available Tools
1 toolget_emailVerify the email instantlyCInspect
Verify the email instantly Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions 'Billing per call: 1 Credits', which discloses a cost, and 'instantly' suggests speed. However, it does not describe what verification does (e.g., checks syntax, domain existence), side effects, or outcome behavior. This is insufficient transparency for a tool with no structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, which is good for conciseness. However, the billing info is awkwardly appended and the content is too sparse to be functional. It is appropriately brief but lacks essential detail, so a middle score is warranted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no complex schema), the description should at least explain what verification means and any limitations. It only repeats the title and adds a billing note, providing no meaningful context. This is inadequate even for a simple tool, especially with no annotations or output schema to rely on.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The only parameter is 'email', which is self-explanatory due to its name, but the description adds no additional meaning, format constraints, or usage notes. The schema itself has an example but no description. Thus, the parameter semantics are under-explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Verify' and the resource 'email', which conveys the core purpose. It distinguishes from the name 'get_email' by indicating the action is verification, not retrieval. However, it lacks specifics on what 'verify' entails (format, deliverability, etc.), so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any exclusions or prerequisites. The fact that it verifies an email implies usage for that purpose, but there's no explicit context, and no sibling tools exist. This is minimal guidance, so it earns a 2.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- First observed
get_email
Related MCP Connectors
Fast email validation at the edge: syntax, MX records, disposable-domain detection.
Verify email deliverability by SMTP. Catch-all/disposable/role detection. EU-hosted, GDPR-ready.
Verify emails and domains for routing, disposable providers, role accounts, and SMTP risk.
Verify emails — deliverability, disposable/role/free detection, MX validity, domain age.
Related MCP Servers
- FlicenseNot gradedqualityCmaintenanceProvides email verification as a tool, performing syntax validation, domain verification, and disposable-domain risk detection.-
- FlicenseNot gradedqualityBmaintenanceEnables AI agents to verify email addresses in real-time, checking syntax, DNS, MX records, and SMTP handshake, returning verdicts and deliverability scores without sending actual emails.-
- AlicenseNot gradedqualityAmaintenanceEnables AI agents to verify email addresses and receive a 'send', 'hold', or 'kill' verdict with the reason, while also managing signup and credits programmatically.2MIT
- AlicenseAqualityBmaintenanceEnables real-time email verification via MCP tools, checking syntax, MX, disposable domains, and optional SMTP probe to determine deliverability with a VALID/RISKY/INVALID verdict.28MIT