Every checkout, every delivery, every "where do I send this?" moment in commerce comes down to one stubborn field: the address. It looks trivial. It is anything but. The address is where digital intent meets the physical world — and it is the single most expensive, most error-prone field in the entire commerce stack. Now that AI agents are starting to place orders on our behalf, that weak field is about to break in a brand-new way.
This is the problem VayaCore MCP was built to solve. But before the solution, it's worth being honest about how bad the problem really is.
The address is the most expensive field in commerce
Start with the money. Last-mile delivery — the final hop from depot to doorstep — now absorbs 53% of total shipping costs, up from 41% in 2018. It is the most expensive leg of the journey, and it is the leg most likely to fail. Roughly 5% of deliveries fail on the first attempt, and of those failures, 22% trace back to inaccurate address information. A failed delivery isn't just a re-attempt; it's a support ticket, a refund risk, and a customer who may never come back.
The carriers make you pay for the privilege of being wrong. Address-correction surcharges from UPS and FedEx run $23.50 to $24 per package, and about 2.1% of all e-commerce parcels hit an address issue. For a mid-sized merchant shipping 15,000 orders a month, that's tens of thousands of dollars a year in correction fees alone — money spent fixing a field the customer already filled in.
The damage starts earlier than fulfillment, though. It starts at the form. The average documented cart-abandonment rate is 70.22%, and a meaningful slice of that is pure friction: 18% of shoppers abandon because the checkout is too long or too complicated. The average US checkout shows shoppers 23.48 form fields when 12 to 14 would do. The address block — street, unit, city, region, postal code, country — is the heaviest part of that form. Every field is a chance to mistype, mis-format, or give up.
Data-quality people have a name for this compounding cost: the 1-10-100 rule. It costs about a dollar to validate an address at the point of entry, ten dollars to fix it later in the pipeline, and a hundred dollars or more if it's never corrected and a package goes into the void. The cheapest place to get the address right is the first place. Almost nobody does.
For half the world, there is no address to validate
Here's the part the Western commerce stack quietly ignores: validation assumes there is something to validate. For a large share of the planet, there isn't.
Billions of people worldwide lack a formal street address — the Universal Postal Union has run an "Addressing the world" initiative for over a decade precisely because so much of the globe is unaddressed. In these markets, people navigate the way humans always have: by description. *The green house on the corner, behind the third shop, past the church.* No autocomplete API has a field for that.
We see it every day in our home market. Across Barbados and much of the Caribbean, homes have historically had no formal street address. It's not a fringe edge case — it's the default. And it's changing in a telling direction: Barbados has rolled out the Barbados Building Identifier (BBID), giving every building its own unique identifier, delivered door to door alongside updated postal codes. The future of addressing in these markets isn't a longer street name. It's a stable identifier per building — exactly the primitive that software can resolve.
That's the world AI agents are walking into: a commerce layer where the most expensive field is often missing entirely, and where the "fix" is an identifier, not a sentence.
Now hand that problem to an AI agent
It gets worse before it gets better. Take a field that's already fragile and hand it to a system that is confidently, fluently unreliable about geography.
Large language models are bad at addresses in a specific, dangerous way. When researchers at The GDELT Project tested LLM-based geocoders, they found models that "hallucinate, confidently asserting that cities were mentioned which are not even alluded to in the text," that change their answers run to run, and — most damning for our market — that "exhibit extreme Western bias … failing miserably at identifying more localized names less prevalent in the Western web." In other words, LLMs are weakest at exactly the addresses that need the most help.
This isn't a one-off finding. On MapEval, a benchmark for map-based reasoning with real APIs, the best foundation models "none surpass 67% accuracy," lagging "over 20% behind human performance," and they fail most on the practical stuff — nearby search and routing — by passing wrong or missing parameters to tools. An agent that's right about where your package goes two times out of three is not an agent you can ship.
And agents are already transacting. During the last holiday peak, $14.2 billion in global online sales were driven by generative AI and agents, with Adobe reporting a staggering 4,700% year-over-year jump in AI-driven visits to US retail sites. A wave of agentic-commerce protocols has shipped to handle the handshake — who the agent is, how it pays. But every one of them solves identity and payment. None of them solves where the box actually goes. That gap is left to the model's imagination, which we just established is the last place you want it.
But don't Google Places and what3words already solve this?
It's a fair question, and the honest answer is: they each solve one slice — for a human, in a well-addressed country, filling out a form.
Google's Places Autocomplete and Address Validation APIs are the default checkout stack, and they're good at what they do. But they're built around a person typing into a field. Autocomplete predicts from partial input; it doesn't prove that an address exists or that a courier can actually deliver to it. Validation runs one address at a time, coverage outside major Western markets is thin, and Google's terms restrict storing or caching the returned results — which fights directly against an agent that wants to resolve a delivery target once and reuse it.
what3words takes a different swing — a 3-metre grid with three words per square. But it hands you a *point*, not a delivery *identity*: no contact, no hours, no photo of the door, no confirmation step. It needs a smartphone, GPS, and connectivity at the point of use, and it's a closed, single-vendor system — the company has even sent legal threats to open-source clones. A point on a grid is not something an agent can confirm a human actually lives behind.
Traditional address-validation services — Smarty, Loqate, Precisely — standardize and enrich addresses well, but they're SDK-and-REST products aimed at form pipelines and bound to the regions they cover. None of them is exposed as a tool an agent can discover and call under a single namespace.
The pattern is consistent: every existing player optimizes the human-typing-into-a-form path in places that already have addresses. The agent-native path — resolve a stable, human-readable ID to a confirmed, photo-backed delivery target, in the markets where addresses are hardest — has simply been missing.
The missing primitive: a resolvable delivery identity, exposed as a tool
So what does an agent actually need? Not a better autocomplete. Not a cleverer prompt. It needs a deterministic, confirmable delivery target it can look up — the way it looks up a stock price or a weather forecast — instead of asking the user to type a street name into a chat window.
That's what a VayaPin is. A VayaPin is a short, human-readable identifier — something like BB:TAPAS887 — that resolves to the real thing: GPS coordinates, a structured address, contact details, delivery hours, drop-off instructions, even photos of the door. It's the digital equivalent of "the green house on the corner," except a machine can resolve it in a single call and a courier can act on it without a phone call.
Two shifts make this the right moment to expose that primitive to agents. The first is the identifier trend itself — BBID and systems like it mean the physical world is moving toward stable, building-level IDs that map cleanly to data. The second is the Model Context Protocol, the open standard Anthropic introduced in late 2024 and donated to the Agentic AI Foundation under the Linux Foundation in December 2025. MCP gives agents a universal way to discover and call tools. One server, and the same tools light up in Claude, Cursor, VS Code, n8n, and any other MCP client — no bespoke integration per app.
Put those together and the answer is obvious: ship the delivery primitive as an MCP server.
One install, eight tools, your own keys
That's VayaCore MCP — the @vayapin/mcp package. One install gives an agent eight tools across three families, under a single namespace.
Identity. resolve_pin turns a VayaPin into the full delivery payload. preview_pin suggests an available pin name for a new user, and confirm_pin reserves it and sends them a signup link over WhatsApp, SMS, or email — so the agent can onboard someone who *doesn't* have a VayaPin yet without ever asking them to type an address.
Maps. geocode, reverse_geocode, place_search, and place_details wrap the Google Maps Platform so the agent can turn text into coordinates, coordinates into addresses, and "near here" into real places.
Shipping. track_package normalizes tracking across 1,200+ carriers via AfterShip, with automatic carrier detection — so the agent can answer "where is my order?" without the developer wiring up a single courier API.
Two design decisions matter for anyone deploying agents at scale. First, the Maps and shipping tools are bring-your-own-key (BYOK): they call Google and AfterShip with *your* credentials, proxied server-side so the keys never touch the model. You keep control of your spend, your quotas, and your data — no vendor sitting between you and your own API bills. Second, the whole thing installs in one config block:
claude mcp add --transport stdio vayapin -- npx -y @vayapin/mcpAdd a VAYAPIN_PAT, drop a one-paragraph addressing instruction into your system prompt, and the agent stops guessing. When a customer needs to provide a delivery address, it resolves a real one instead of hallucinating, asking, or fumbling a Google API call with the wrong parameters.
Where this goes — agentic commerce that actually arrives
The agentic-commerce story so far has been about the front of the transaction: discovery, identity, payment. Those are being solved fast. But a purchase isn't finished when the card clears — it's finished when the package is in someone's hands. That last step has been quietly running on the weakest field in commerce, in a world where billions of people don't have the field at all, executed by models that are wrong about geography a third of the time.
VayaCore MCP closes that gap with the one thing agents were missing: a resolvable, confirmable, photo-backed delivery identity they can call like any other tool — plus the maps and shipping tools to act on it — in a single install that works everywhere MCP does. It's the location and logistics layer for agentic commerce, built first for the markets where addresses are hardest, because if it works there, it works anywhere.
The agents are already checking out. It's time they knew where the box goes.
Ready to build? Get started with VayaCore MCP →