Skip to main content
Glama

lob

by io.usefulapi

Verify a US address

lob_verify_us_address
Read-only

Validate & standardize a US address, returning deliverability, corrected components, and a confidence score. Pass either a single freeform address string OR structured primary_line/city/state/zip_code. Non-mutating (no mail sent). Lob API: POST /v1/us_verifications.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cityNo
stateNo2-letter state code, e.g. 'CA'.
addressNoFreeform single-line address (alternative to the structured fields).
zip_codeNo5-digit or ZIP+4.
primary_lineNoPrimary delivery line, e.g. '210 King Street'.
secondary_lineNoSecondary line, e.g. 'Suite 6100'.

TDQS

A4.2/5.0
Behavior4/5

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

Annotations provide readOnlyHint: true, and the description adds 'Non-mutating (no mail sent),' which aligns. It further discloses that the tool returns deliverability, corrected components, and a confidence score, and it mentions the API endpoint. This adds value beyond the annotations without contradicting them.

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

Conciseness5/5

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

The description is two sentences long, front-loading the purpose and outputs. Every sentence adds value: the first explains what the tool does and returns, and the second specifies input modes and side effects. No filler or repetition.

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?

Given no output schema and 6 parameters, the description explains what the tool returns and how to provide input. It covers the key behavioral aspects. However, it could briefly mention error scenarios or that the address must be US (though implied by the name). Overall, it is sufficiently complete for an AI agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 83%, with most parameters having descriptions. The description adds semantics by clarifying the two input modes (freeform vs. structured) and implying that one set can be used exclusively. This helps the agent understand the relationship between parameters beyond the schema's individual descriptions.

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 description clearly states the tool's purpose: 'Validate & standardize a US address, returning deliverability, corrected components, and a confidence score.' It specifies a specific verb ('validate & standardize'), a resource ('US address'), and distinct outputs. This differentiates it from siblings like lob_verify_intl_address and lob_us_autocomplete.

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?

The description explains how to use the tool: pass either a freeform address string or structured components. It also notes that the tool is non-mutating. However, it does not explicitly state when to use this tool versus siblings like lob_us_autocomplete or lob_us_zip_lookup, nor does it provide exclusions or prerequisites.

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

All lob toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation5/5

Every tool targets a distinct resource and action, with clear verb-noun names like create_address and verify_us_address. There is no overlapping functionality, and even similar operations (e.g., list for different resources) are distinct.

Naming Consistency5/5

All tools share the 'lob_' prefix and follow a consistent verb_noun pattern (e.g., create_postcard, list_letters, verify_intl_address). Multi-word nouns use underscores, maintaining uniformity throughout.

Tool Count5/5

With 18 tools, the set covers the primary mail fulfillment operations—address management, postcards, letters, checks, self-mailers, and address verification—without feeling bloated or sparse. The count is well-suited to the domain.

Completeness2/5

The tool set has notable gaps: no create_check or create_self_mailer, no cancel for letters or checks despite being referenced, no update/delete for addresses, and only list for templates. These missing operations will likely cause agent failures in common workflows.

Resources