Phone Validation Grounding Data

Overview

A phone validation and phone number validator API that answers in JSON from one REST call, with a Free plan to test it before you pay. Send a number in +E.164 form on its own, or a national number with its two-letter country code. Validation runs on Google's libphonenumber numbering-plan data, so each number is checked against the real number ranges of its country rather than a generic pattern. Location, carrier and time zones come from libphonenumber's offline geocoding and carrier maps. The carrier is the operator the number range was first allocated to, so a ported number still shows its original network, and US and Canadian numbers carry no carrier data. The disposable flag checks the number against numbers published on temporary SMS-receiving sites.

Live Test Phone Validation Grounding Data Source →

The tool

Once your client is connected to the VerveContext server, this appears in its tool list as PhoneValidationGroundingData. It is read-only and open-world — it fetches and never mutates anything on your side — so most clients call it without asking you to confirm.

{
  "name": "PhoneValidationGroundingData",
  "arguments": {
    "number": "816-555-1017"
  }
}

You do not name the tool yourself; the model picks it. Asking about 816-555-1017 in the terms this source covers is enough for it to reach for PhoneValidationGroundingData on its own — naming it explicitly also works, and is the way to force the call.

Connecting

One server URL covers every source in the catalog, including this one. Authorization is OAuth: the client opens a browser once, and there is no key to paste into a config file.

{
  "mcpServers": {
    "vervecontext": {
      "url": "https://api.vervecontext.com/v1/mcp"
    }
  }
}

https://api.vervecontext.com/v1/mcp

Per-client setup — Claude, Cursor, VS Code, ChatGPT — is on the MCP setup page.

Arguments

These are the properties on the tool's inputSchema, so a well-behaved client validates them before the call is made. Premium arguments are accepted on every plan but only take effect on plans that include them.

What the model gets back

The result carries a structuredContent object matching the tool's declared outputSchema, so a client reads fields without parsing prose. status is "ok" and error is null on success; a null field means the value was not available for that input, not that the call failed.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

{
  "status": "ok",
  "error": null,
  "data": {
    "country": "US",
    "detectedCountry": "US",
    "countryName": "United States",
    "countrycode": 1,
    "numberNational": 8165551017,
    "extension": null,
    "isValid": true,
    "isMobile": true,
    "isVoip": false,
    "isDisposable": false,
    "type": "fixed_line_or_mobile",
    "isValidNumber": true,
    "nationalSignificantNumber": "8165551017",
    "location": "Missouri",
    "carrier": null,
    "timezones": [
      "America/Chicago"
    ],
    "formatted": {
      "international": "+1 816-555-1017",
      "national": "(816) 555-1017",
      "rfc": "tel:+1-816-555-1017",
      "e164": "+18165551017"
    },
    "riskScore": 0,
    "riskLevel": "low"
  }
}

Response fields

Paths are relative to data. Premium fields are absent rather than zeroed on plans that do not include them, so check for presence instead of comparing to 0.

Why ground on it

A model can produce something that looks like this answer from its training data, and be confidently out of date or simply wrong. This source returns the current value in a shape you can check, which is the difference between an answer you can cite and one you have to hedge.

Point an evaluation at detectedCountry: it is the field most worth pinning a claim to, and it is either present and current or absent — never plausibly invented.

Failure modes

Errors come back as tool errors carrying a sentence the model can act on, not a bare status code. Error handling covers the full list.

A call costs 10 credits each time the tool actually runs; a model that reasons about the tool without calling it costs nothing.

Use cases

Account Signup Verification

When users register, check validity and flag disposable or VoIP lines before sending one-time verification SMS codes.

CRM Lead Scrubbing

Sales platforms inspect incoming prospect numbers and standardize them into E.164 format to keep contact records clean and dialable.

Outbound SMS Routing

To prevent wasted spend on unroutable text messages, delivery systems verify that recipient numbers are mobile lines rather than landlines.

Checkout Risk Screening

Payment gateways identify virtual and disposable phone numbers during checkout to detect suspicious buyer profiles before processing charges.

Contact Time Windows

Contact centers read the returned time zone and area so calls and texts go out during the recipient's local business hours.

Other ways to use Phone Validation Grounding Data

Set up Phone Validation Grounding Data on VerveContext, or reach the same source a different way. Your VerveContext account and credits work on all of them — one key, one balance.

Related

More in Data Validation: