Skip to main content
Glama
byteplant-devops

Byteplant Validator MCP Server

Official
by byteplant-devops
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Validate a phone number

validate_phone
Read-only

Validate a phone number to verify its status, line type, carrier, location, and national/international formats for accurate contact data.

Instructions

Validate a phone number and return its status, line type, carrier codes, location and national/international formats.

Result fields:

  • status (string): VALID_CONFIRMED, VALID_UNCONFIRMED, INVALID, DELAYED, RATE_LIMIT_EXCEEDED, API_KEY_INVALID_OR_DEPLETED

  • linetype (string): FIXED_LINE, MOBILE, VOIP, TOLL_FREE, PREMIUM_RATE, SHARED_COST, PERSONAL_NUMBER, PAGER, UAN, VOICEMAIL

  • location (string): geographical location (city, county, state)

  • countrycode (string): two letter ISO 3166-1 country code

  • formatnational (string): phone number in national format

  • formatinternational (string): phone number in international format

  • mcc (string): mobile country code to identify a mobile network operator (carrier) using the GSM (including GSM-R), UMTS, and LTE networks

  • mnc (string): mobile network code to identify a mobile network operator (carrier) using the GSM (including GSM-R), UMTS, and LTE networks

  • ratelimit_remain (int): number of API requests remaining before the API rate limit is reached (the default API rate limit allows 100 API requests in 300s)

  • ratelimit_seconds (int): number of seconds remaining in the current rate limit interval

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeNoTwo letter ISO 3166-1 country code. Required for numbers in national format; leave empty if the number starts with '+'
modeNo'extensive' (full validation) or 'express' (static checks only, faster)extensive
phoneYesPhone number to validate, in national format or international format with a leading '+'
localeNoIETF language tag for geocoding resultsen-US
timeoutNoTimeout in seconds (min 5, max 300)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

B3.4/5.0
Behavior4/5

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

Annotations declare readOnlyHint=true and openWorldHint=true, so safety is already covered, and the description adds genuinely useful behavior: enumerated status outcomes (RATE_LIMIT_EXCEEDED, API_KEY_INVALID_OR_DEPLETED, DELAYED) and explicit rate-limit semantics (100 requests per 300s). This tells the agent what failure and throttling look like, which the annotations do not.

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

Conciseness3/5

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

The lead sentence is front-loaded and efficient, but the bulk of the text enumerates result fields that duplicate the existing output schema. That enumeration is largely redundant and crowds out more valuable guidance such as when to use express vs extensive.

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 need not re-explain return values, and it covers the core purpose plus rate-limit behavior. The main gap is the absence of usage guidance for mode selection and country-code handling, but the tool is otherwise callable as described.

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%, so the schema already documents phone, code, mode, locale, and timeout. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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?

States a specific verb ('validate') and resource ('phone number') plus the returned data categories, so an agent can immediately distinguish it from validate_email and validate_address by resource. It does not explicitly name siblings, but the resource is unambiguous.

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

Usage Guidelines2/5

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

The description gives no when-to-use guidance, no prerequisites, and no exclusions. It never explains the tradeoff between the extensive and express modes that the schema exposes, nor when a country code is needed beyond what the schema already says.

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

Deploy Server

Other Tools