Skip to main content
Glama

verify-the-email-instantly

Server Details

Verify the email instantly: Identify the spam email while authenticating your users.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Last Tested
Transport
Streamable HTTP
URL

Available Tools

1 tool
get_emailVerify the email instantlyCInspect

Verify the email instantly Billing per call: 1 Credits.

ParametersJSON Schema
NameRequiredDescriptionDefault
emailNo

TDQS

C2.5/5.0
Behavior2/5

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.

Conciseness3/5

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.

Completeness1/5

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.

Parameters2/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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. Dates show when Glama detected each change.

  1. 1 tool update
    • First observedget_email

Frequently Asked Questions

Discussions

No comments yet. Be the first to start the discussion!

Related MCP Connectors

Related MCP Servers

  • F
    license
    Not graded
    quality
    B
    maintenance
    Enables 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.
    -
  • A
    license
    A
    quality
    B
    maintenance
    Enables 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.
    2
    31
    MIT
  • A
    license
    Not graded
    quality
    B
    maintenance
    Real-time email verification API with syntax, MX, disposable detection, role-based flags, quality score 0-100. Built for agent outreach pipelines with pay-per-call via x402 (USDC on Base L2) -- no API key, no signup, no rate-limit wall.
    MIT
Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3/5.0
Disambiguation5/5

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.

Naming Consistency4/5

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.

Tool Count3/5

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.

Completeness4/5

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.

Resources