Skip to main content
Glama

ActionShip by Teapplix Demo

Validate Shipping Address

teapplix_validate_address
Read-only

Validate and normalize a US shipping address against a carrier's validation engine. Only US addresses (CountryCode=US) are supported — non-US addresses return an error. Branch on Status: "Validated Changed" → engine corrected one or more fields, diff Address vs. input and update the record; "Validated Not Changed" → address is already valid, no action needed; "Not Changed" → engine rejected the address, surface Message to the user. [DEMO]

Input Schema

NameRequiredDescriptionDefault
AddressYesUS address to validate. Supply at least Street, City, State, and ZipCode (or Street + ZipCode for ZIP-only normalization). Only US addresses (CountryCode=US) are supported.
ProviderNoAddress validation engine. FEDEX is the preferred provider (best quality) but requires a linked FedEx carrier account. TEAPPLIX is always available for every account (USPS-based) and serves as the universal fallback. UPS requires a linked UPS account. Use FEDEX when available, fall back to TEAPPLIX otherwise.TEAPPLIX

Output Schema

NameRequiredDescriptionDefault
StatusYesValidation result. Three known values: "Validated Changed" — address is valid but change is suggested; "Validated Not Changed" — address is valid no change needed; "Not Changed" — address is invalid impossible to fix.
AddressYesInput address, but if suggested change is given under Status="Validated Changed", certain fields in this object are modified based on carrier feedback.
MessageNoDetail message about address validation return.
ResidentialNoTrue for residential delivery, false for commercial. Populated when the validating carrier reports it.
DeliveryPointNoUSPS DPV postal-barcode delivery point digits, when available.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / Provider / description
      Previous value: -"Address validation engine. Defaults to TEAPPLIX (uses the account default, typically EasyPost). UPS and FEDEX route to that carrier's native validator — only specify these if the user explicitly requests carrier-specific validation and has that carrier account linked."New value: +"Address validation engine. FEDEX is the preferred provider (best quality) but requires a linked FedEx carrier account. TEAPPLIX is always available for every account (USPS-based) and serves as the universal fallback. UPS requires a linked UPS account. Use FEDEX when available, fall back to TEAPPLIX otherwise."
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description goes further by disclosing the failure mode (non-US input errors out) and, critically, the tri-state Status semantics including that 'Validated Changed' means the engine mutated fields and the caller must diff and update. That is behavior beyond the annotations and essential to correct consumption.

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?

Front-loaded with the core action and scope, then a compact status branch list; every sentence earns its place. The trailing '[DEMO]' marker is noise that slightly clutters an otherwise tight definition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-shape explanation is unnecessary; combined with annotations covering safety and a 100% documented schema, the description fills the remaining gaps (US-only restriction, status-driven next actions) completely for an agent to call and act on results.

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 both the nested Address fields and the Provider enum/fallback logic are already fully documented in structured data. The description only reinforces the CountryCode=US constraint, adding little beyond the schema — baseline 3.

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?

States a specific verb pair (validate and normalize) plus the precise resource (a US shipping address) and the engine it consults. It is the only address-validation tool among the siblings, and the description makes the US-only scope explicit so it can't be confused with rate, label, or order tools.

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

Usage Guidelines5/5

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

Gives explicit when-to-use conditions ('Only US addresses (CountryCode=US) are supported — non-US addresses return an error') and a full branch table telling the agent what action to take for each Status value. This is actionable routing guidance rather than a generic blurb.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources