
MobileValidate
com.mobilevalidatePublished by mobilevalidate.comOfficial publisherv1.2.0Updated Oct 24, 2026
Check phone numbers (WhatsApp, Telegram, carrier, spam reputation) and e-mail addresses.
Overview
Checks phone numbers and e-mail addresses for messaging-app registration, carrier details and spam reputation, with paid lookups and bulk jobs.
- What you can do
- Normalize and validate numbers locally in E.164 format, flagging ambiguous or duplicate inputs
- Estimate the cost and size of a lookup before spending anything, and list available services with prices
- Look up numbers and e-mail addresses in real time for services such as WhatsApp, Telegram, Viber, carrier, HLR, portability and spam
- Check spam reputation with risk levels, scores, reasons and sources
- Run bulk jobs of up to 50,000 numbers or addresses and page through their results
- Read account balance, reserved credit, daily usage and limits
- When to use it
- Useful when an assistant needs to verify contact data before outreach, screen sign-ups for disposable or risky numbers, or enrich a list with messaging-app registration and carrier information. Test keys let you try it without billing.
- Requirements
- Either the hosted endpoint with an Authorization bearer header, or the npm package run with npx on Node.js 20 or newer. A MobileValidate agent key (scoped, spend-capped) or a free test key is required; live keys are refused. Network access to the MobileValidate API.
Installation
In SourceWeft
- Open MobileValidate in the dashboard and add it to a workspace.
- Connect Authorization token credentials. They are stored privately and never shown on public pages.
- Enable the server for the chats that should use its tools.
Web executable via Streamable HTTP. Remote servers run from the web runtime once configured in a workspace.
Use with an agent
Paste this prompt into Claude Code, Codex, Cursor or another agent — or into SourceWeft chat. The agent reads this server's install guide, shows you its publisher, endpoint and sign-in, and adds it to your client once you agree. Keys never go into a command.
Read https://sourceweft.com/mcp/com.mobilevalidate%2Fmcp/install.md and connect the MCP server it describes to my client. Before changing any config, show me its publisher, endpoint and sign-in method and wait for my OK. Never put an API key in a command or in a file I would commit; ask me where it should come from.Other MCP clients
Add this to your client's mcpServers config.
{
"mcpServers": {
"mobilevalidate": {
"type": "http",
"url": "https://mcp.mobilevalidate.com/mcp",
"headers": {
"Authorization": "Bearer <YOUR_TOKEN>"
}
}
}
}README
@mobilevalidate/mcp
Model Context Protocol server for MobileValidate. It
lets AI agents (Claude Desktop, Claude Code, Cursor, VS Code and any other MCP client) check phone numbers — registration
on WhatsApp, Telegram, Viber, Signal and other platforms, carrier and line type, report-based spam reputation — and e-mail
addresses (mailbox exists; account on Gmail, Outlook, Apple and others; yes / no / unknown only, never names or
profiles). Several services can be checked in one call (checks); list_services shows what the key can use.
It is a thin client of the public MobileValidate API, built on the mobilevalidate
SDK. It holds no credentials of its own: your key is only forwarded to api.mobilevalidate.com.
Two ways to use it:
Both run the same tools with the same spend safeguards. Try either with a test key: the documented test values return fixed answers and nothing is billed.
Keys: an agent key (mv_agent_…, scoped, daily spend cap) or a test key (mv_test_…, free, never billed).
Live keys (mv_live_…) are refused by the MCP server on purpose. Get a personal test key at
https://mobilevalidate.com/get-test-key; agent keys come with an approved account.
Docs: https://mobilevalidate.com/docs/mcp
Quick start (hosted, test key)
Then ask: "Check +447700900001, +447700900002 and +447700900003 on WhatsApp." You get registered, not registered and unknown. Test keys never reach a real network and are never billed: the magic values below give fixed answers, and any other number gets a made-up but stable answer.
Just looking? The public sandbox key mv_test_publicSandboxn9ZgneuhR1B9CRfKG3fulym works too, but it answers only
the magic values below (anything else is refused with sandbox_magic_only), has low shared rate limits and cannot run
large jobs. Use your own test key for anything more.
Test e-mail addresses: [email protected], not-registered@…, unknown@… (same domain). Full list:
https://mobilevalidate.com/docs/test-values.
Client configuration
Claude Code
.mcp.json equivalent of the hosted setup:
Cursor (~/.cursor/mcp.json or .cursor/mcp.json)
Hosted (live):
Local stdio: { "mcpServers": { "mobilevalidate": { "command": "npx", "args": ["-y", "@mobilevalidate/mcp"], "env": { "MOBILEVALIDATE_API_KEY": "mv_agent_..." } } } }
VS Code (.vscode/mcp.json)
Claude Desktop (claude_desktop_config.json)
Claude Desktop connects to remote servers with a key through a stdio bridge such as the community
mcp-remote package (hosted server, live):
Local stdio:
Any other MCP client
- Streamable HTTP: URL
https://mcp.mobilevalidate.com/mcp, headerAuthorization: Bearer mv_agent_…. The server is stateless:POSTonly, JSON responses, no session id. - stdio: command
npx, args["-y", "@mobilevalidate/mcp"], envMOBILEVALIDATE_API_KEY=mv_agent_…. To pin a version use@mobilevalidate/[email protected]. Afternpm install -g @mobilevalidate/mcpthe command ismobilevalidate-mcp.
Protocol versions
Both transports speak MCP 2026-07-28 and the handshake-based revisions 2025-11-25, 2025-06-18, 2025-03-26, 2024-11-05 and 2024-10-07 (from 1.1.0; 1.0.x stopped at 2025-11-25). Nothing to configure: the client's opening message picks the revision.
- 2026-07-28: no
initialize; every request carries_meta(io.modelcontextprotocol/protocolVersion, client info and capabilities) and, over HTTP, theMCP-Protocol-Version,Mcp-MethodandMcp-Nameheaders (checked against the body; mismatch →400,-32020).server/discoverreturns the supported versions, capabilities, server identity and instructions.tools/listandserver/discovercarryttlMs: 3600000, cacheScope: "public"(the list is the same for every key), and tools come back in a fixed order. An unsupported version gets400withUnsupportedProtocolVersion(-32022) listing the supported ones. Tool calls return JSON (no SSE). - 2025-era clients:
initializeas before; the hosted server stays stateless (POSTonly, JSON responses, no session id;GET→405). On stdio the connection stays on the negotiated revision. - The server uses no server→client requests (sampling, elicitation, roots) and no protocol logging, so nothing
deprecated in 2026-07-28 is involved. Bulk jobs use an explicit
job_idhandle, the pattern the spec recommends now that sessions are gone. - The server card's
supportedProtocolVersionslists the same versions (newest first).
Tools
Every tool declares a title, annotations, inputSchema and outputSchema. Each one returns structuredContent
plus a one-line text summary. checks takes service codes or aliases (e.g. whatsapp, telegram, viber,
carrier, spam); its description lists the real-time and bulk-only codes known to this build (from the SDK's generated
catalog), and list_services gives the live list. Result items keep the v1 top-level fields (WhatsApp if requested,
otherwise the first service) and add a checks map per service when more than one service (or a non-WhatsApp service)
was requested. Tool descriptions state the anti-enumeration limits (≥ 20 consecutive numbers refused, daily caps).
E-mails. Phone services run on numbers, e-mail services on emails; send at least one check of each
kind you send. Result items carry kind (phone/email); e-mail items have email (normalized, null if invalid),
email_status (valid, invalid_email, duplicate, suppressed) and number_status: null. Descriptions state the
e-mail rules: ≥ 20 addresses on one domain differing only by digits are refused as enumeration, and answers are
yes/no/unknown only — no names, photos or profiles. Test keys use [email protected],
not-registered@…, unknown@… (same domain).
Spam reputation. check_spam_reputation (or checks: ["spam"] on the other tools) answers from spam and
nuisance-call reports: regulator actions, government complaint data, community reports and recently-unassigned numbers.
All countries except sanctioned ones (Cuba, Iran, North Korea, Syria, Russia, Belarus, Venezuela and sanctioned regions →
unsupported_country, free). no_reports means no reports are known — not that the
number is safe; it is still a conclusive, billed answer. Limits: ≤ 100 numbers per call, the same spend confirmation and
anti-enumeration rules as lookup_numbers. Test keys: +447700900001 high, …002 no_reports, …003 unknown, …004
pending then medium, …005 unsupported_country. Attribute values may be integers (risk_score, sources).
Network checks. checks: ["hlr"] returns live network status (status reachable / unreachable / invalid, ported,
roaming, mcc_mnc, country); checks: ["mnp"] returns number portability (porting ported / not_ported,
mcc_mnc, country). Unknown answers are free.
Spend safety
Before lookup_numbers, lookup_emails, check_spam_reputation or create_lookup_job spends anything, the server
calls the free estimate. Real-time tools quote the maximum at the key's real-time prices (from list_services),
create_lookup_job at bulk prices. The call is refused with a confirmation_required error result when either of
these is true:
- the maximum cost is above
MCP_CONFIRM_ABOVE_USD(default1.00), or - a job has more than 100 numbers and e-mails.
Scopes (agent keys): the real-time tools need lookup:write and jobs:write (the estimate is
POST /v1/jobs/estimate); estimate_cost and create_lookup_job need jobs:write; get_lookup_job needs jobs:read;
get_account needs account:read. list_services needs none.
The error text states the amount and tells the agent to ask the user. The agent then re-invokes the tool with
confirm_max_cost set to the amount shown. The confirmed (or estimated) amount is always sent to the API as
max_cost, so the API refuses any request that would cost more.
Limitation: this confirmation is agent-mediated. The server cannot prove that a human approved the amount.
The hard limits are the key's own spend cap and the max_cost guard. A human confirmation URL is planned.
Other rules:
- Only
mv_agent_…(scoped, spend-capped) andmv_test_…keys are accepted.mv_live_…keys are rejected with a clear message. - There is no
webhook_urlparameter, and request metadata is never echoed into tool output. - Logs go to stderr and contain counts and ids only. Anything that looks like a phone number or an e-mail address is masked.
Environment variables
Self-hosting the HTTP transport
POST /mcp only (stateless, JSON responses, 2026-07-28 and 2025-era clients on the same endpoint) and GET /healthz. Each request's Authorization: Bearer key is forwarded
to the API for that request only and never stored. Host must be 127.0.0.1:<port> or localhost:<port>, plus any
value in MCP_ALLOWED_HOSTS (DNS-rebinding protection) — set it when you put the server behind a reverse proxy, and
terminate TLS in front of it. Bodies are limited to 2 MB.
Security notes
- Use an agent key (
mv_agent_…) with a spend cap you are comfortable with; the key's cap and themax_costguard are the hard limits. Test keys are free. - Put the key in the client's
env/ header configuration, not in prompts. The server never logs keys; its stderr logs contain counts and ids only, and anything that looks like a phone number or e-mail address is masked. - Spending above
MCP_CONFIRM_ABOVE_USDrequires the agent to ask the user first (see Spend safety); this is agent-mediated, so keep the key's spend cap as the real limit. - Only check numbers and addresses the user has a legitimate relationship with. Enumeration patterns are refused and daily caps apply.
Maintainers
Source is TypeScript in src/ (run directly with tsx inside the monorepo: pnpm --filter @mobilevalidate/mcp start
for HTTP on 127.0.0.1:3300, start:stdio for stdio). The published package contains only the compiled dist/,
README.md, LICENSE and server.json; publishConfig swaps main / exports / bin from src/ to dist/ and
pnpm rewrites the workspace:* SDK dependency to the exact SDK version — so always pack with pnpm
(ops/publish-packages.sh), never plain npm pack / npm publish from this directory. The build compiles against the
SDK's dist/ types, so build the SDK first.
MCP SDK: the server uses the official v2 TypeScript SDK (@modelcontextprotocol/server, which implements 2026-07-28
with dual-era serving: createMcpHandler + isLegacyRequest for HTTP, serveStdio for stdio). The v1 package
@modelcontextprotocol/sdk and @modelcontextprotocol/client are dev dependencies only: the tests use them as a
real 2025-11-25 client and a real 2026-07-28 client (test/protocol.test.ts).
Release checklist: bump version in package.json, SERVER_VERSION in src/tools.ts and both version fields in
server.json (a test enforces they match). The SDK must be published first, because this package pins its exact
version.
MCP Registry. Listed as com.mobilevalidate/mcp (domain-verified namespace). server.json follows the registry
schema 2025-12-11; mcpName in package.json must equal its name (the registry checks it on npm).
License
MIT © 2026 MobileValidate LLC See LICENSE.
Source: mcp/README.md at commit 11cc74f
Tools
0Version history
3- v1.2.0LatestSep 27, 2026
- v1.1.0Sep 27, 2026
- v1.0.2Sep 26, 2026
Score
85% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 daysRequired25 pts
- Auth declaredRequired10 pts
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts