PostAgent

Verify a postal address for deliverability (paid, flat fee)

verify_address

Idempotent

Standalone paid address verification — no mail is sent. Checks whether an address is deliverable and returns the standardized form (US: CASS with ZIP+4; international: per-country matching). Costs a small flat USDC fee per call via x402 (a fraction of a cent vs. mailing).

Two-step flow, like the mail rails: call WITHOUT paymentSignature to get the 402 challenge and paymentUrl (preferred: have the agent's x402 wallet pay paymentUrl in-band with the address as the JSON POST body {"address":{...}}); or sign the challenge and call again WITH paymentSignature to verify and get the result in one round trip. US addresses need line1 + (city+state or zip). International addresses need line1 + country.

Note: when mailing through PostAgent you do NOT need this tool — create_mail_quote already verifies sender and recipient for free as part of the quote.

Input Schema

TableJSON Schema

Name	Required	Description
`zip`	No	ZIP or postal code
`city`	No
`name`	No	Recipient/contact name (optional)
`line1`	Yes	Street address line 1
`line2`	No
`state`	No	State/province/region
`country`	No	2-letter ISO country code. Omit or 'US' for CASS-standardized US verification; any other code runs international verification.
`paymentSignature`	No	x402 PAYMENT-SIGNATURE header value signed against this endpoint's challenge. Omit to fetch the challenge first.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

First observedJun 17, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations indicate this is a paid, idempotent, non-destructive tool with open-world semantics. The description adds important behavioral context: the cost via x402, the two-step payment flow, and the standardized output format. It does not contradict annotations. However, it could briefly mention that the output includes deliverability status and standardized address fields, but overall it provides sufficient transparency.

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 well-structured with three concise paragraphs: overview and cost, two-step flow with requirements, and a crucial note about alternatives. Every sentence adds unique value. Despite moderate length, it is front-loaded with essential info and avoids redundancy.

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 8 parameters (1 required), 75% schema coverage, and no output schema, the description provides sufficient context for an agent to decide when and how to use the tool. It covers payment flow, address field requirements, and alternative usage. The only minor gap is the lack of explicit output structure (e.g., 'returns a JSON with deliverability status and standardized fields'), but the mention of 'standardized form' partially compensates.

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?

With 75% schema description coverage, the description adds significant meaning beyond the schema. It explains the purpose of 'paymentSignature' (omit to fetch challenge), the role of 'country' (omit or 'US' for US CASS verification), and required combinations (US: line1 + (city+state or zip); international: line1 + country). It also clarifies that 'name' is optional. This helps the agent understand parameter relationships.

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 explicitly states the tool's purpose: verifying address deliverability and returning standardized forms (CASS for US, per-country for international). It distinguishes itself from sibling tools by noting it's standalone and not needed when using create_mail_quote (which includes free verification). The verb 'verify' and resource 'address' are clearly linked.

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?

The description provides explicit guidance on when to use the tool (standalone paid verification) and when not to (for mailing via PostAgent, where create_mail_quote provides free verification). It also details the two-step flow with paymentSignature, offering clear instructions for both cases: calling without paymentSignature to get a challenge, or with paymentSignature to get results in one round trip.

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

All PostAgent tools Inspect

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

A4.5/5.0

Disambiguation5/5

Each tool targets a distinct function: updates, document upload (letter/template/postcard), quoting (single, campaign, postcard), payment (x402, MPP, card checkout, detached signature), and status tracking. There is minimal overlap; even the three quote tools (create_mail_quote, create_campaign_quote, create_postcard_quote) are clearly differentiated by recipient type and workflow.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_letter, get_campaign_status, submit_paid_mail_job). Verbs are descriptive and nouns clearly indicate the resource or action. There are no mixed conventions or vague names.

Tool Count5/5

14 tools is well-scoped for a mailing and payment server. Each tool serves a distinct step in the workflow (upload, quote, pay, verify, track) without redundancy. The count is neither too low (would miss essential operations) nor too high (would overwhelm).

Completeness4/5

The tool set covers the core lifecycle: document preparation, quoting, multiple payment rails, address verification, and status tracking. Minor gaps exist, such as no explicit tool to cancel a job or list previously created documents, but these are not critical for typical use and can be worked around.

Resources

Need Help?