How do I use verifox-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., "@verifox-mcp Check if john@google.com is a valid email" 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.

verifox-mcp

by verifoxturnix1

Overview Schema Source Related Servers Discussions Admin

JavaScript

Hybrid

Verifox MCP Server

MCP (Model Context Protocol) server that gives Claude and other AI assistants the Verifox API — verify email deliverability and find business emails, both single and in bulk.

Quick start (published package)

Add to your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json) or Claude Code MCP config — no install needed, npx fetches it:

{
  "mcpServers": {
    "verifox": {
      "command": "npx",
      "args": ["-y", "verifox-mcp"],
      "env": {
        "VERIFOX_API_KEY": "foxkey_your_key_here"
      }
    }
  }
}

Get a free API key (1,000 credits) at https://verifox.ai/dashboard/api. Restart Claude Desktop and ask it to "verify these emails".

Related MCP server: GrowthToolkit MCP Server

Tools

Tool	Does	Credits
`verify_email`	Verify ONE email — SMTP deliverability, catch-all, disposable, role, free + 0-100 score	1 / email
`verify_emails`	Bulk-verify a LIST — submits, waits, returns one result per email	1 / email
`find_email`	Find ONE business email from name + company domain (best match or not_found)	10 / find
`find_emails`	Bulk-find emails for a LIST of contacts (name + domain each)	10 / contact
`get_credits`	Check the account's remaining Fox Credit balance	free
`get_job`	Poll a long-running `verify_emails` / `find_email` / `find_emails` job for results	—

Verify and find are async for large lists: the bulk tools wait ~55s inline, and hand back a jobId to finish via get_job if a job runs longer. Cached verifications cost 0 credits.

Local development

Run straight from source with Bun (no build):

cd mcp
bun install

{
  "mcpServers": {
    "verifox": {
      "command": "bun",
      "args": ["run", "/FULL/PATH/TO/Verifox-api/mcp/src/index.ts"],
      "env": {
        "VERIFOX_API_URL": "https://api.verifox.ai",
        "VERIFOX_API_KEY": "foxkey_your_key_here"

```json
{
  "mcpServers": {
    "verifox": {
      "command": "bun",
      "args": ["run", "/FULL/PATH/TO/Verifox-api/mcp/src/index.ts"],
      "env": {
        "VERIFOX_API_URL": "https://api.verifox.ai",
        "VERIFOX_API_KEY": "foxkey_your_key_here"
      }
    }
  }
}

VERIFOX_API_URL defaults to https://api.verifox.ai when unset. For local development against the API on port 8001, set it to http://localhost:8001.

3. Restart Claude Desktop

The tools will appear in Claude's tool list.

Remote (HTTP) mode

The same server also runs as a streamable-HTTP MCP endpoint (for Smithery, claude.ai connectors, and other remote MCP clients). Set MCP_TRANSPORT=http (or a PORT) and it listens on POST /mcp with a GET /health check:

MCP_TRANSPORT=http PORT=8080 node dist/index.js
# or: docker build -t verifox-mcp . && docker run -p 8080:8080 verifox-mcp

In HTTP mode the Verifox API key is read per request from the Authorization: Bearer <foxkey> header (also accepts x-api-key or ?api_key=) — so one hosted endpoint serves many users, each on their own credits.

Usage Examples

In Claude Desktop, just ask:

"Scan stripe.com for security issues"
"Check if john@google.com is a valid email"
"Score these emails: admin@stripe.com, test@mailinator.com, john.doe@microsoft.com"
"Find the email for Patrick Collison at stripe.com"
"Run OSINT on tesla.com — find subdomains and emails"
"Test the email server for turnix.co"
"Check DMARC policy for google.com"

Environment Variables

Variable	Default	Description
`VERIFOX_API_URL`	`https://api.verifox.ai`	Verifox API base URL
`VERIFOX_API_KEY`	(empty)	Per-user API key (`foxkey_*`), sent as `x-api-key`

Generate a foxkey_* key from the Verifox dashboard (API Keys). The key authenticates every tool call and is the account whose Fox Credits are charged (verify and find cost 1 credit each; scoring and DNS scans are free).

Available Tools

6 tools

find_emailAInspect

Find ONE person's business email from their name and company domain. Generates ~50 permutations and SMTP-verifies each, waits for the result, and returns the best match (or not_found). Charges 10 Fox Credits per find.

ParametersJSON Schema

Name	Required	Description
`domain`	Yes	Company domain, e.g. stripe.com
`last_name`	Yes	Person's last name
`first_name`	Yes	Person's first name
`middle_name`	No	Optional middle name for more permutations

TDQS

A4.3/5.0

Behavior4/5

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

No annotations provided, but the description fully carries the burden: discloses generation of 50 permutations, SMTP verification, synchronous wait, return of best match or not_found, and cost. This exceeds minimal expectations.

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?

Three sentences, each earning its place: purpose, method/behavior, and cost. Front-loaded with verb and resource. No redundancy.

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?

Despite no annotations or output schema, the description covers input semantics, process (generating, verifying, returning), cost, and possible output 'not_found'. Complete for a single-email finder with good annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. Description adds value by noting middle_name is 'Optional middle name for more permutations', which explains its behavioral effect beyond schema.

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?

Description explicitly states it finds ONE person's business email from name and company domain, clearly distinguishing it from sibling 'find_emails' which suggests multiple results. The verb 'Find' and resource 'business email' are specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage for single email lookup but does not explicitly state when to use this tool versus alternatives like verify_email or find_emails. Mentions 10 Fox Credits cost, which is relevant for cost-aware selection.

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

find_emailsAInspect

Bulk-find business emails for a LIST of contacts (name + company domain each). Submits the list, waits for completion, and returns the found email per contact. Up to 1000 contacts. Charges 10 Fox Credits per contact. Large lists that don't finish quickly return a jobId to poll with get_job.

ParametersJSON Schema

Name	Required	Description	Default
`wait`	No	Wait for results in this call (default true)
`contacts`	Yes	Contacts to find emails for

TDQS

A4.2/5.0

Behavior4/5

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

No annotations, so description carries full burden. Discloses submission, wait, return of emails or jobId, and billing. Sufficiently transparent for a read-heavy but mutating (credit-burning) operation.

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?

Three concise sentences, front-loaded with purpose, no filler. Efficiently conveys all key behaviors.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Describes return value (email or jobId), limits, and billing. No output schema, so description adequately covers expected response. Lacks error behavior explanation but still complete enough.

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%, so description adds minimal value. It mentions 'name + company domain each' clarifying the pattern, but no extra detail beyond schema. Baseline 3 justified.

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?

Clear purpose: bulk-finds business emails for a list of contacts, each with name and company domain. Distinguishes from sibling 'find_email' by specifying list processing and bulk nature.

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?

Describes usage context: up to 1000 contacts, charges 10 Fox Credits per contact, and async polling with jobId for large lists. Lacks explicit when-not-to-use or alternatives, but provides sufficient guidance.

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

get_creditsAInspect

Get the current Fox Credit balance for the Verifox account tied to the API key. Free — no credits charged. Use it to check remaining balance before a big verify/find run (verify = 1 credit/email, find = 10 credits/contact).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.6/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. Discloses that it is free ('no credits charged') and implies read-only. Could mention rate limits or response format, but adequate for a simple balance check.

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?

Two concise sentences front-loading purpose and key behavioral trait. Every sentence adds value with zero waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, cost, and usage context. Lacks specification of return format (e.g., data type), but for a balance check the expected result is simple enough that missing output schema doesn't severely hinder usability.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, schema coverage 100%. Baseline of 4 applies; description adds no parameter info because none needed.

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?

Uses specific verb 'Get' and resource 'Fox Credit balance' with account context. Clearly distinguishes from sibling tools that perform verify/find operations.

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?

Explicitly states when to use: 'check remaining balance before a big verify/find run'. Provides credit costs for sibling tools, guiding the agent on planning.

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

get_jobAInspect

Check an async job started by verify_emails, find_email, or find_emails. Returns results if finished, otherwise the current status. Use the type shown in the submitting tool's response.

ParametersJSON Schema

Name	Required	Description	Default
`type`	Yes	Job type: verify_bulk, find_single, or find_bulk
`job_id`	Yes	Job ID from verify_emails / find_email / find_emails

TDQS

A4.4/5.0

Behavior4/5

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

No annotations are provided, so the description carries full burden. It discloses that the tool returns results if finished or status otherwise, indicating a non-destructive, read-only behavior. No hidden side effects are implied.

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?

Two sentences with no wasted words. The main purpose is front-loaded, and guidance follows directly. Every sentence serves a clear purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool and good annotations (though none), the description covers primary functionality. It could mention that job_id is returned by the parent tools, but it's implied. No output schema exists, so explaining return values is sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds value by connecting parameters to the submitting tools ('Job ID from verify_emails...' and 'type shown in the submitting tool's response'), which is not in the schema.

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 it checks async jobs started by verify_emails, find_email, or find_emails. It specifies what it returns (results or status), distinguishing it from the sibling tools that initiate jobs.

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 tells when to use the tool (after starting a job with those tools) and how to determine the 'type' parameter. It lacks explicit when-not-to-use instructions, but the context makes it clear there are no direct alternatives within this group.

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

verify_emailAInspect

Verify whether ONE email address is deliverable. Checks syntax, MX, SMTP, catch-all, disposable, free-provider and role detection, and returns a 0-100 quality score. Charges 1 Fox Credit per uncached email.

ParametersJSON Schema

Name	Required	Description	Default
`email`	Yes	Email address to verify
`proxy`	No	Use a SOCKS5 proxy for the SMTP check

TDQS

A3.7/5.0

Behavior3/5

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

Discloses cost (1 Fox Credit per uncached email) and checks performed, but no annotations exist. Missing details on rate limits, error handling, or 'uncached' definition.

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?

Two sentences, front-loaded with purpose, then details and cost. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, so description should clarify return values. Mentions quality score but incomplete (e.g., no mention of success/failure response, additional fields). Adequate but not fully comprehensive.

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 covers 100% with descriptions for both parameters. Description adds marginal value (cost note) but doesn't elaborate on parameter behavior beyond schema.

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 verifies email deliverability and lists specific checks (syntax, MX, SMTP, etc.) and returns a quality score. It distinguishes from siblings like 'verify_emails' by specifying 'ONE email'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied (verify a single email), but no guidance on when to use this vs 'verify_emails' or 'find_email', and no exclusions or prerequisites mentioned.

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

verify_emailsAInspect

Bulk-verify a LIST of email addresses. Submits the whole list, waits for completion, and returns one result per email (same fields as verify_email). Best for cleaning lead lists. Charges 1 Fox Credit per email. Large lists that don't finish quickly return a jobId to poll with get_job.

ParametersJSON Schema

Name	Required	Description	Default
`wait`	No	Wait for results in this call (default true). Set false to just get a jobId.
`emails`	Yes	Email addresses to verify

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations, the description fully discloses behavior: submits entire list, waits for completion (or returns jobId), returns one result per email, charges per email, and recommends polling for large lists. No contradictions.

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?

Three sentences, each adding value: purpose, behavior/pricing, and fallback for large lists. Front-loaded and no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given lack of output schema, description covers input, behavior, and output format (same as verify_email). It mentions pricing and polling but omits error handling or rate limits. Still reasonably complete for a bulk verification tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with parameter descriptions. The description adds context on 'wait' behavior (default true, set false to get jobId) and implies email array is a list, but does not add new constraints beyond schema.

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 verifies a list of emails (bulk), using specific verbs and resource. It distinguishes from siblings like verify_email (single) and find_emails (search).

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 says 'Best for cleaning lead lists' and mentions polling with get_job for large lists. It implies use for bulk but does not explicitly exclude single email verification (use verify_email) or when not to use it.

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.

6 tool updatesv1.2.0Jul 28, 2026
- First observedfind_email
- First observedfind_emails
- First observedget_credits
- First observedget_job
- First observedverify_email
- First observedverify_emails

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.4/5.0

Scored 2026-07-28 04:21 across 6 tools

Disambiguation5/5

Each tool has a distinct purpose: single vs bulk operations for verify and find, plus a credits check and async job polling. No overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case: verify_email, verify_emails, find_email, find_emails, get_credits, get_job.

Tool Count5/5

6 tools is well-scoped for the domain, covering core operations (verify, find, credits, async) without being over- or underwhelming.

Completeness4/5

Covers all essential email verification and finding workflows, including async polling. Minor gap: no tool to cancel or list async jobs, but not critical.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

Anymail FinderOAuth
io.github.anymailfinder
Find verified work emails from a name, company, role or LinkedIn URL, and verify emails you have.
Email Search
1
Fiber AI A
ai.fiber
Search companies, enrich contacts, and reveal emails and phones from your AI agent.
Search Customer Data Platforms Marketing
52
Email Verification MCP A
io.github.FoundryNet
Verify emails — deliverability, disposable/role/free detection, MX validity, domain age.
Email Security
2
emailverifier.devOAuth
io.github.usamaejaz
Verify emails and domains for routing, disposable providers, role accounts, and SMTP risk.
Email Security
1

Related MCP Servers

Enrow MCP Serverofficial
CRM
EnrowAPI
A
license
A
quality
C
maintenance
Enables AI assistants to find and verify professional emails and phone numbers via the Enrow API.
Updated 2 months ago (2026-07-08 00:44 UTC)
13
1
MIT
GrowthToolkit MCP Server
CRM Customer Data Platforms
iamanantgupta
A
license
Not graded
quality
D
maintenance
Gives AI assistants the power to find verified emails, phone numbers, and rich contact data from 575M+ professionals across 30M+ companies via GrowthToolkit's API.
Updated 6 months ago (2026-04-01 10:51 UTC)
MIT
mcp-emailable
Email Communication Security
pipeworx-io
A
license
Not graded
quality
C
maintenance
Wraps the Emailable API for email verification, enabling AI agents to verify email addresses through natural language queries.
Updated 22 days ago (2026-08-26 17:03 UTC)
5 npm
MIT
Verifly MCP Server
Email Customer Data Platforms Security
james-sib
A
license
A
quality
D
maintenance
Enables AI agents to verify email addresses, clean lists, run bulk verification jobs, and manage a Verifly account through natural language, without writing HTTP calls.
Updated 2 months ago (2026-07-17 07:59 UTC)
15
4 npm
MIT

Verifox MCP Server

Quick start (published package)

Tools

Local development

3. Restart Claude Desktop

Remote (HTTP) mode

Usage Examples

Environment Variables

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Enrow MCP Serverofficial