Skip to main content
Glama

PostAgent

by tech.interpretai

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
NameRequiredDescriptionDefault
zipNoZIP or postal code
cityNo
nameNoRecipient/contact name (optional)
line1YesStreet address line 1
line2No
stateNoState/province/region
countryNo2-letter ISO country code. Omit or 'US' for CASS-standardized US verification; any other code runs international verification.
paymentSignatureNox402 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.

  1. First observed

TDQS

A5/5.0
Behavior5/5

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

The description discloses the paid nature, the two-step x402 flow, the exact return format (CASS+ZIP4 for US, per-country for international), and required fields depending on address type. Annotations are consistent (readOnlyHint=false, idempotentHint=true, destructiveHint=false) and the description adds significant context without contradiction.

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 and front-loaded: first sentence captures the core purpose, followed by cost, flow, field requirements, and a clear exclusion note. Every sentence adds value, with no redundancy or filler.

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?

Given the complexity (8 parameters, payment flow, no output schema), the description is complete: it covers the process, payment mechanism, address requirements, and relationship to sibling tools. An agent can correctly invoke the tool without additional context.

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

Parameters5/5

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

The description adds meaning beyond the input schema by explaining the two-step payment flow, the role of paymentSignature, the country code semantics (US vs international), and required fields (line1 + city/state/zip for US, line1 + country for international). Schema coverage is 75%, but the description compensates fully.

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: verifying a postal address for deliverability and returning standardized form. It distinguishes itself from create_mail_quote, which already verifies addresses for free, making the use case clear.

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 explicitly tells when to use this tool (standalone verification) and when not to (if mailing through PostAgent, use create_mail_quote instead). It also provides step-by-step guidance on the two-flow process with paymentSignature.

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

All PostAgent 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

A4.4/5.0
Disambiguation4/5

Most tools have clearly distinct purposes: separate quote tools for campaigns, letters, and postcards; distinct payment paths; and no overlapping fundamental operations. The only slight ambiguity is between prepare_mail_payment and submit_paid_mail_job, but descriptions clarify different flows.

Naming Consistency5/5

All tool names strictly follow a verb_noun pattern in snake_case, e.g., create_letter, get_mail_job_status, pay_mail_with_shared_payment_token. The convention is uniform across all 13 tools, making them predictable and easy to navigate.

Tool Count5/5

13 tools are well-scoped for a mailing service: content creation (3), quoting (3), payment (4), status checking (2), and address verification (1). No unnecessary duplication, and the count is typical for a focused MCP server.

Completeness4/5

The core workflow (create content, get quotes, pay, track) is fully covered. Minor gaps exist: no tools for listing or deleting uploaded documents/templates, and no batch job status endpoint for individual mail jobs. However, these are not critical dead-ends for the primary use case.

Resources