Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@billionverify-mcp verify email john@example.com"
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.
Connect any AI assistant to BillionVerify email verification via the Model Context Protocol. Built with the official MCP TypeScript SDK.
Use BillionVerify's hosted MCP server at https://mcp.billionverify.com/mcp. No setup required — just add your API key.
Get your API key from the BillionVerify Dashboard.
Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"billionverify": {
"command": "curl",
"args": ["--stdio", "https://mcp.billionverify.com/mcp?api_key=YOUR_API_KEY"]
}
}
}claude mcp add billionverify -- curl --stdio "https://mcp.billionverify.com/mcp?api_key=YOUR_API_KEY"Go to Settings → MCP and add the same JSON configuration as Claude Desktop above.
Related MCP server: @sendbyte/mcp
Run your own MCP server using this TypeScript implementation.
Node.js 18+
BILLIONVERIFY_API_KEY=your_api_key npx billionverify-mcp{
"mcpServers": {
"billionverify": {
"command": "npx",
"args": ["-y", "billionverify-mcp"],
"env": {
"BILLIONVERIFY_API_KEY": "your_api_key_here"
}
}
}
}npm install -g billionverify-mcp
billionverify-mcpgit clone https://github.com/BillionVerify/billionverify-mcp.git
cd billionverify-mcp
npm install
npm run build
npm startVariable | Description | Default |
| Your BillionVerify API key | — |
| API base URL override |
|
Tool | Description |
| Verify a single email address in real-time |
| Verify up to 50 emails in one request |
| Check your credit balance |
| Poll the status of an async file verification job |
| Get download URL for results with status filters |
| Subscribe to file completion events |
| List all configured webhooks |
| Remove a webhook |
| Check server health |
MIT
Create a webhook to receive file verification completion notifications
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | HTTPS URL to receive webhook events | |
| events | Yes | Events to subscribe to | |
| api_key | No | BillionVerify API key (optional if BILLIONVERIFY_API_KEY env is set) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should disclose behavioral traits. It only states 'Create a webhook' without mentioning duplication handling, required permissions, or any side effects of creation.
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, short sentence that is concise and front-loaded. It could be slightly more informative but does not waste 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?
Given the moderate complexity (3 parameters, no output schema), the description is adequate but lacks context on error states, idempotency, or how to use the tool effectively.
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 100%, so the schema already documents all three parameters. The description adds no extra meaning beyond what the schema provides, meeting the baseline.
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 creates a webhook for file verification completion notifications. It uses a specific verb and resource, and distinguishes from siblings like delete_webhook or list_webhooks.
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 on when to use this tool vs alternatives, such as when to create a webhook versus get_task_status for polling. No prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a webhook by ID
| Name | Required | Description | Default |
|---|---|---|---|
| webhook_id | Yes | The webhook ID to delete | |
| api_key | No | BillionVerify API key (optional if BILLIONVERIFY_API_KEY env is set) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description fails to disclose whether deletion is permanent, required permissions, or any side effects. It only states the basic action without behavioral depth.
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?
Single sentence, front-loaded with verb and resource, no extraneous words. Concise but lacks some detail.
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?
Adequate for a simple deletion tool with well-documented parameters, but misses contextual notes like permanence or that the webhook ID should come from list_webhooks.
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 coverage is 100% with clear parameter descriptions, so baseline is 3. The tool description adds no extra meaning beyond the schema.
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 action (delete) and resource (webhook) with identifier (by ID), differentiating it well from sibling tools like create_webhook and list_webhooks.
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 about when to use this tool, prerequisites (e.g., webhook must exist), or alternatives. The description lacks any context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current credit balance for your BillionVerify account
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | BillionVerify API key (optional if BILLIONVERIFY_API_KEY env is set) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It correctly indicates a read-only operation ('Get'), but fails to disclose any behavioral traits such as rate limits, authentication requirements beyond the optional api_key, or side effects.
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, efficient sentence that conveys the tool's purpose without unnecessary words. It is front-loaded and easy to parse.
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 absence of an output schema, the description should ideally note what format the credit balance is returned in (e.g., numeric value, currency). The tool is simple, but the lack of return value information leaves a gap.
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 100% for the single parameter (api_key). The description does not add additional meaning beyond what the schema already provides, resulting in a baseline score.
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 specific action ('Get') and resource ('current credit balance for your BillionVerify account'), distinguishing it from sibling tools like verify emails or webhook management.
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 explicit guidance on when to use this tool versus alternatives is provided. The context is simple enough that usage may be implied, but the absence of conditions or exclusions prevents a higher score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the download URL for file verification results with optional status filters
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | The job ID of the completed file verification | |
| api_key | No | BillionVerify API key (optional if BILLIONVERIFY_API_KEY env is set) | |
| valid | No | Include valid emails | |
| invalid | No | Include invalid emails | |
| catchall | No | Include catch-all emails | |
| role | No | Include role-based emails | |
| disposable | No | Include disposable emails | |
| unknown | No | Include unknown emails |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions optional filters but does not disclose that the job must be completed, auth requirements beyond the api_key parameter, or what the download URL behavior is (e.g., direct download, temporary link).
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?
A single, front-loaded sentence with no redundant information. Every word contributes to the purpose.
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?
Despite 100% schema coverage, the description lacks context about when to call the tool (post-job), what the return value contains (just a URL or data?), and how the status filters alter the URL. No output schema or annotations exacerbate the gap.
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 coverage is 100% with descriptions for all parameters. The description adds 'optional status filters' but does not explain how the filters combine or the meaning of the download URL. Baseline 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 retrieves a download URL for file verification results, using a specific verb and resource. It distinguishes from sibling tools like verify_batch_emails and get_task_status, which have different purposes.
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. It does not mention prerequisites like job completion or contrast with get_task_status for checking status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the status and progress of an async file verification job
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | The job/task ID returned from a file upload | |
| api_key | No | BillionVerify API key (optional if BILLIONVERIFY_API_KEY env is set) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It adds the 'async' context hinting at non-immediate completion, but does not disclose potential side effects, authentication requirements, or error scenarios.
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 of 10 words, front-loading the purpose without wasted words. Slightly more structure could improve readability but it is concise.
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?
With no output schema, the description should indicate the return value. It mentions 'status and progress' but does not specify fields or format, leaving agents underinformed about what to expect.
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?
Both parameters have full descriptions in the input schema, so the description adds no extra meaning beyond that. Baseline 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 verb 'Get', the resource 'status and progress', and the context 'async file verification job'. It effectively distinguishes from sibling tools like verify_single_email which initiate verification.
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 that the tool is used after a file upload to check job progress, but it does not explicitly state when to use it versus alternatives or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the BillionVerify MCP server health status
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, placing full burden on description. It only states the purpose without disclosing what constitutes health, possible responses (e.g., status codes, message), or behavior under failure. Minimal behavioral 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?
A single sentence that is front-loaded with the verb and resource. No unnecessary words; every word earns its place.
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 (0 params, no output schema), the description is largely sufficient. However, it could mention what the response contains (e.g., status, timestamp) for better completeness.
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 0 parameters and schema description coverage is 100%. Baseline for 0 params is 4. The description adds no parameter-specific info but none 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 action ('check') and the resource ('BillionVerify MCP server health status'). It distinguishes this tool from all siblings which perform other operations like webhook management or email verification.
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 for verifying server availability but provides no explicit guidance on when to use (e.g., before other calls) or when not. No alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all webhooks for your BillionVerify account
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | BillionVerify API key (optional if BILLIONVERIFY_API_KEY env is set) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as rate limits, authentication requirements beyond 'account', or whether the list is paginated. The tool is read-only, but the description does not explicitly state this.
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, concise sentence with no unnecessary words. It efficiently conveys the tool's purpose.
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 low complexity (one optional parameter, no output schema), the description is fairly complete. It could be improved by mentioning that it returns all webhooks (if no pagination) or the response format, but overall it suffices.
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 coverage is 100% with one parameter (api_key) described in the schema. The description adds no additional meaning beyond what the schema provides, so a 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 'List all webhooks for your BillionVerify account', using a specific verb (list) and resource (webhooks). It distinguishes itself from sibling tools like create_webhook and delete_webhook.
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 on when to use this tool versus alternatives. It does not specify that it retrieves all webhooks with no filtering capabilities, nor does it mention any prerequisites or alternatives like create_webhook.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify multiple email addresses (up to 50)
| Name | Required | Description | Default |
|---|---|---|---|
| emails | Yes | List of email addresses to verify (max 50) | |
| api_key | No | BillionVerify API key (optional if BILLIONVERIFY_API_KEY env is set) | |
| check_smtp | No | Perform SMTP verification |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not explain what 'verify' entails (e.g., format only, domain, SMTP), nor does it mention costs, rate limits, or error behavior.
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 with no wasted words, efficiently conveying the core function and batch limit.
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?
Despite low complexity (3 parameters), the description lacks information about output format, verification depth, and error handling, making it incomplete for effective use.
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 100%, so baseline is 3. The description adds no extra meaning beyond the schema's parameter descriptions.
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 it verifies multiple email addresses and includes a batch size limit of 50. However, it does not differentiate from its sibling tool 'verify_single_email'.
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 on when to use batch vs single verification, or any prerequisites or limitations beyond the batch size.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a single email address
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The email address to verify | ||
| api_key | No | BillionVerify API key (optional if BILLIONVERIFY_API_KEY env is set) | |
| check_smtp | No | Perform SMTP verification | |
| force_refresh | No | Bypass cache and force fresh verification |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description lacks behavioral details such as network calls, caching, rate limits, or what verification entails (e.g., SMTP check hinted in schema but not explained).
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?
Single sentence, no wasted words. Could benefit from slightly more detail but remains efficient.
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, no annotations, and description omits return format, error handling, or async behavior. Incomplete for a tool with 4 parameters.
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 100%, so baseline 3. Description adds no extra parameter meaning beyond schema.
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?
Description clearly states it verifies a single email address, distinguishing it from sibling verify_batch_emails. Specific verb and resource.
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 on when to use this tool vs alternatives like verify_batch_emails. Does not mention prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0create_webhookdelete_webhookget_account_balanceget_download_urlget_task_statushealth_checklist_webhooksverify_batch_emailsverify_single_emailEach tool has a clearly distinct purpose: email verification (single/batch), webhook management (create, delete, list), account balance, result download, task status, and health check. The only potential overlap is between verify_single_email and verify_batch_emails, but they are differentiated by the number of emails, making them unambiguous.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_webhook, get_account_balance). There are no deviations or mixed conventions, ensuring predictability.
With 9 tools, the server is well-scoped for its purpose: email verification plus supporting account and webhook management. The count is neither too few nor excessive, covering essential operations without redundancy.
The tool set covers core CRUD for webhooks, single and batch verification, result retrieval (via download URL and status), and account balance. Minor gaps include the absence of a webhook update tool and a way to cancel a verification job, but these are not critical for typical workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Email verification for AI agents — verify, clean & validate emails; self-onboard + crypto pay
Verified, pay-per-use API tools for AI agents through one authenticated connection.
Provide AI agents and automation tools with contextual access to blockchain data including balance…
Connects AI assistants to CloudQuell multi-cloud and AI cost, savings, anomaly, and budget data.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/BillionVerify/billionverify-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
