APIVerve

Disposable Phone Number Checker

DisposablePhoneNumberChecker

Read-only

Disposable Phone Number Checker: Disposable Phone Number Checker is a phone fraud API that flags temporary, burner and virtual phone numbers published on SMS-receiving sites. Pass a number in E.164 format to check whether it is disposable and see the date it was first seen on those lists. (Cost: 6 credits)

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "phone": "<phone>"
    },
    "name": "DisposablePhoneNumberChecker"
  }
}

Input Schema

Name	Required	Description	Default
`phone`	Yes	The phone number to check, in E.164 format (e.g., +12085813945), or in national format together with country
`country`	No	Two-letter ISO country code for a number given in national format (e.g., GB for 07700 900123). Not needed for E.164 numbers

Output Schema

Name	Required	Description
`data`	No
`error`	No	Error message, null on success
`status`	No	"ok" on success

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 7, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Beyond the readOnly/openWorld annotations, the description discloses that results come from external list sources and include the date the number was first seen, and it discloses a concrete cost of 6 credits — context an agent cannot get from the annotations. It does not discuss list coverage limits or freshness beyond 'first seen', which keeps it just short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with purpose and ending with the cost signal, which is well placed. It loses a little to the redundant lead-in that repeats the tool name twice before saying anything new.

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?

With an output schema present, the description needn't describe return values, and it correctly focuses on scope, input format, and cost. For a low-complexity two-parameter lookup this is sufficient, with only source-coverage context left unstated.

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 description coverage is 100%, documenting both phone (E.164 or national) and country (ISO code for national format). The description restates only the E.164 path and adds no semantics about the country parameter or format fallbacks, so it sits at the baseline where the schema does the work.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource ('flags temporary, burner and virtual phone numbers') and scopes the data source to numbers 'published on SMS-receiving sites', which is far more precise than the title alone. It is distinguishable from neighbors like PhoneNumberValidator and DisposableEmailChecker, though it never names those siblings explicitly.

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 by 'Pass a number in E.164 format to check', and there is a light input-format constraint. There is no explicit statement of when to use this versus PhoneNumberValidator (format/validity checking) or when the result should not be trusted, and no prerequisites are given.

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

All APIVerve tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.