Byteplant Validator MCP Server

Official

by byteplant-devops

Overview Schema Source Related Servers Discussions Admin

Python

Remote

Validate a postal address

validate_address

Read-only

Checks postal addresses for validity and deliverability, returns standardized components, and optionally provides coordinates.

Instructions

Validate and standardize a postal address and return its status, standardized address components, and optionally its coordinates.

Result fields:

status (string): VALID: address is correct and deliverable. SUSPECT: address is incorrect and needs corrections to be deliverable, a suggested correction is provided. INVALID: address is incorrect and not deliverable - either there is no match at all in the reference data or the address is ambiguous and there are a lot of different matches. In these cases automatic correction suggestions are not available. DELAYED, NO_COUNTRY, RATE_LIMIT_EXCEEDED, API_KEY_INVALID_OR_DEPLETED, RESTRICTED, INTERNAL_ERROR
formattedaddress (string): full address in standardized format
supplement (string): additional address details (building / unit / apt / suite etc.)
street (string): street address in standardized format
streetnumber (string): street number in standardized format
postalcode (string): zip / postal code in standardized format
city (string): city in standardized format
type (string): address type: S = Street address | P = P.O. Box, Pick-Up or other delivery service
rdi (string): Residential Delivery Indicator (Commercial / Residential)
district (string): district in standardized format
county (string): county in standardized format
state (string): state / province in standardized format
country (string): two-letter ISO 3166-1 country code
latitude (number): latitude (for valid addresses if Geocoding is enabled)
longitude (number): longitude (for valid addresses if Geocoding is enabled)
diagnostics (string): detailed diagnostic hints, indicating errors in the address input
corrections (string): detailed correction hints, indicating which parts of the address input have been fixed
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

Name	Required	Description	Default
`city`	No
`code`	Yes	Two-letter ISO 3166-1 country code, 'XX' for international
`state`	No
`locale`	No	Output language for countries with multiple postal languages, as an IETF language tag. Use only to translate addresses; always leave empty for address validation
`charset`	No	Output character set: 'utf-8' or 'us-ascii'	utf-8
`timeout`	No	Timeout in seconds (min 5, max 300, default 10)
`geocoding`	No	Return latitude and longitude for valid addresses
`street_adr`	Yes	Street, house number and building, may include unit/apt etc. May also contain the complete address (leave the other optional fields empty then). Always use ',' to separate address elements where required
`street_num`	No	House number/building, if it isn't part of street_adr
`postal_code`	No
`additional_info`	No	Building/unit/apt/floor etc.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.1.0Oct 4, 2026

TDQS

A4/5.0

Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint, but the description discloses the full failure surface: DELAYED, NO_COUNTRY, RATE_LIMIT_EXCEEDED, API_KEY_INVALID_OR_DEPLETED, RESTRICTED, INTERNAL_ERROR, and concrete rate-limit numbers (100 requests / 300s, with remaining count and seconds). It also explains that corrections are unavailable for INVALID/ambiguous input, which is meaningful operational context an agent needs to handle responses.

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 opening sentence is well front-loaded, but the bulk of the text is a field-by-field enumeration of return values, which is redundant because an output schema already exists. The status-code semantics are worth keeping; the remaining per-field listing does not earn its space.

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 is not obliged to explain return values, and it still adds useful status semantics and rate-limit behavior. The main gap is the absence of any input-parameter guidance for a tool with 11 parameters, but the schema covers most of them.

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 73%, which is close to the high-coverage band where the schema does the heavy lifting, and the description adds nothing about input parameters at all. Notably it does not compensate for the undocumented city, state and postal_code fields, so it lands at the baseline rather than above it.

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

Purpose5/5

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

The first sentence states a specific verb+resource ('validate and standardize a postal address') plus the return shape (status, standardized components, optional coordinates). Against siblings validate_email and validate_phone the resource alone is unambiguous, so an agent can route correctly without opening the schema.

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?

There is no explicit when-to-use or when-not sentence; usage is only implied by the name and by the note that coordinates are returned only 'for valid addresses if Geocoding is enabled'. The geocoding conditional is the closest thing to a usage rule, so the score sits at implied-usage level rather than clear guidance.

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

Deploy Server