Apply for AI Grants India

AI agents are moving from answering questions to completing commerce tasks: finding a product, comparing prices, checking delivery eligibility, applying a coupon, and placing an order. The challenge is that the open network for digital commerce is built from thousands of independent websites, apps, catalogues, payment flows, and logistics systems—each with different interfaces and rules.

WebMCP offers a practical way to make websites more usable by AI agents. Instead of forcing an agent to interpret every page visually and click through unpredictable interfaces, a site can expose structured, permission-aware tools for common actions. This article explains how to use WebMCP to help AI agents navigate the open network for digital commerce, including system architecture, tool design, security, transaction handling, testing, and India-specific considerations.

What Is WebMCP?

WebMCP is a web-oriented approach for exposing website capabilities to AI agents through structured tools and machine-readable interactions. The exact implementation may evolve with browser and standards support, but the underlying principle is straightforward: websites describe what an agent can do, what inputs are required, what information will be returned, and which actions need user approval.

For digital commerce, WebMCP can expose capabilities such as:

• Search products or services
• Retrieve structured product details
• Check inventory and fulfilment coverage
• Compare variants, prices, taxes, and delivery charges
• Add or remove items from a cart
• Apply a promotion
• Create a checkout session
• Request payment authorisation
• Track an order or initiate a return

The goal is not to give an AI unrestricted control of a website. The goal is to provide a reliable, constrained interface that lets an agent perform useful work while preserving customer consent, merchant policies, privacy, and payment security.

Why WebMCP Matters for Open-Network Commerce

Open-network commerce depends on interoperability. A buyer may discover a product through one application, purchase from an independent seller, pay through a third-party provider, and receive the order through another logistics partner. Traditional web automation struggles in this environment because it relies on page layouts, CSS selectors, visual interpretation, and brittle browser actions.

A structured agent interface improves this model in five ways:

1. Discoverability: Agents can identify available capabilities without reverse-engineering every page.
2. Precision: Inputs and outputs use explicit schemas rather than ambiguous text.
3. Reliability: A tool can return clear states such as available, reserved, failed, or awaiting confirmation.
4. Safety: High-impact actions can require explicit approval and strong authentication.
5. Interoperability: Different merchants can expose comparable functions while retaining their own systems.

This is particularly relevant in India, where digital commerce spans large marketplaces, direct-to-consumer brands, local retailers, ONDC participants, social commerce channels, UPI payment flows, and multilingual customers.

A Reference Architecture for WebMCP Commerce

A production implementation should separate the agent, WebMCP interface, commerce application, and external network services.

1. Customer-facing agent

The agent interprets the user’s intent and coordinates tasks. It should not invent availability, prices, delivery dates, or policies. Every material claim should be grounded in a current tool response.

Example intent:

> “Find a vegetarian meal kit under ₹1,500, deliverable to Bengaluru by Friday, and show me the final price before ordering.”

The agent converts this into structured searches and follows the merchant’s rules rather than assuming that all stores support identical options.

2. WebMCP tool layer

This is the controlled interface exposed by the website or commerce application. It should contain narrowly scoped tools with documented input and output schemas.

Typical tools include:

• search_catalog
• get_product
• check_serviceability
• get_delivery_quote
• create_cart
• update_cart
• create_checkout
• request_payment
• get_order_status

Each tool should state whether it is read-only, reversible, or financially consequential.

3. Merchant backend

The WebMCP layer should call existing commerce services rather than duplicating business logic. Pricing, inventory, tax calculation, promotions, seller eligibility, and order creation should remain authoritative in the backend.

4. Open-network adapters

If the business participates in an open commerce protocol or network, adapters can translate internal objects into external search, discovery, fulfilment, and order models. Keep this translation explicit. Do not assume that a network-level offer is identical to a final checkout total.

5. Identity, consent, payment, and audit services

Authentication, user consent, payment authorisation, fraud checks, and audit logs should be independent security controls. An agent tool must never receive raw card credentials or UPI PINs.

Design WebMCP Tools Around Commerce Tasks

The most important implementation decision is tool granularity. A tool that does too much becomes difficult to secure and explain. A tool that does too little forces the agent to make excessive calls and increases failure points.

Use explicit input schemas

A product search tool might accept:

{
  "query": "wireless earbuds",
  "category": "audio",
  "delivery_postal_code": "560001",
  "max_price_inr": 5000,
  "currency": "INR",
  "page_size": 20,
  "page_token": null
}

Validate every field server-side. Do not rely on the model to provide correct types, limits, postal codes, or currency values.

Return structured, source-grounded data

A result should distinguish facts from marketing text:

{
  "items": [
    {
      "id": "sku_123",
      "title": "Example Earbuds",
      "seller": {"id": "seller_45", "name": "Example Store"},
      "price": {"amount": 3499, "currency": "INR"},
      "availability": "in_stock",
      "estimated_delivery": "2026-09-06",
      "source_timestamp": "2026-09-03T10:15:00Z"
    }
  ],
  "next_page_token": "opaque-token"
}

Include timestamps, seller identity, fulfilment information, and currency. If a field is unknown, return null or an explicit status instead of fabricating a value.

Separate discovery from commitment

Searching for an item and buying it should never be the same operation. Use a staged flow:

1. Discover products or services.
2. Retrieve current details.
3. Confirm fulfilment and total cost.
4. Create or update a cart.
5. Present a review summary.
6. Obtain user approval.
7. Start payment authorisation.
8. Create the order only after successful confirmation.

This structure makes it easier for the user to stop the process and for the system to recover from price or inventory changes.

Build a Safe Agentic Checkout Flow

Agent navigation becomes risky when the agent can trigger irreversible actions. Define an approval policy before exposing purchase tools.

Low-risk actions

These usually need no additional confirmation beyond the user’s original request, subject to authentication and policy:

• Searching a catalogue
• Filtering products
• Reading specifications
• Checking delivery coverage
• Comparing public prices
• Viewing return policies

Medium-risk actions

These may require an account session or confirmation when they change user state:

• Saving an address
• Adding an item to a persistent cart
• Applying a loyalty benefit
• Reserving inventory
• Starting a return request

High-risk actions

These should require explicit, timely confirmation:

• Placing an order
• Making or authorising a payment
• Changing a delivery address
• Cancelling an order with fees
• Buying regulated or age-restricted goods
• Sharing sensitive personal data

The final confirmation should display merchant, items, quantity, delivery address, taxes, shipping, discounts, total amount, payment method, cancellation terms, and expected delivery date. Avoid vague prompts such as “Proceed?”

Handle Price, Inventory, and State Changes

Open-network commerce is dynamic. A tool response can become stale between search and checkout. WebMCP implementations should therefore treat every transaction as stateful.

Useful techniques include:

• Attach a short-lived quote or cart identifier to pricing responses.
• Revalidate price and stock at checkout.
• Return a structured changed_since_quote result when totals differ.
• Use idempotency keys for order creation and payment initiation.
• Define expiration times for reservations and checkout sessions.
• Make retries safe and distinguish retryable from permanent failures.

Example error states might include:

• ITEM_UNAVAILABLE
• PRICE_CHANGED
• DELIVERY_NOT_SUPPORTED
• PAYMENT_REQUIRES_STEP_UP
• DUPLICATE_REQUEST
• MERCHANT_TEMPORARILY_UNAVAILABLE

The agent should explain these states plainly and offer the next valid action instead of silently retrying a purchase.

Security and Privacy Requirements

WebMCP expands the attack surface because natural-language instructions are combined with tools that can affect accounts and money. Treat all web content as untrusted input.

Defend against prompt injection

Product descriptions, reviews, seller pages, and third-party content may contain instructions directed at the agent. These instructions must not override system policy or user intent. The agent should treat such text as data, not as executable authority.

Enforce server-side authorisation

A tool must verify:

• The authenticated user or session
• Resource ownership
• Seller and merchant permissions
• Scope of the requested action
• User consent for sensitive operations
• Account and transaction risk controls

Never assume that hiding a tool from the model is a security boundary.

Minimise data exposure

Return only the fields needed for the current task. Mask personal data and avoid exposing full addresses, phone numbers, tokens, or payment details unless essential. Follow India’s Digital Personal Data Protection Act requirements and maintain clear purpose and consent practices.

Protect payment credentials

The agent should initiate a payment session or redirect to a trusted payment interface. It should not handle UPI PINs, one-time passwords, card CVVs, or private authentication secrets. For Indian payments, integrate with compliant payment providers and preserve the user’s direct control over authorisation.

India-Specific Considerations

Indian digital commerce introduces operational details that an agent must model accurately.

• Postal serviceability: Pincode alone may not determine delivery. Consider locality, address validation, seller warehouse, and carrier coverage.
• Price presentation: Clearly separate base price, GST, delivery fee, platform or convenience fees, discounts, and cash-on-delivery charges.
• Payments: Support UPI, cards, net banking, wallets, and cash-on-delivery where available, but expose eligibility and limits explicitly.
• Languages: Product titles and policies may be available in English and Indian languages. Preserve the original text for legal and transaction-critical information.
• Returns and cancellations: Return windows, pickup availability, exclusions, and refund methods can differ by seller and category.
• Network roles: If operating across an open commerce network, distinguish buyer app, seller app, logistics provider, gateway, and marketplace responsibilities.
• Regulated categories: Food, medicines, financial products, alcohol, and other restricted goods may require additional controls, documentation, or age verification.

An agent should never infer that an item is legally deliverable merely because it appears in search results.

Testing and Observability

Before launch, test WebMCP tools like APIs and like user-facing commerce flows.

Contract testing

Validate schemas, required fields, enumerations, pagination, timestamps, and error formats. Maintain backward compatibility or version tools when output changes.

Scenario testing

Create test cases for:

• Out-of-stock products
• Concurrent inventory changes
• Expired carts
• Invalid pincodes
• Coupon restrictions
• Partial fulfilment
• Payment failure after order creation
• Duplicate order requests
• Seller cancellation
• Return and refund exceptions

Agent evaluation

Measure whether agents:

• Choose the correct tool
• Ask for missing information
• Avoid unsupported assumptions
• Show the final total accurately
• Request confirmation at the right time
• Handle tool errors without unsafe retries
• Preserve user constraints such as budget and delivery date

Monitoring

Log tool name, version, request identifier, authorisation scope, latency, outcome, and error class. Avoid logging sensitive payment data or unnecessary personal information. Use trace IDs to connect agent actions with backend events and customer support records.

A Practical Implementation Roadmap

A phased rollout reduces risk.

Phase 1: Read-only discovery

Expose catalogue search, product details, serviceability, policies, and order-status tools. Focus on accurate schemas and trustworthy responses.

Phase 2: User-state actions

Add carts, saved preferences, delivery quotes, and reservations. Introduce authentication, scopes, expiration, and audit trails.

Phase 3: Checkout preparation

Expose a quote or checkout-session tool that calculates the final payable amount. Require the agent to present a complete review summary.

Phase 4: Transaction execution

Add payment-session creation and order placement with explicit confirmation, idempotency, fraud controls, and robust recovery paths.

Phase 5: Network optimisation

Use real-world data to improve ranking, multilingual support, seller quality signals, delivery estimates, and tool performance across open-network participants.

Common Mistakes to Avoid

• Exposing a single unrestricted do_anything browser tool
• Treating search results as confirmed inventory
• Allowing the agent to place orders without final approval
• Returning prices without taxes, fees, or timestamps
• Passing raw payment credentials through the agent
• Trusting product-page instructions as system commands
• Omitting seller and fulfilment identity
• Retrying failed payments without idempotency
• Logging sensitive personal or financial information
• Designing tools around page buttons instead of stable commerce capabilities

Frequently Asked Questions

Can WebMCP replace existing commerce APIs?

Usually, it should complement them. WebMCP can provide an agent-friendly interface over existing catalogue, cart, order, payment, and fulfilment services while keeping authoritative business rules in the backend.

Can an AI agent complete a purchase automatically?

Technically, a system can support automated purchasing, but high-impact actions should require explicit user consent, strong authentication, risk controls, and clear disclosure of the final amount and terms.

Is WebMCP limited to one marketplace?

No. Its value is strongest when independent websites and commerce participants expose interoperable, structured capabilities. Each participant can retain its own policies while supporting common agent workflows.

How should merchants protect against malicious agents?

Use authentication, scoped permissions, rate limits, schema validation, server-side authorisation, fraud detection, idempotency keys, audit logs, and strict separation between untrusted page content and executable tool instructions.

What should Indian startups build first?

Start with read-only product discovery, serviceability, pricing, and order-status tools. Once data quality and security are proven, add carts, checkout quotes, payment sessions, and order placement with human confirmation.

Apply for AI Grants India

Building an agent-ready commerce product for India’s open digital ecosystem? Apply to AI Grants India for support, visibility, and opportunities to advance your AI startup.