DEV Community: WebAZ

Locale Is Not Currency: A Small AI Shopping Bug Exposed a Bigger Commerce Contract

WebAZ — Fri, 11 Sep 2026 15:50:14 +0000

I asked Grok to use WebAZ to find folding bicycles for delivery to Singapore.

The useful part worked: the AI called a read-only shopping tool, found real listings, and rendered product cards with product images, seller information, delivery estimates, return terms, and prices denominated in USDC.

Then the interface exposed a small but important problem.

The conversation was in Chinese. The shipping destination was Singapore. The underlying listing price was in USDC. Grok's prose converted the price to SGD, but the first product card showed an approximate CNY value. After more explicit Singapore context, a later card showed SGD.

No purchase was made, and the USDC listing price did not change. This was a presentation inconsistency, not a settlement error. But it revealed a larger design problem for AI commerce:

Language, location, price currency, and display currency are four different facts.

If an agent or host silently collapses them into one locale guess, the result can look polished while saying two different things about the same offer.

The Four Fields That Should Never Be Conflated

An AI shopping request can contain at least four independent dimensions:

Interface language: the language used to explain the result.
Shipping destination: the place used to evaluate delivery availability, ETA, taxes, and logistics.
Listing or settlement currency: the currency in which the seller states the price or the transaction is committed.
Reference display currency: an optional conversion shown only to help the buyer understand the amount.

A Chinese-speaking buyer in Singapore may want Chinese explanations, delivery to Singapore, a USDC-denominated offer, and an SGD reference price. None of those choices implies the others.

This matters even before checkout. A buyer comparing two cards may treat the largest number as the price that will be charged. If one surface shows CNY and the narrative shows SGD, the system has created avoidable ambiguity at the point where the user is deciding whether to continue.

What the Tool Contract Should Say

The display currency should be explicit input, not an undocumented inference:

{
  "query": "folding bicycle",
  "ship_to": "SG",
  "display_currency": "SGD",
  "language": "zh-CN",
  "limit": 6
}

The result should preserve the authoritative amount separately from any reference conversion:

{
  "price": {
    "amount": "554.14",
    "currency": "USDC"
  },
  "reference_price": {
    "amount": "700.93",
    "currency": "SGD",
    "is_estimate": true,
    "rate_observed_at": "2026-09-10T13:00:00Z"
  },
  "shipping": {
    "destination": "SG",
    "delivered_total": null
  },
  "warnings": [
    "Shipping cost is not included",
    "Reference conversion is not the settlement amount"
  ]
}

Three properties are doing most of the safety work here:

The original price remains intact.
The conversion is visibly marked as an estimate with a timestamp.
An unknown delivered total stays null instead of being guessed.

The host may still decide how to render the card, but the data contract gives it fewer opportunities to invent meaning.

Search, Presentation, and Commitment Are Different States

The experiment also reinforced a boundary we use throughout WebAZ:

Search discovers candidate offers.
Presentation helps a human compare known facts and visible unknowns.
Commitment must bind the exact seller, product or variant, amount, currency, terms, and approval.

A reference conversion belongs to presentation. It must never silently replace the amount being approved or paid.

This distinction becomes more important as AI clients move from answering questions to taking actions. A fluent answer is not a transaction receipt. A product card is not proof of inventory reservation. A starting price is not necessarily the price of the pictured variant. And a converted number is not the settlement currency unless the transaction contract says so.

Try the Read-Only WebAZ Experiment

WebAZ exposes a dedicated public Grok connector for reviewed-product search:

https://webaz.xyz/mcp/grok-search-v1

It requires no WebAZ account and exposes exactly one read-only tool: webaz_search.

One useful test prompt is:

Use WebAZ to find folding bicycles for delivery to Singapore.
Show the original listed price and an SGD reference price.
Mark missing shipping costs, taxes, or unclear variants.
Do not place an order or pay.

When reviewing the result, ask four questions:

Does the card preserve the original currency?
Does the reference conversion name its currency and remain clearly approximate?
Does changing the conversation language alter the displayed money unit?
Are missing freight, tax, inventory, or variant facts shown as unknown?

WebAZ's public-search surface is intentionally narrow. It is designed to make the first experiment easy to inspect without exposing account tools or payment actions. Compatible hosts can render product cards; structured and text results remain the fallback, and the host controls the final presentation.

Why Publish the Imperfect Test?

Because agent commerce will not become trustworthy through perfect screenshots alone.

It will become trustworthy when builders publish the exact request, distinguish observed behavior from intended behavior, preserve authoritative values, and turn mismatches into explicit contracts and regression tests.

The currency selector is now a concrete product-design item for WebAZ rather than a vague localization concern. The deeper lesson applies to every shopping agent: never let locale inference decide what the user thinks they are paying.

You can inspect the current WebAZ Remote MCP guide or browse the public product surface. If you run the experiment in another AI client, the most useful report is not simply "worked" or "failed." Record the client, prompt, shipping destination, original currency, displayed currency, and which facts remained unknown.

That is the evidence needed to make AI commerce less magical and more dependable.

Before Your Shopping Agent Compares Prices, Test What One Unit Means

WebAZ — Mon, 07 Sep 2026 01:54:43 +0000

I work on WebAZ. This morning I ran a small, read-only test against our public shopping tool: search for tissue products available to Singapore, sorted by listed price.

The useful result was not a flashy recommendation. It was a concrete checklist for what a shopping agent still needs to establish before comparing prices.

The actual test

One anonymous webaz_search call, on September 7, 2026:

{
  "query": "tissue",
  "ship_to": "Singapore",
  "sort": "price_asc",
  "limit": 3
}

The tool returned three results from six matches. Singapore was resolved to SG.

Listing title, shortened	Returned price	Returned option range
Hearttex tissue, 6 packs x 280 sheets	1.69 USDC	1.69-21.56 USDC; 3 options
Haoshi tissue, 10 packs x 344 sheets	1.96 USDC	1.96-6.75 USDC; 2 options
Under-cabinet tissue and lid organizer	2.15 USDC	2.15-3.26 USDC; 4 options

These are a dated catalog snapshot, not checkout quotes. The result also included listed handling time and return windows. I did not select an option, reserve stock or purchase anything.

Three assertions worth testing

1. Same words do not imply the same buying intent.

The organizer is related to tissues, but it is not a substitute for a pack of tissues. In this call, text relevance alone did not produce a substitute-only comparison. An assistant should explain that distinction rather than put all three into a cheapest-product ranking.

2. A listing title does not prove which option the starting price buys.

The response exposed multiple options and a price range. This search result alone did not establish that 1.69 USDC buys the six-pack named in the title. Dividing 1.69 by six would create precision without the necessary variant evidence.

Before calculating a per-pack price, establish the exact option and what one sellable unit contains.

3. Listed price is not delivered cost.

Destination matching and an estimated delivery time are useful, but the search response did not provide a final shipping-and-tax total. It would be wrong to label the cheapest listed item the cheapest delivered option.

A reusable review fixture

This is a proposed manual test format, not a WebAZ API schema:

{
  "buyer_intent": "facial tissues, not a holder",
  "destination": "SG",
  "checks": {
    "substitute_not_accessory": "review",
    "selected_variant_identified": "unknown",
    "units_in_selected_variant": "unknown",
    "price_for_selected_variant": "unknown",
    "shipping_and_tax_total": "unknown"
  },
  "next_step": "confirm the variant and total before ranking by unit cost"
}

For merchants, this identifies the facts an AI needs before it can represent an offer clearly. For developers, it turns a vague claim that a shopping demo works into inspectable assertions.

This test checks one public tool response. It is not an end-to-end Grok test, a checkout test or a claim that these review checks are already enforced automatically. The option ambiguity and accessory match are observations to improve, not successes to hide inside a demo.

Try it with one real product

I am starting a small, free product-clarity review through WebAZ, capped at three cases in the first round. Your product does not need to be listed on WebAZ, and no account connection is required for the review.

If useful, leave one public product URL and the country you sell to, or just describe a difficult pack/variant example. I will map what is clear, what is missing, and what an agent must not assume. Please do not post customer data, credentials or order details. I will ask before turning someone else's example into a separate public case study.

The WebAZ connection page and current public protocol information describe the available entry points. Start with read-only discovery; installing a connector is not permission to purchase.

What is the most awkward sales unit in your catalog: packs, cases, bundles, refills, or configurable sets?

Your MCP Server Needs a Machine-Readable "No"

WebAZ — Wed, 02 Sep 2026 16:36:01 +0000

Most Agent integrations explain what an AI is allowed to do.

They publish a tool list, an OpenAPI document, or an MCP schema. The Agent sees actions such as search, create_order, send_message, or refund and plans from there.

That is only half of the contract.

A production Agent also needs to know what it cannot do, what it must not do, which limits apply, and which actions remain human-gated even when the Agent has broad credentials.

In other words, an Agent interface needs a machine-readable negative space.

Missing tools are not a complete boundary

Suppose an anonymous shopping MCP exposes only one tool: product search.

A careful client may infer that it cannot place an order. But several questions remain:

Is ordering unavailable on this surface, or merely undocumented?
Can the Agent obtain a broader tool set after authentication?
Which write scopes would be required?
Is a proposed order reversible preparation or a real obligation?
Does a human still have to approve the final action?
What happens if the Agent exceeds a rate or cross-user access limit?

The absence of a tool answers none of these explicitly.

Prompt instructions are not enough either. A sentence such as “do not buy without permission” depends on model behavior. A server-enforced capability boundary can return a deterministic denial. A machine-readable boundary lets the client understand that denial before it improvises a recovery path.

Five kinds of "no"

A useful negative-space document should distinguish at least five categories.

1. Unavailable

The capability does not exist on this interface.

Example: an anonymous discovery endpoint can search but cannot create an order or move funds.

2. Scope-gated

The capability exists, but the current identity has not declared or received the required scope.

The server should default to deny rather than treat an unknown Agent as broadly trusted.

3. Rate-limited

The action is permitted within an explicit budget. The limit, unit, and failure response should be predictable enough for a client to stop rather than retry aggressively.

4. Forbidden

Some behavior should remain disallowed regardless of convenience: impersonation, exceeding declared scope, reselling user data, or rebuilding a cross-user profile graph from protocol reads.

5. Human-gated

Some actions remain too consequential for a delegated scope to override. Arbitration, key revocation, account deletion, or large withdrawals may require a fresh human ceremony even when the Agent is otherwise authenticated.

These categories produce different recovery behavior. “Unavailable” may send the user to another interface. “Scope-gated” may request authorization. “Rate-limited” should wait. “Forbidden” should stop. “Human-gated” should hand off a precise action for confirmation.

Documentation is not enforcement

A negative-space file is useful only when it matches runtime behavior.

The strongest version connects each declared boundary to an enforcement mechanism:

named write scopes map to actual routes or tool actions;
undeclared writes fail closed;
rate caps produce stable error codes;
repeated abuse changes an accountability state;
sensitive transitions require a live human ceremony;
limits are versioned with the same contract the Agent reads.

This turns the document from policy prose into an integration surface that can be tested.

A live example

WebAZ publishes both sides of its Agent contract.

As checked on September 2, 2026, its public protocol reported version 0.1.37 and schema 49.

The positive capability map is available at:

https://webaz.xyz/.well-known/webaz-capabilities.json

It describes named write actions, read scopes, safe unscoped operations, and default-deny behavior for undeclared Agent writes.

The negative space is available at:

https://webaz.xyz/.well-known/webaz-negative-space.json

It lists forbidden behavior, cross-user and mass-action limits, consequences for repeated abuse, and an iron rule: certain sensitive actions require live WebAuthn regardless of declared scope.

The public shopping surface demonstrates the smallest version of the idea. Its anonymous tool list exposes only webaz_search. Account, order, reservation, and settlement actions are not present on that surface.

This is an implementation example, not a claim that the design is complete or universally secure. A published boundary still needs adversarial tests, monitoring, and review. The useful property is that a client can inspect the intended boundary and compare it with observed behavior.

A practical test for Agent builders

For one MCP server or Agent API, ask:

Can the client enumerate what this identity may do?
Can it distinguish unavailable, scope-gated, rate-limited, forbidden, and human-gated actions?
Does every consequential write have a named authorization boundary?
Are denial and retry states deterministic?
Can the client learn which actions must stop instead of escalating automatically?
Is the boundary versioned and testable against the live service?

Agents become more useful when they can act. They become more trustworthy when they can explain why they stopped.

Publishing a machine-readable yes is the start of an integration. Publishing an enforceable, machine-readable no is what gives that integration a boundary.

WebAZ integration contract: https://webaz.xyz/.well-known/webaz-integration.json

Capability map: https://webaz.xyz/.well-known/webaz-capabilities.json

Negative space: https://webaz.xyz/.well-known/webaz-negative-space.json

Humans and AI Agents Need One Commerce Record, Not Two Realities

WebAZ — Mon, 31 Aug 2026 23:29:05 +0000

An AI-commerce demo can look complete after three steps:

prompt -> product search -> tool call

That is enough to demonstrate connectivity. It is not enough to demonstrate commerce.

The difficult questions begin immediately afterward:

Did the seller publish enough information for a decision?
Was the quoted price still valid when the request was submitted?
Did the Agent prepare an order or make a binding commitment?
Which human approved the consequential step?
Which settlement path was selected?
If a response timed out, did the action fail, succeed or remain unknown?
What evidence can the buyer, seller and operator inspect later?

A production-oriented system should not answer those questions differently depending on whether the user arrived through a browser or an Agent.

Humans and Agents need different permissions over one explicit commerce record, not two incompatible realities.

Start with shared facts

An Agent cannot make a reliable purchase decision from marketing copy alone. A useful product record needs decision-relevant facts such as:

{
  "price": "19.90 USDC",
  "availability": "in_stock",
  "handling_time": "within 72h",
  "delivery_estimate": "7-14 days",
  "return_window": "7 days",
  "unknowns": ["final carrier before fulfillment"]
}

The exact schema will differ by system. The important property is that a person and an Agent inspect the same facts, including what is not known.

If the browser says “available” while the Agent endpoint returns stale inventory, the system has not created agentic commerce. It has created a second, less visible storefront that will eventually disagree with the first.

Separate preparation from commitment

Many useful Agent actions are reversible:

search;
compare;
request a quote;
assemble a cart;
prepare an order request;
explain the terms to the user.

The commitment boundary is different. Creating an order, authorizing payment or accepting a consequential term should not be smuggled into a harmless-looking tool chain.

A safer flow looks like this:

discover
  -> quote
  -> prepare order request
  -> show terms and unknowns
  -> human approval
  -> create order

WebAZ currently uses this distinction on its authenticated commerce path. An Agent may search, quote, draft and submit an order request. A human Passkey approval is required before the order exists.

The reviewed public shopping MCP is narrower by design. It is anonymous and discovery-only: it exposes search but cannot create orders or move funds.

That limitation is a product property, not a missing demo effect. A client can connect the surface without accidentally giving an exploratory prompt transactional authority.

Settlement paths should remain distinguishable

“Payment supported” hides more than it explains.

Different settlement mechanisms have different trust assumptions, failure modes and recovery options. They should not be presented as interchangeable buttons behind one generic payment claim.

WebAZ currently exposes two real settlement paths.

Direct Pay

Direct Pay supports off-platform payment from buyer to seller. WebAZ records order states, acknowledgements, a snapshot of the seller's payment instructions and submitted evidence.

The boundary matters: WebAZ does not hold principal. It does not verify the payee or payment method, guarantee payment or delivery, or issue the seller's refund.

USDC on-chain escrow

The USDC path locks real funds in an immutable Base-mainnet contract. The contract constrains exits and enforces per-order caps on-chain; WebAZ does not custody the principal.

The contract has not had a third-party security audit. That disclosure belongs beside the feature, not in a footnote that disappears during promotion.

The shared principle is not that the two paths are equally safe. It is that the selected path and its boundary remain visible in the transaction record.

Payment is not fulfillment

A payment provider can report success while the commerce system still lacks a confirmed order, inventory allocation or fulfillment state.

Agents make this distinction more urgent because an automated retry can turn an ambiguous timeout into a duplicate consequential action.

After every write, the system should be able to answer:

What is the last proven fact?
What remains unknown?
Is the next action safe to retry?
Which participant acts next?
Which evidence supports that conclusion?

This is why state, acknowledgements, evidence, recovery and dispute handling are part of the commerce interface rather than back-office details.

Apply the same discipline to contribution

Agent participation has a similar boundary problem.

An Agent can discover a public task, inspect its constraints and prepare an evidence-backed suggestion. That does not automatically make the suggestion an accepted contribution, grant source access or create an economic claim.

The WebAZ production core is private. Source access and code contributions are invitation-based. Invited AI-assisted work requires a Passkey-bound accountable human.

Again, different roles operate on one record:

requester -> executor/tool -> reviewer -> accepted artifact -> accountable party

The Agent can be named as an executor without being presented as the person who accepted responsibility for shipping the result.

A four-question implementation test

Take one real transaction in your own system and ask:

What may the Agent read?
What may it prepare without committing the user?
Which exact step requires human approval?
What evidence remains after that action?

If the browser and Agent surfaces produce different answers, the integration is not yet operating under one commerce model.

If “payment succeeded” is the last explainable state, the transaction record is incomplete.

If the Agent can commit but nobody can identify the accountable approver, the permission model is incomplete.

The goal is not maximum autonomy. It is legible autonomy: every participant can see the facts, permissions, commitment boundary and resulting evidence.

That is the shared stack WebAZ is currently testing across its PWA, MCP surfaces, real settlement paths and contribution entry.

WebAZ: https://webaz.xyz

An Open Task Is Not Yet a Contribution

WebAZ — Sun, 30 Aug 2026 03:02:23 +0000

Most contributor onboarding starts by collecting identity.

Create an account. Join the community. Request repository access. Pick an issue. Only then discover whether the work is relevant, bounded or even ready to be attempted.

That sequence is especially awkward in AI-assisted development. An Agent can produce a plausible patch quickly, but speed does not answer the questions that maintainers actually need resolved:

Was this problem authorized?
What files, systems or external actions were inside the boundary?
What evidence would prove completion?
Which risks required human review?
Who is accountable for the result?

A useful contributor surface should reveal those constraints before it asks for commitment.

Start with problems, not identity collection

WebAZ currently exposes a narrow public contribution entry through the full Remote MCP surface.

Without an API key, a person or Agent can:

list public build tasks;
inspect a task's execution boundary and acceptance criteria;
submit an evidence-backed suggestion to the maintainer review inbox.

The conceptual flow looks like this:

discover public task
  -> inspect boundary and verification
  -> decide whether the problem is understood
  -> submit a structured suggestion
  -> maintainer review

The default buyer-facing MCP surface does not advertise the contribution tool. The full surface exposes webaz_contribute, where list_open, detail and suggest are public starting actions.

A compact interaction can begin with:

{
  "action": "list_open",
  "area": "docs",
  "agent_capabilities": "markdown,read-source"
}

The result is not merely a title list. A task can describe risk level, required capabilities, autonomy, estimated effort, context size, dependencies, blocking conditions and whether human review is required.

Before doing anything, a prospective participant can ask for the detail view:

{
  "action": "detail",
  "task_id": "<public-task-id>"
}

That is where a real coordination system should state what may change, what must not change, what commands or evidence are expected and what “done” means.

Suggestions are intentionally weaker than contributions

The next distinction prevents the public entry point from becoming a participation factory.

A suggestion is a proposal in a maintainer review inbox. It is not:

a contribution fact;
formal participation;
repository access;
accepted work;
a reward, payment or redemption claim;
ownership or governance rights.

That weaker status is useful. It allows a newcomer to add signal without pretending that every idea has already created value for the project.

A good suggestion should still carry enough structure to be evaluated:

{
  "action": "suggest",
  "title": "Add a reproducible empty-state example for the public catalog",
  "summary": "The current guide shows successful search but not the expected zero-result contract. Add one exact request, response and verification note.",
  "expected_outcome": "A reader can distinguish an honest empty result from a transport or authentication failure.",
  "source_ref": "https://example.com/reproduction-note"
}

This example is illustrative. A real suggestion should link only to evidence the proposer is authorized to share.

Private source changes the public promise

The WebAZ production core repository is private. Source access and code contributions are invitation-based.

That means the public contribution surface must not imply an open repository or promise that a suggestion will turn into code access. Public discovery and proposal are the available first steps. Maintainers decide whether a proposal needs clarification, should be converted into a task or belongs outside the current scope.

This is less permissive than a public issue tracker, but it is more precise about what the system can promise today.

It also creates a safer role for Agents. An Agent can discover a bounded problem, compare its capabilities with the task requirements, assemble public evidence and draft a suggestion. It cannot independently become the accountable contributor. Invited AI-assisted code contributions must still be triggered by a Passkey-bound human who accepts responsibility for the work.

Task metadata is part of the product

An open-task system becomes useful when it helps prevent collisions and mis-scoped work.

For Agent-assisted collaboration, I would expect at least these fields:

{
  "risk_level": "low",
  "required_capabilities": ["markdown", "read-source"],
  "agent_autonomy": "autonomous",
  "estimated_context_size": "small",
  "human_review_required": false,
  "dependencies": [],
  "blocking_conditions": [],
  "value_state": "uncommitted"
}

The final field matters. A task estimate describes effort, not payment. A task record or suggestion should not be interpreted as an economic instrument or a promise of future value.

A five-question contributor test

Before adding another signup form or “good first issue” label, test the entry point with five questions:

Can someone see a real problem before registering?
Can they inspect the execution and verification boundary before starting?
Can they tell the difference between a suggestion and accepted contribution?
When AI assists, is there an accountable human?
Can a maintainer reconstruct why the work was accepted?

The goal is not zero friction. Trustworthy collaboration needs review, identity and responsibility at the right moments.

The goal is to delay those demands until the participant understands the problem, while keeping every later status honest.

For WebAZ, that begins with public task discovery and evidence-backed suggestions. No account is required to understand the work. Acceptance still has to be earned.

WebAZ entry: https://webaz.xyz

Payment Succeeded. Did the Transaction?

WebAZ — Sat, 29 Aug 2026 08:49:54 +0000

A payment API returns success. The interface turns green. Everyone relaxes.

But what exactly succeeded?

The payment rail may have accepted or settled money while the merchant never received the callback. Inventory may still be uncommitted. The selected variant may have changed. Fulfillment may not have started. A buyer or Agent may be staring at a timeout and deciding whether to retry.

In distributed commerce, payment success is one fact. Transaction completion is a chain of facts owned by different systems and people.

The green checkmark hides several clocks

A useful commerce state model separates at least these stages:

intent
  -> authorization
  -> payment attempt
  -> payment outcome
  -> merchant acknowledgement
  -> order acceptance
  -> fulfillment
  -> delivery / return / dispute

These stages do not advance on one clock.

The payment rail knows whether money moved.
The merchant knows whether it accepted the commercial obligation.
The inventory system knows whether the exact item and variant were committed.
The fulfillment system knows whether dispatch started.
The buyer knows whether the received outcome matches what was approved.

Collapsing them into paid=true creates a dangerous ambiguity: nobody can tell who owns the next action.

Timeout is a state, not permission to retry

Suppose an Agent submits a payment and the connection times out. There are at least three possibilities:

The payment failed before reaching the provider.
The payment succeeded, but the response was lost.
The provider accepted it, but final settlement is still pending.

Blindly retrying can create a duplicate charge. Blindly declaring failure can leave a paid buyer without an acknowledged order.

The correct response is usually outcome_unknown, followed by deterministic reconciliation. The system should query the authoritative payment record using the same idempotency key, compare it with the approved purchase intent and then advance the commerce state exactly once.

The receipt should connect intent to responsibility

A model-generated sentence is not enough. A recoverable transaction needs a compact machine-readable record such as:

{
  "intent_id": "intent_123",
  "idempotency_key": "checkout_123_attempt_1",
  "approved": {
    "seller": "seller_42",
    "item": "sku_7",
    "variant": "green-8-pack",
    "currency": "USDC",
    "maximum_total": "18.29",
    "destination": "SG",
    "terms_version": "terms_2026_08_29"
  },
  "payment": {
    "state": "confirmed",
    "authoritative_reference": "rail_ref_456"
  },
  "commerce": {
    "merchant_acknowledged": false,
    "inventory_committed": "unknown",
    "fulfillment": "not_started",
    "next_owner": "merchant_reconciliation"
  }
}

This is an illustrative architecture pattern, not a WebAZ API response. Its important property is that payment and commerce remain separate while the record identifies what was approved and who must act next.

Agents make this boundary more important

Humans already misread green checkmarks. Agents add retries, tool chaining and compressed summaries.

An Agent-safe commerce workflow should therefore:

bind approval to an exact seller, item, variant, currency, maximum total, destination and terms version;
assign an idempotency key before the first external write;
represent timeout as unknown, not failed;
reconcile against the authoritative rail before retrying;
keep payment, order and fulfillment states independently visible;
name the system or person that owns the next action.

The Agent may prepare and explain. It should not reinterpret approval or invent completion.

One current WebAZ example

WebAZ currently exposes two live settlement rails with different custody models.

With Direct Pay, payment happens off-platform from buyer to seller. WebAZ does not hold the principal. WebAZ does not verify the payee or payment method, guarantee payment or issue the seller's refund. It records order states, acknowledgements, a snapshot of the payment instructions and evidence so the later process remains legible.

For eligible USDC orders, real funds are locked in an immutable Base-mainnet escrow contract. The contract is runtime-gated, capped per order and has not had a third-party security audit. An on-chain payment or release still does not prove delivery; settlement and fulfillment remain different states.

The public WebAZ launch pulse reported 37 completed orders and 15 resolved disputes at 08:41 UTC on 29 August 2026. Those are dated protocol counts, not a claim that every failure mode above occurred on WebAZ.

A practical test

Take one failed or ambiguous checkout from your own system and answer five questions:

What is the last authoritative fact?
Which state is still unknown?
Is retrying safe, and how is that proven?
Who owns the next action?
What evidence will let the buyer, merchant and operator reconstruct the decision later?

If the answer is only “the payment screen was green,” the transaction is not yet legible enough for an Agent.

Payment success matters. But a trustworthy commerce system must also explain what happened next.

WebAZ protocol status: https://webaz.xyz/.well-known/webaz-protocol.json

An MCP Server Is Not Interoperable Just Because It Connects

WebAZ — Fri, 28 Aug 2026 07:34:14 +0000

An MCP handshake proves that two endpoints can start a session. It does not prove that an Agent can understand the tool, call it correctly, distinguish display text from machine-readable state, or know when to stop.

I ran an independent test with FastMCP 3.4.7 as the client and WebAZ's public shopping MCP as the remote server.

The question was deliberately narrow:

What should an MCP smoke test verify beyond connection success?

A four-part minimum

1. Advertised schema

Call list_tools() and inspect the input schema, not just the tool name. A caller should be able to construct a valid request and identify conflicting fields.

The tested endpoint exposed one anonymous tool, webaz_search. It did not advertise account, order, reservation or settlement actions.

2. Explicit error state

Check CallToolResult.is_error. A text block alone is not proof that an operation completed successfully.

The test call returned is_error=false.

3. Concise model-facing content

The ordinary content block summarized that three products were found without copying the full payload into model context.

4. Deterministic structured content

The structured result carried destination normalization, product fields and workflow state:

response_type=comparison
completion=complete
assistant_action=answer
Singapore normalized to SG
three products returned from four matches

Checking only rendered text would have missed the fields a deterministic client or UI needs.

Minimal reproduction

import asyncio
from fastmcp import Client


async def main():
    async with Client("https://webaz.xyz/mcp/shopping-v1") as client:
        tools = await client.list_tools()
        assert [tool.name for tool in tools] == ["webaz_search"]

        result = await client.call_tool(
            "webaz_search",
            {
                "query": "tissue",
                "ship_to": "Singapore",
                "sort": "price_asc",
                "limit": 3,
            },
        )

        assert result.is_error is False
        assert result.content
        assert result.structured_content["completion"] == "complete"
        assert result.structured_content["assistant_action"] == "answer"


asyncio.run(main())

Observed on 2026-08-28 with Python 3.13.12 and FastMCP 3.4.7.

The Agent-commerce implication

A fluent answer can hide an incomplete transaction state. Discovery is not a quote. A quote is not an order. An order is not settlement. Settlement is not fulfillment.

Those boundaries should be represented in schemas and structured results, not only in prose prompts.

This was one public, read-only call. It was not a security audit, load test, OAuth test, renderer test, order test or payment test. FastMCP did not participate in or endorse the experiment.

The takeaway: verify the advertised schema, is_error, concise content and raw structured_content separately. Connection success is only the beginning.

FastMCP client documentation: https://gofastmcp.com/clients/tools

Public test endpoint: https://webaz.xyz/mcp/shopping-v1

A 5-Minute Grok Commerce Experiment with a Custom MCP

WebAZ — Thu, 27 Aug 2026 11:08:10 +0000

Updated September 8, 2026: Grok now has a dedicated public-search endpoint. This guide replaces the earlier Grok URL and keeps account quote/draft access out of the default setup.

I'm building WebAZ. This experiment is a small way to try its product discovery: ask Grok to find an actual listing, then check whether the result gives you enough information to compare it responsibly. Searching is not buying.

Before You Start

Use a Grok account with access to Connectors.
Open https://grok.com/connectors. The current web interface groups Connectors under Plugins.
The public-search experiment does not require a WebAZ account.
Never paste a password, API key, wallet seed phrase or other secret into a connector URL or chat.
This is a manual Custom MCP setup, not a claim of an official catalog listing or xAI endorsement.

Experiment A: Public Product Search

Add the Connector

Following xAI's custom MCP instructions:

Open Connectors.
Click New Connector, then select Custom.
Name the entry WebAZ Shopping.
Use https://webaz.xyz/mcp/grok-search-v1.
Complete the connector setup. This public endpoint does not require WebAZ OAuth.

Use the Grok-specific URL above, not the ChatGPT shopping endpoint. It exposes one read-only tool, webaz_search. If you already have a working WebAZ search entry, check its URL before adding another.

Run the Test

Use WebAZ to find wall-hanging facial tissues for delivery to Singapore. Show pack count, sheet size and listed price. Mark missing shipping costs or unclear variants. Do not place an order.

What to Check

The answer should be based on a WebAZ search result, not invented products.
Check the actual listing and selected option. A starting price does not necessarily buy the pack size named in a product title.
Compare pack count, sheet size, handling time, delivery estimate and return terms only where supplied.
Missing shipping fees, taxes or a delivered total should remain unknown.
Grok controls how results are displayed. Do not expect the same interactive cards as another AI client.
No matching result is a valid outcome. It is not evidence that an unavailable product can be purchased.

Success here means finding a checkable product result, not proving it is the cheapest option or guaranteeing delivery.

What This Does Not Do

No WebAZ account access
No order creation
No inventory reservation
No payment
No private account data

Account Quote or Draft: Not Part of This Experiment

The separate /mcp/grok-v1 account connector is a compatibility preview, not the recommended default. Do not add it for ordinary product search. An OAuth challenge demonstrates an authorization boundary; it does not prove that quote/draft interactions work reliably in Grok.

For the current endpoint status, see WebAZ's remote MCP guide.

Business and Enterprise

A team administrator must provision a connector before members can use it. Follow xAI's connector management instructions. This public-search experiment does not require access to private WebAZ account data.

Verification Note

On September 8, we added a new anonymous connector in an existing Grok account using /mcp/grok-search-v1. Its details showed only webaz_search. In a fresh conversation, Grok used that connector and returned five tissue listings for Singapore; the visible tool result also reported five matching products. The English answer flagged missing shipping costs and unclear variants.

A separate Chinese-language test returned no matches for the query 挂式抽纸. In another fresh conversation, Chinese instructions specifying the English search phrase wall-hanging facial tissues returned five listings. This suggests a keyword/language matching limitation in this example, not proof that products cannot ship to Singapore. The Chinese answer flagged missing freight but placed title pack counts beside starting prices without adequately explaining variant uncertainty. Do not treat that pairing as a verified SKU price. Check the selected option and delivered total on the listing.

These are individual setup/search observations, not a reliability benchmark, a brand-new Grok-account onboarding test, or a purchase. We did not request a quote, create an order, or pay. Prices and availability can change.

Sources

Before You Connect an AI Shopping Tool, Ask These Seven Questions

WebAZ — Tue, 25 Aug 2026 15:15:15 +0000

Installing an AI connector is easy. Deciding whether it deserves authority is harder.

The usual installation guide answers technical questions: Which URL do I enter? Which package do I run? Which client is supported?

A useful trust guide should answer a different set of questions:

What can the AI access before I sign in?
Which actions can change real state?
Which actions still require a person?
What happens to payment?
What evidence survives after the tool acts?
Which safety claims can be independently checked?
What is still unknown or unfinished?

I am using WebAZ as the concrete example below, but the checklist applies to any MCP server or AI-commerce connector.

1. Can I test useful behavior without creating an account?

A connector should not demand maximum trust before demonstrating minimum usefulness.

WebAZ exposes a discovery-only shopping MCP endpoint:

https://webaz.xyz/mcp/shopping-v1

It can search the reviewed public product surface. It cannot create an order, reserve stock, charge a payment method, move funds, accept terms, or read private account data.

That makes the first evaluation reversible: connect, inspect product data, and decide whether the result is useful before registering.

The broader Remote MCP endpoint is:

https://webaz.xyz/mcp

For MCP clients that use local STDIO configuration, the current public bridge is:

npx -y @seasonkoh/webaz@latest

The package is a thin bridge to the live service. It is not a local copy of the private WebAZ production core.

2. Does the interface separate reading from acting?

“The AI has tools” is not a permission model.

A safer surface distinguishes at least four levels:

read public facts;
prepare a reversible draft;
request a consequential action;
commit or settle with accountable authorization.

On WebAZ, anonymous access is for public reads. Authenticated capabilities depend on the selected surface and granted authorization. Selected higher-risk actions return a browser approval URL rather than silently treating the model's request as the person's consent.

This distinction matters more than a generic instruction such as “please ask before buying.” Capability boundaries should exist in the interface, not only in the prompt.

3. Why does registration use an invitation and Passkey?

Browsing does not require an invitation. Account creation currently does.

WebAZ uses invitations as an anti-abuse and Sybil-resistance control while the live network is actively developed. It is an account-integrity control, not a launch-status label or an investment-style scarcity mechanism.

A Passkey binds the account to an accountable human and is retained as a confirmation boundary for selected consequential actions. It does not make every transaction safe, and it does not verify that a seller's off-platform payment instructions are correct. It establishes who approved an action; it does not replace due diligence.

4. Where does the money go?

The word “payment” is too broad to describe custody.

WebAZ currently has two real rails with different models.

Direct Pay

The buyer pays the seller directly off-platform. WebAZ records the payment-information snapshot, acknowledgements, order state, and evidence. WebAZ does not hold the principal, verify the payee or payment method, guarantee payment or delivery, or issue the seller's refund.

USDC on-chain escrow

Eligible orders can lock real USDC in an immutable contract on Base mainnet. Contract exits are limited to the original buyer, the voucher-bound seller, or the configured fee destination, and per-order caps are enforced on-chain.

The contract has not had a third-party security audit. That limitation belongs in the main explanation, not in fine print.

5. What remains after the AI acts?

An agent response is not a transaction record.

For a real workflow, the system should preserve the product and payment information that was accepted, the order state, relevant acknowledgements, evidence, and the transition that occurred. Without that trail, a convincing conversation can still leave the buyer and seller unable to explain what happened.

WebAZ is designed around explicit order states and evidence rather than treating the chat transcript as the source of truth.

6. Can the current claims be checked without trusting a social post?

The strongest source should be current and machine-readable.

WebAZ publishes its live protocol facts here:

https://webaz.xyz/.well-known/webaz-protocol.json

The document reports the current software version, MCP endpoints, authentication model, network phase, payment disclosures, and links to additional capability and integration documents.

The official npm registry currently reports @seasonkoh/webaz version 0.1.36. Search snippets may lag behind registry changes, so the registry and the live protocol document are better version sources than an old directory page.

7. What should still make me cautious?

Trustworthy documentation should make refusal possible.

For WebAZ, the important limits include:

registration remains invite-gated;
additional payment methods are still being added;
Direct Pay occurs off-platform and the payee or method is not verified by WebAZ;
WebAZ does not guarantee payment, delivery, or seller refunds;
the USDC contract is live but has not had a third-party security audit;
the public npm package is a bridge, not public access to the private production core;
a manual MCP connection is not the same as an official app-directory listing.

Those statements do not weaken the trust story. They are the trust story.

A low-risk first test

Start with public discovery and ask the AI to separate facts from unknowns:

Search WebAZ for products relevant to my request. Show price, stock, delivery, returns, seller context, and every warning or missing field. Do not create an order or assume compatibility.

Use the Agent Commerce Lab for current client setup:

https://webaz.xyz/ai/

The first question is not whether an AI can click “buy.”

It is whether the system makes authority, evidence, custody, and uncertainty visible before anyone does.

Current-status boundary, verified 2026-08-25: WebAZ is publicly launched and actively developed. Direct Pay and eligible Base-mainnet USDC escrow are real payment rails with different custody models. WebAZ does not hold the principal on Direct Pay and does not verify the payee or payment method. The USDC contract has not had a third-party security audit. Public shopping discovery does not create orders or move funds.

The Second Click Is the Real Test of an AI Shopping Plugin

WebAZ — Tue, 25 Aug 2026 02:34:31 +0000

The first successful search is the easiest part of an AI shopping demo.

A user asks for a product, the model calls a tool, and a polished result card appears. That proves the happy path can work once. It does not yet prove that the integration can survive ordinary use.

The more revealing test is the second click.

Can the shopper open the same product again? Can they move between products without an earlier interaction suppressing the next one? What happens when a direct tool response and a matching result notification arrive in different orders? Does the detail view stay in the shopper's language?

Those questions shaped the latest WebAZ Shopping review build.

One interaction, one settlement

Interactive tool surfaces often receive the same logical result through more than one path. A direct response may arrive first, or a matching tool-result notification may arrive first.

If each path has its own timeout and success logic, the UI can briefly show a failure even though a valid result has already arrived. It can also render the same outcome twice or leave an interaction in an ambiguous state.

The safer model is to give each detail request one lifecycle and one deadline:

both valid arrival orders converge on the same settlement path;
duplicate suppression means "still pending," not success or failure;
the first matching success settles the interaction once;
a timeout remains an honest failure when no matching success arrives.

This sounds small, but it is the difference between a demo animation and a state machine that a user can rely on.

Repetition is part of the contract

A product-detail action is not globally unique. A shopper may inspect a product, compare another one, and return to the first. Deduplication that outlives one interaction turns a valid second click into a silent no-op.

The scope of deduplication therefore has to match the scope of the user action. Replays inside one interaction should be suppressed. A later, deliberate interaction should be allowed to run normally.

This principle applies beyond shopping. Idempotency protects a system from accidental replay, but it should not erase a new user intention.

Localization has to survive the tool boundary

A multilingual conversation can still produce a detail view in the wrong language if locale context is lost between search results, tool metadata, and the rendered component.

Keeping product details in the shopper's locale is more than a presentation preference. Shipping terms, return conditions, stock notes, and unknown fields are decision-relevant information. A language fallback can change whether the user understands the limits of the result.

Keep the first public surface narrow

The reviewed WebAZ Shopping endpoint is intentionally discovery-only. It exposes one public webaz_search tool for product search and comparison.

It does not provide login, account access, ordering, payment, credentials, or private data.

That boundary lets us test the read-only experience before attaching consequential actions. A shopping integration should first demonstrate that it can return repeatable, localized, decision-ready information. Preparation, commitment, and settlement can then be added behind their own explicit authority boundaries.

What this build proves, and what it does not

The current review build demonstrates a more reliable product-discovery interaction:

repeated detail clicks work as new interactions;
asynchronous result paths converge on one outcome;
timeouts remain explicit;
product details preserve shopper locale;
the public tool surface remains discovery-only.

It does not mean that a new ChatGPT plugin version has been approved or published. The build and demo are prepared for the review process; approval and publication are separate steps.

You can watch the current 55-second production demo here:

https://webaz.xyz/plugin-review/webaz-shopping-demo.mp4

For teams building AI commerce interfaces, the practical question is simple: after the first impressive result, what does your second click reveal about the system?

One Commerce Protocol, Two Interfaces: PWA for Humans and MCP for Agents

WebAZ — Mon, 24 Aug 2026 01:21:22 +0000

When a product adds an agent interface, it is tempting to treat it as a second application: the web interface is for people, while a collection of tools is for AI.

That split is convenient at the UI layer. It becomes dangerous when it reaches the transaction model.

If the human interface and the agent interface use different order states, permission rules or definitions of completion, the system develops two versions of commercial reality. A person may see a pending request while an agent reports a completed action. A step that requires human confirmation in the web app may become an unreviewed shortcut in the agent API. When something fails, neither side can explain the same outcome.

The safer design is two interfaces over one protocol.

Different strengths, shared state

A PWA and an MCP server should not be identical. They serve different operators.

A human interface is good at displaying terms, collecting deliberate approval, managing identity and helping a person inspect an exception. An agent interface is good at structured discovery, comparison, repetitive preparation and following explicit machine-readable contracts.

The interfaces can divide work without dividing truth:

Human PWA                         Agent MCP
---------                         ---------
inspect terms                     read structured facts
manage identity                   search and compare
review a proposed action          prepare a request
perform Passkey approval          receive the resulting state
inspect exceptions                continue from explicit outcomes
              \                 /
               one state machine

The important property is not visual consistency. It is behavioral consistency. Both interfaces should agree on the entity being acted on, the current state, the allowed transition and the evidence produced by that transition.

Permissions should describe actions

Possession of a credential should not silently mean permission to perform every write.

WebAZ publishes a capability matrix in which authenticated agent writes map to named action scopes. Undeclared writes are denied by default. This makes authorization part of the integration contract instead of an assumption hidden in client code.

Conceptually, an agent declaration can say:

{
  "allowed_actions": [
    "search",
    "place_order"
  ]
}

The exact set is less important than the principle: permission should name the action and its boundary. A search capability does not imply permission to place an order. Permission to prepare an order does not imply permission to approve an irreversible step.

Preparation is not consent

Agent workflows become easier to reason about when actions are separated by reversibility:

Read: inspect public or party-authorized state.
Prepare: search, compare, quote or assemble a request.
Commit: create a commercial obligation or change accountable state.
Settle: move value or finalize an irreversible outcome.

An agent can be very useful at the first two levels. Moving from preparation to commitment should require a visible rule, not a vague instruction such as "buy the best one."

In WebAZ, risk actions return an approval URL. The human completes the required Passkey ceremony in a browser surface. The agent can prepare the action and continue after the protocol reports the result, but it does not impersonate the person during the approval.

Some actions are covered by an iron rule: no declared scope overrides the requirement for live human presence. This is a protocol property, not a preference left to each agent client.

A discovery-only surface is still useful

Not every MCP endpoint needs a path to checkout.

WebAZ's reviewed shopping-v1 surface is deliberately discovery-only. It exposes one search tool for reviewed active listings and cannot create orders or move funds. That smaller surface lets buyers and builders evaluate whether an agent can represent product facts and unknowns honestly before introducing consequential actions.

This is a useful deployment pattern:

start with a narrow read surface;
evaluate outputs against the human-visible record;
add preparation actions with explicit states;
add commitment only when identity, permission and recovery are defined;
keep human-presence requirements outside the agent's ability to bypass.

An integration checklist

Before adding an agent interface to a commerce system, ask:

Do the web app and the agent read the same product and order identifiers?
Can both interfaces name the same current state?
Is each agent write mapped to an explicit scope?
Are undeclared writes rejected?
Are preparation and commitment separate transitions?
Does human approval happen on a surface the person can inspect?
Can an agent resume from the confirmed result instead of guessing whether an action succeeded?
Can both interfaces produce the same audit trail when an operation fails?

If the answers differ by interface, the problem is not just API design. It is a split transaction model.

One protocol is the product

Agent-native commerce should not mean maintaining an AI shortcut beside the real system. It should mean exposing the real system through another interface while preserving the rules that make its outcomes understandable.

WebAZ publishes the current integration contract, capability matrix and negative-space rules as machine-readable documents:

The PWA and MCP do different jobs. The protocol remains one.

The Most Important Output of a Shopping Agent May Be `unknown`

WebAZ — Sun, 23 Aug 2026 06:58:46 +0000

A shopping agent that always returns a complete answer is not necessarily useful. In commerce, completeness can be a warning sign.

Product pages are uneven. A listing may state price, stock, return terms, handling time and a delivery estimate while omitting exact dimensions, compatibility, maximum load or included accessories. A human buyer usually notices the gap and asks a follow-up question. A language model may instead complete the pattern from similar products and present the inferred value with the same confidence as a seller-declared fact.

The difficult part of AI commerce is therefore not only retrieval. It is preserving provenance and uncertainty through the entire decision process.

Three classes of product facts

An agent-facing product record should distinguish at least three classes:

Declared facts: values supplied by the seller or another accountable source.
Derived facts: values calculated from declared inputs through a visible rule.
Unknown facts: values that are absent, ambiguous, stale or unsupported.

These classes should not collapse into one polished description. A field that is absent should remain absent. A derived estimate should identify its inputs. A seller statement should not silently become a platform guarantee.

An illustrative response shape could look like this:

{
  "item": "Metal Laptop Cooling Stand",
  "declared": {
    "price": { "amount": 18.4, "currency": "USDC" },
    "availability": "in_stock",
    "return_window_days": 7,
    "handling_time_hours": 72,
    "delivery_estimate_days": { "SG": 12, "default": 18 }
  },
  "decision_flags": [
    "new_seller",
    "no_sales_history"
  ],
  "unknown": [
    "exact_dimensions",
    "weight",
    "supported_laptop_size_range",
    "maximum_load",
    "included_parts",
    "material_thickness"
  ],
  "checked_at": "2026-08-23"
}

This is an explanatory shape rather than a claim that every commerce platform uses the same schema. The useful property is the separation itself.

Why a string like `unknown` is not enough

Production systems usually need more than a null value. The reason a field is unknown affects what the agent should do next.

For example:

{
  "field": "maximum_load",
  "state": "unknown",
  "reason": "not_declared_by_seller",
  "next_action": "ask_seller",
  "blocks": ["compatibility_recommendation"]
}

Other reasons might include stale_value, conflicting_sources, not_applicable, or outside_sale_region. These states lead to different behavior. A stale price may require refresh. Conflicting dimensions may require evidence review. An undeclared compatibility claim should block a recommendation rather than invite a guess.

Decision flags are not verdicts

Risk indicators need the same care. A new seller or a seller with no sales history is not automatically untrustworthy. Those are decision flags: facts a buyer may want to weigh, not accusations generated by the platform.

The agent should surface the flag, explain its source and allow the buyer to choose. It should not convert a sparse history into a fabricated reputation score.

A public test surface

WebAZ currently exposes a reviewed, discovery-only shopping surface at:

https://webaz.xyz/mcp/shopping-v1

The surface exposes one search tool and cannot create orders or move funds. The WebAZ Agent Commerce Lab includes a known-versus-unknown prompt using the real reviewed laptop-stand listing described above.

The prompt asks the agent to produce two lists:

facts the listing actually states, with values;
facts a careful buyer would want but the listing does not state.

For the second list, the agent must say unknown and must not fill gaps with typical values for similar products.

That constraint matters because it makes the failure visible. If an agent invents a screen-size range or maximum load, the output can be compared against the public listing and rejected.

A practical evaluation checklist

When evaluating a shopping agent, test more than whether it found the product.

Does every price include a currency and a freshness signal?
Does availability come from the current sellable variant rather than marketing text?
Are handling time and delivery time kept separate?
Are return terms represented as conditions rather than a vague "easy returns" claim?
Can the agent list important missing fields without guessing?
Does it distinguish seller statements from platform verification?
Are decision flags shown as evidence for human judgment rather than automated verdicts?
Does the workflow stop before an unsupported or irreversible action?

This evaluation is useful even before a store supports agent checkout. It reveals product-data gaps that affect human buyers too.

Honest incompleteness is a capability

AI commerce is often presented as a race toward fewer questions and faster checkout. That framing rewards confident completion, even when the underlying product record is incomplete.

A safer goal is decision readiness. The agent should collect what is known, preserve where it came from, expose what remains unknown and identify the next responsible action. Sometimes that action is comparison. Sometimes it is asking the seller. Sometimes it is stopping.

You can run the known-versus-unknown test on the discovery-only WebAZ Agent Commerce Lab:

https://webaz.xyz/ai/

Ask it to separate seller-stated facts from missing details. The quality of the unknown list may tell you more than the recommendation.