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:
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.
