Validate email addresses directly from Claude, Cursor, or any MCP-compatible AI assistant.
Related MCP server: Email MCP Server
validate_email — validate a single email
validate_emails_bulk — validate up to 100 emails at once
check_credits — check your credit balance
Sign up at https://bounceprotect.com
Go to Dashboard → API Keys
Create a new key
Add to your claude_desktop_config.json:
{
"mcpServers": {
"bounceprotect": {
"command": "node",
"args": ["/path/to/mcp-server/index.js"],
"env": {
"BOUNCEPROTECT_API_KEY": "your-api-key-here"
}
}
}
}Add to your Cursor MCP settings:
{
"bounceprotect": {
"command": "node",
"args": ["/path/to/mcp-server/index.js"],
"env": {
"BOUNCEPROTECT_API_KEY": "your-api-key-here"
}
}
}Once configured, you can ask your AI assistant:
"Validate the email john@acmecorp.com"
"Check if these 5 emails are valid: [list]"
"How many BounceProtect credits do I have left?"
"Validate all the emails in this list and tell me which ones to remove"
Each email validation costs 1 credit. Start with 100 free credits at bounceprotect.com.
Check your remaining BounceProtect credit balance.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. The verb 'Check' implies a read-only operation, but it does not disclose response format, rate limits, or whether the check consumes credits. However, for a simple balance lookup, these details are not critical.
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 a single, front-loaded sentence that states the exact purpose without any unnecessary words or redundancy. It is concise and well-structured.
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?
The tool has no output schema or annotations, so the description must convey the essence. It tells the user what to check but does not explicitly state the return value type or format. Yet, for a trivial zero-parameter tool, this level of detail is sufficient.
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?
The tool has zero parameters, so the description correctly omits any parameter details. The baseline for zero-parameter tools is 4, and no additional explanation is needed.
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 tool's function with a specific verb ('Check') and resource ('remaining BounceProtect credit balance'), distinguishing it from sibling email validation and status tools. There is no ambiguity about what the tool does.
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?
The description implies usage when the user needs to know their remaining credits, but it provides no explicit context, alternatives, or exclusions. This is an implied rather than explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check deep analysis progress for an upload and return full domain-level results when the job is complete.
| Name | Required | Description | Default |
|---|---|---|---|
| upload_id | Yes | The upload_id returned by a prior validation workflow. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It explicitly states that progress is checked and full results are only returned when the job is complete, implying intermediate status responses. It does not disclose auth, rate limits, or error behavior, but for a simple status check tool, these are less critical.
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 a single, well-structured sentence that front-loads the main action ('Check deep analysis progress') and explains the conditional outcome. Every word earns its place with no redundancy.
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?
For a simple one-parameter tool with no output schema, the description adequately conveys the purpose and the key behavioral distinction between progress and completion. It could be more explicit about the return format or that it may be polled, but given the tool's simplicity, this is largely complete.
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?
The only parameter upload_id is fully described in the schema as 'returned by a prior validation workflow.' The tool description adds no additional meaning beyond the schema, so it earns the baseline score for high schema coverage.
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 tool checks deep analysis progress and returns full domain-level results upon completion. It uses a specific verb ('check') and resource ('deep analysis progress'), distinguishing it from siblings like trigger_deep_analysis or get_smtp_status.
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?
The description implies this tool should be used after triggering deep analysis and potentially polled until completion. It gives clear context on what it does, though it does not explicitly exclude alternatives or state when not to use it. The sibling tool trigger_deep_analysis is an obvious complement but not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether background SMTP verification has completed for an upload and return updated results when ready.
| Name | Required | Description | Default |
|---|---|---|---|
| upload_id | Yes | The upload_id returned by validate_email or validate_emails_bulk when SMTP is still pending. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool checks completion and returns results when ready, but does not disclose what happens when verification has not completed (e.g., whether it returns a 'pending' status, blocks, or errors) or the structure of the returned results. This is a notable gap for a status-polling tool.
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 a single, well-structured sentence that front-loads the core purpose. It contains no waste and is appropriately concise for the tool's simplicity.
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 has only one parameter, no output schema, and no annotations, the description provides the essential purpose but leaves gaps about the exact return format and pending state behavior. It is acceptable for a simple status checker but not fully complete without these details.
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?
The schema description fully covers the only parameter, upload_id, explaining it is returned by validate_email or validate_emails_bulk when SMTP is pending. Since schema coverage is 100%, the description adds no additional parameter-specific information, warranting the baseline score of 3.
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 tool's purpose: checking whether background SMTP verification has completed for an upload and returning updated results. It uses a specific verb ('Check') and resource ('background SMTP verification'), and unambiguously distinguishes itself from sibling tools like validate_email and get_deep_analysis_status by focusing on SMTP status.
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?
The description implies when to use the tool: after an SMTP verification is pending, likely following validate_email or validate_emails_bulk. The upload_id schema description reinforces this by referencing those tools. However, it does not explicitly name alternatives or state when not to use this tool, so it falls slightly short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start deep analysis for an upload so you can inspect domain legitimacy, website/SSL signals, and matched organisation data.
| Name | Required | Description | Default |
|---|---|---|---|
| upload_id | Yes | The upload_id to analyse. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It says 'Start deep analysis' but does not disclose whether the operation is asynchronous, what it returns, or that you may need to poll get_deep_analysis_status. This lack of behavioral context is a significant gap.
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 a single sentence that starts with the action, states the resource, and gives the purpose. No wasted words.
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?
No output schema exists, so the description should explain what the tool returns or what happens after triggering. It does not mention the response or that the user should subsequently check status, leaving the workflow incomplete.
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?
The schema provides a description for upload_id (100% coverage), so the baseline is 3. The tool description adds no further semantic detail beyond what the schema already states.
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?
Specific verb 'Start' + resource 'deep analysis for an upload' clearly distinguish it from the sibling get_deep_analysis_status. It also states the purpose: to inspect domain legitimacy, website/SSL signals, and matched organisation data.
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?
Usage is implied: use when you want to initiate deep analysis for an upload. However, there is no explicit guidance on when to use this vs. alternatives like validate_email or check_credits, nor any mention of prerequisites or next steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a single email address. Returns deliverability status, spam risk score, SMTP verification result, and a send recommendation.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The email address to validate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses the main behavior and output fields (deliverability status, spam risk score, SMTP verification result, send recommendation), but it does not mention any side effects, network dependencies, or whether the tool is read-only. This is adequate but lacks deeper context.
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 a single, tightly-worded sentence that front-loads the key action and outcome. Every claim (single address, return types) earns its place, with no filler or redundancy.
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?
For a simple, single-parameter tool with no output schema, the description is fairly complete: it states the purpose and enumerates the return values. It could add usage guidance or mention edge cases, but the core information is present and sufficient given the tool's simplicity.
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?
The schema fully describes the only parameter ('email' with 'The email address to validate'), giving 100% coverage. The description adds no extra meaning about the parameter format, constraints, or example values, so the baseline score of 3 is appropriate.
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 tool's function: 'Validate a single email address' with a specific verb and resource. It also distinguishes itself from the sibling tool 'validate_emails_bulk' by explicitly limiting scope to a single address, making the purpose unambiguous.
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?
The phrase 'a single email address' provides clear context that this tool is for individual validation, not bulk operations, which helps differentiate from the sibling 'validate_emails_bulk'. However, it does not explicitly name the alternative or state when-not-to-use, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate up to 100 email addresses at once. Returns validation results for each email including status, recommendation, and deliverability signals.
| Name | Required | Description | Default |
|---|---|---|---|
| emails | Yes | Array of email addresses to validate (maximum 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return content (status, recommendation, deliverability signals) but does not mention whether validation consumes credits, is asynchronous, or has side effects. The description adds some value but leaves behavioral gaps.
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 two concise sentences, front-loaded with the core action and followed by output details. No unnecessary words or repetition.
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?
The tool is simple (1 parameter, no output schema), and the description adequately covers input and output. However, it omits contextual details like potential credit usage or relationship to sibling tools like 'check_credits', which could be important for an agent.
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?
The schema fully documents the 'emails' parameter (array, max 100), with 100% coverage. The description only restates the limit and batch behavior, adding no new semantic information beyond what the schema already provides.
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 tool validates email addresses in bulk, with a specific limit of 100. The verb 'Validate' and resource 'up to 100 email addresses at once' distinguish it from the sibling 'validate_email', which is singular.
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?
The description implies bulk usage via 'at once' and the 100-email limit, providing clear context for when to use it. However, it does not explicitly mention the alternative 'validate_email' for single addresses or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct operation: single validation, bulk validation, credit check, SMTP status, deep analysis trigger, and deep analysis status. The two status tools could be confused at a glance, but their names reference different processes clearly.
All tool names follow a consistent verb_first snake_case pattern (validate, check, get, trigger). The conventions are uniform and easy to predict, with no mixed styles.
Six tools is an ideal size for an email validation service, covering the essential operations without unnecessary overlap or bloat.
The set covers the full validation workflow: single and bulk validation, credit monitoring, asynchronous SMTP status, and deep analysis with its own status check. A minor gap is the lack of explicit upload management or historical view, but the core lifecycle is complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Email validation for Claude and any MCP client — verdicts with evidence, bulk jobs, refunds.
Email verification for AI agents — verify, clean & validate emails; self-onboard + crypto pay
Connect any mailbox to Claude, ChatGPT & AI: read, send, reply, schedule & search emails.
Verify email deliverability by SMTP. Catch-all/disposable/role detection. EU-hosted, GDPR-ready.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/BounceProtect/bounceprotect-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
