What can you do with this server?

This server provides tools to check whether email addresses or domains are disposable, via the isitdisposable.com API. Useful for validating user signups and preventing abuse. Tools: * check_email: Checks a single email address. * check_domain: Checks a single bare domain (without @). * check_batch: Checks up to 100 mixed email addresses and bare domains efficiently. Response: Each check returns disposable (true/false), action (allow/warn/block), and optional signals like mx_valid, relay, public_domain, and did_you_mean (typo suggestion). Fail-open behavior: If a check fails due to network issues, timeouts, or rate limits, the server returns checked: false, disposable: null, and action: "allow" with a note, ensuring the tool never crashes. Note: this outcome is inconclusive, not safe. Requirements: A free API key from isitdisposable.com is needed for actual checks; without it, tool calls will indicate the missing key.

How do I use isitdisposable-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@isitdisposable-mcp Check if john.doe@temp-mail.org is disposable" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

isitdisposable-mcp

by richelo

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

isitdisposable-mcp

A Model Context Protocol (MCP) server that lets an AI agent check whether an email address or domain is disposable, using the isitdisposable.com application programming interface (API).

Installation

The server is published to the npm registry and is normally run with npx, so there is nothing to install by hand; the examples below show how to wire it into a Model Context Protocol (MCP) host.

Claude Desktop

Add this to your Claude Desktop configuration:

{
  "mcpServers": {
    "isitdisposable": {
      "command": "npx",
      "args": ["-y", "isitdisposable-mcp"],
      "env": { "ISITDISPOSABLE_API_KEY": "your_secret_key" }
    }
  }
}

Claude Code

claude mcp add isitdisposable --env ISITDISPOSABLE_API_KEY=your_secret_key -- npx -y isitdisposable-mcp

Related MCP server: mcp-email-sender

Getting an API key

An isitdisposable.com key is required. Get a free key at https://isitdisposable.com (a free tier is available), then set it as ISITDISPOSABLE_API_KEY in the configuration above.

Tools

Tool	What it does
`check_email`	Checks a single email address to see whether it is disposable.
`check_domain`	Checks a single bare domain (no local part) to see whether it is disposable.
`check_batch`	Checks up to 100 email addresses or bare domains at once in a single call. Mix full addresses and bare domains freely in the `items` list; entries containing an `@` sign are sent as email addresses, everything else as a domain.

Every tool returns the same verdict shape. disposable is the core true or false verdict: a disposable address is a throwaway or temporary inbox used to receive a single signup message and evade normal registration requirements, rather than a real, ongoing mailbox. action is the recommended handling of allow, warn, or block. A handful of opt in signals may also be present, including mx_valid (whether the domain's mail servers accept mail), relay (a forwarding or catch all style address), public_domain (a well known free provider such as Gmail), and did_you_mean (a likely intended domain when the one given looks like a typo).

Fail open behavior

This server always fails open. If a network problem, a timeout, a rate limit, or a server error prevents a real check from completing, the tool call still succeeds (it never throws or crashes the connection). It retries once after a short delay, and if that also fails, it returns a result with checked: false, disposable: null, and action: "allow", along with a note explaining that the check could not be completed. An agent using this tool should treat that outcome as inconclusive, not as a signal that the address is safe.

If no API key is configured, the server still starts normally and responds to the Model Context Protocol (MCP) handshake; each tool call then returns an error result pointing to https://isitdisposable.com to get a free key.

Available Tools

3 tools

check_batchCheck a batch of emails and domains for disposableA

Read-only

Checks up to 100 email addresses or domains at once in a single call, which is far more efficient than calling the single-item tools in a loop. Provide a mixed list in items: entries containing an @ sign are sent as email addresses, and all other entries are sent as bare domains. A disposable address is a throwaway or temporary inbox (for example from a burner mail service) that someone uses to receive a single signup message and evade normal registration requirements, rather than a real, ongoing mailbox. In the response, disposable is the core true or false verdict. action is the recommended handling: allow, warn, or block, based on the caller's own account policy. Extra opt in signals may also be present: mx_valid (whether the domain's mail servers accept mail at all), relay (a forwarding or catch all style address rather than a dedicated inbox), public_domain (a well known free provider such as Gmail or Outlook), and did_you_mean (a likely intended domain when the one given looks like a typo). This tool always fails open: if a network problem, timeout, rate limit, or server error prevents a real check, the call still succeeds and returns checked false with action allow, plus a note explaining the check could not be completed. Treat that outcome as inconclusive, never as evidence the address is safe.

ParametersJSON Schema

Name	Required	Description	Default
`items`	Yes	1 to 100 entries, each either a full email address or a bare domain. Entries containing an @ sign are checked as email addresses; all other entries are checked as bare domains.

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only say readOnly and openWorld. The description adds crucial behavioral details: fail-open behavior (call succeeds with checked false, action allow, note), the meaning of disposable, and the purpose of extra signals like mx_valid, relay, public_domain, and did_you_mean. No contradictions with annotations.

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 description is appropriately sized for a complex batch tool. Every sentence adds value: efficiency, input format, definition of disposable, response fields, and fail-open handling. Well-structured and front-loaded with the core purpose.

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 fully covers return values and edge cases. It explains all relevant response fields, the meaning of a disposable address, and the inconclusive fail-open outcome. This is complete for the tool's complexity.

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?

The input schema already fully describes the 'items' parameter with 100% coverage, including the @-sign rule and min/max. The description mainly echoes this rule without adding new parameter-specific semantics, so 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?

Clearly states the tool checks up to 100 emails or domains in a single call, with a specific verb and resource. It explicitly distinguishes from sibling tools by noting efficiency over looping single-item tools.

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?

Provides explicit guidance on when to use this tool instead of alternatives (batch vs loop), how to structure the mixed list, and how to interpret the response. Includes fail-open behavior, making it clear what to expect on errors.

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

check_domainCheck domain for disposableA

Read-only

Checks a single bare domain (no local part, for example when only a company's domain is known and not a specific address) to see whether it is disposable. A disposable address is a throwaway or temporary inbox (for example from a burner mail service) that someone uses to receive a single signup message and evade normal registration requirements, rather than a real, ongoing mailbox. In the response, disposable is the core true or false verdict. action is the recommended handling: allow, warn, or block, based on the caller's own account policy. Extra opt in signals may also be present: mx_valid (whether the domain's mail servers accept mail at all), relay (a forwarding or catch all style address rather than a dedicated inbox), public_domain (a well known free provider such as Gmail or Outlook), and did_you_mean (a likely intended domain when the one given looks like a typo). This tool always fails open: if a network problem, timeout, rate limit, or server error prevents a real check, the call still succeeds and returns checked false with action allow, plus a note explaining the check could not be completed. Treat that outcome as inconclusive, never as evidence the address is safe.

ParametersJSON Schema

Name	Required	Description	Default
`domain`	Yes	A bare domain with no local part and no @ sign, for example example.com.

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint, openWorldHint), the description details the fail-open behavior, the meaning of response fields (disposable, action, check flags), and optional signals (mx_valid, relay, etc.). It also clarifies that a failed check returns checked:false with action:allow and a note, which is critical behavioral context not in annotations.

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 description is lengthy but each sentence provides necessary context for a nuanced tool. It is well structured with clear concepts and edge-case disclosures (fail-open, opt-in signals). Slightly verbose but justified; no wasted words.

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?

Without an output schema, the description carries the full burden of explaining return values and behavior. It thoroughly covers the core verdict, action handling, optional fields, and failure semantics. Complete for a single-parameter tool.

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%, and the schema already explains that domain should be a bare domain without @ sign. The description reiterates this and adds a usage example, but does not add new syntax or format details beyond the schema. Baseline 3 is appropriate.

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 clearly states the tool's function with a specific verb and resource: 'Checks a single bare domain... to see whether it is disposable.' It also distinguishes from sibling tools by emphasizing 'single' and 'bare domain (no local part)', which separates it from check_email and check_batch.

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?

The description gives usage context: 'for example when only a company's domain is known and not a specific address.' It implies use cases but does not explicitly name alternatives or exclusions. Clear enough for an agent to select it over the email/batch variants.

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

check_emailCheck email for disposableA

Read-only

Checks a single email address to see whether it is disposable. A disposable address is a throwaway or temporary inbox (for example from a burner mail service) that someone uses to receive a single signup message and evade normal registration requirements, rather than a real, ongoing mailbox. In the response, disposable is the core true or false verdict. action is the recommended handling: allow, warn, or block, based on the caller's own account policy. Extra opt in signals may also be present: mx_valid (whether the domain's mail servers accept mail at all), relay (a forwarding or catch all style address rather than a dedicated inbox), public_domain (a well known free provider such as Gmail or Outlook), and did_you_mean (a likely intended domain when the one given looks like a typo). This tool always fails open: if a network problem, timeout, rate limit, or server error prevents a real check, the call still succeeds and returns checked false with action allow, plus a note explaining the check could not be completed. Treat that outcome as inconclusive, never as evidence the address is safe.

ParametersJSON Schema

Name	Required	Description	Default
`email`	Yes	The full email address to check, for example someone@example.com.

TDQS

A4.4/5.0

Behavior5/5

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

Annotations include readOnlyHint=true and openWorldHint=true, but the description goes much further by disclosing the fail-open behavior: on network problems, timeouts, rate limits, or server errors, the tool still succeeds with `checked:false` and `action:allow`, and this must be treated as inconclusive. It also details optional response fields (`mx_valid`, `relay`, etc.), which is valuable context not present in the annotations.

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 description is long, but it is well-structured and front-loaded with the core action. It then explains the disposable concept, response fields, and failure mode—each element adds value, especially given there is no output schema. It is slightly verbose but not redundant; every sentence serves a purpose.

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 a single parameter and no output schema, the description fully equips an agent to invoke the tool and interpret results. It covers input, all relevant output fields, the meaning of the verdict, and the critical fail-open behavior that could otherwise mislead the agent. The description is complete for the tool's complexity.

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 coverage is 100% for the single `email` parameter, which already includes a clear example ('someone@example.com'). The description repeats that example but adds no new technical constraints or formatting rules. It focuses on the semantic meaning of 'disposable,' which is helpful for concept understanding but does not deepen parameter semantics beyond the baseline.

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 a clear verb+resource: 'Checks a single email address to see whether it is disposable.' This specifically distinguishes it from sibling check_batch (which would handle multiple addresses) and check_domain (which targets domains), and the scope is immediately evident.

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 explicitly scopes the tool to 'a single email address,' which implies that batch checks should use the check_batch sibling. While it does not name alternatives or exclusion criteria, the clear single-address context provides sufficient guidance for selecting between the listed sibling tools.

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.

3 tool updatesv0.1.0Aug 5, 2026
- First observedcheck_batch
- First observedcheck_domain
- First observedcheck_email

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.7/5.0

Scored 2026-08-05 06:45 across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: check_email handles full addresses, check_domain handles bare domains, and check_batch handles mixed lists. While check_batch overlaps in capability, the single vs. batch distinction is explicit and unambiguous.

Naming Consistency5/5

All tool names follow the same check_ prefix followed by a noun (email, domain, batch), creating a predictable and consistent verb-noun pattern.

Tool Count5/5

Three tools are well-scoped for this service: single email, single domain, and batch. This covers the core use cases without bloat or unnecessary additions.

Completeness5/5

The tool surface fully covers the domain of disposable address checking: individual emails, individual domains, and batch processing. No obvious missing operations for a read-only verification service.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

Zyntra - Temp e-mails MCP A
app.zyntra.mcp
MCP server for e-mail testing: create disposable inboxes, wait for delivery, and extract e-mail content or links - all from your AI agent or test automation workflow. Get a free API key on https://app.zyntra.app/
Developer Tools Email Testing & QA Tools
2
ClawLinkOAuth
dev.claw-link
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
App Automation Workplace & Productivity
24
Agent Safe AOAuth
io.github.wowcool
Email safety MCP server. Detects phishing, prompt injection, CEO fraud for AI agents.
Security Autonomous Agents
2
anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2

Related MCP Servers

useblip/email
App Automation Customer Support Email
blipemail
A
license
A
quality
C
maintenance
MCP server for disposable email — create inboxes, receive emails, and extract OTP codes. Let your AI agent sign up for services, wait for verification emails, and extract codes autonomously.
Updated 6 months ago (2026-03-24 15:49 UTC)
7
37 npm
1
MIT
mcp-email-sender
AMEOBIUS-space
A
license
Not graded
quality
C
maintenance
An MCP server that enables AI agents to validate email addresses and send emails via SMTP with zero external dependencies.
Updated 2 months ago (2026-07-22 15:32 UTC)
MIT
smails
Email Communication
pexni
A
license
Not graded
quality
D
maintenance
Disposable email for humans and AI agents. Enables AI agents to create mailboxes and receive verification emails through an MCP server.
Updated 3 months ago (2026-06-26 11:48 UTC)
36
MIT
inboxvalid-mcp
Email
vigneshachar283
F
license
A
quality
B
maintenance
An MCP server that exposes a verify_email tool for checking email syntax, disposable domains, and MX records, returning a structured validity result.
Updated a month ago (2026-08-12 06:23 UTC)
1
-