Apply for AI Grants India

WebMCP can make it easier for new e-commerce storefronts to participate in India’s Open Network for Digital Commerce (ONDC) by connecting AI agents and browser-based workflows to structured commerce capabilities. Instead of treating ONDC as a separate marketplace to build from scratch, a startup can expose catalog, discovery, cart, order, payment, fulfilment, and support functions through controlled tools that an AI assistant can invoke. The result is a storefront that remains useful to human shoppers while becoming discoverable and operable through agentic interfaces.

The key is to separate responsibilities clearly: ONDC defines the network protocols and participant roles; the storefront owns its commerce systems; and WebMCP provides a governed interface through which compatible AI clients can use selected storefront capabilities. A successful implementation therefore requires more than adding an AI chatbot. It needs protocol mapping, identity and consent controls, reliable APIs, observability, and compliance with ONDC and Indian e-commerce requirements.

What WebMCP Means for E-Commerce

WebMCP refers to a web-based model context protocol approach in which websites expose structured tools and context to AI models or agents. A tool might allow an agent to search products, retrieve delivery estimates, add an item to a cart, or check an order. Rather than asking an AI model to infer how a website works from HTML, WebMCP-style integrations provide explicit, machine-readable actions with defined inputs, outputs, and permissions.

For an e-commerce storefront, this can create an agent-accessible commerce layer containing tools such as:

• search_catalog for product discovery and filtering
• get_product for specifications, inventory, price, and seller information
• quote_fulfilment for serviceability and delivery estimates
• create_cart and add_to_cart for shopping-session management
• create_order for order placement after customer confirmation
• get_payment_options for supported payment flows
• track_order for post-purchase support
• request_cancellation or request_return where policy permits

These tools should not bypass the storefront’s existing business logic. They should call the same validated services used by the website and mobile application, ensuring that price calculations, inventory checks, promotions, tax treatment, and fulfilment rules remain consistent.

Understanding ONDC’s Protocol Model

ONDC is a network rather than a single marketplace application. Its ecosystem separates functions between roles such as buyer network participants, seller network participants, gateways, logistics providers, and other service providers. ONDC transactions generally use network APIs and protocol specifications based on defined discovery, transaction, and post-transaction flows.

A typical retail journey may include:

1. A buyer initiates a search using a buyer-side application.
2. The request is broadcast or routed to relevant seller-side participants.
3. Sellers return catalog and availability responses.
4. The buyer selects an item and proceeds through quotation, order, payment, and fulfilment steps.
5. Status updates, cancellations, returns, and support events are exchanged after purchase.

A new storefront must determine whether it will participate as an ONDC seller-side application, work through an ONDC technology service provider, or use another approved integration model. WebMCP does not replace that decision. It can sit above the storefront and seller-side infrastructure, helping an AI agent use capabilities that eventually trigger ONDC-compliant operations.

Reference Architecture: WebMCP Above an ONDC Adapter

A practical architecture uses multiple layers rather than connecting an AI agent directly to ONDC message endpoints.

1. Agent and WebMCP layer

This layer publishes a carefully selected set of tools. Each tool should include a clear description, JSON schema for parameters, expected output fields, authentication requirements, and failure conditions. For example, a product-search tool may accept category, location, price range, brand, and availability filters.

2. Commerce orchestration layer

The orchestration service manages sessions, carts, customer identity, consent, idempotency, and workflow state. It translates a natural-language request such as “find a vegetarian meal kit under ₹1,000 delivered to Bengaluru tomorrow” into validated search and fulfilment operations.

3. Storefront commerce services

These services handle catalog management, pricing, promotions, inventory, tax calculations, customer accounts, payments, order management, and support. Existing platforms can often be retained if they provide stable APIs or webhooks.

4. ONDC adapter or seller-side integration

The adapter maps internal product and order models to ONDC protocol messages. It also validates incoming events, signs or authenticates requests as required by the chosen integration, handles callbacks, and translates ONDC responses into internal entities.

5. External providers

These may include payment gateways, logistics providers, tax services, warehouse systems, CRM tools, and fraud-prevention platforms. They should be integrated behind stable interfaces so that WebMCP tools do not contain provider-specific logic.

The data flow should be explicit: the agent calls a WebMCP tool, the orchestration layer validates the request, the commerce service performs the operation, and the ONDC adapter communicates with network participants when the transaction requires it. This design prevents an AI client from sending arbitrary protocol messages or accessing sensitive internal systems.

Mapping Storefront Functions to ONDC Workflows

The hardest implementation task is mapping a conversational action to a complete business workflow. A “buy this product” request may require much more than one API call.

Discovery and search

The storefront should normalize ONDC catalog responses into a consistent product model. Important fields can include product identifier, seller, category, price, tax, inventory status, location, fulfilment options, return policy, and applicable charges. Agents must receive enough context to compare products accurately without inventing missing attributes.

Search results should also preserve provenance. If a result came from an ONDC seller participant, the system should retain the seller and quote identifiers needed for later selection and order creation.

Product selection and quotation

The agent should not create an order from stale search data. A product-selection tool should verify the current quote, inventory, delivery area, fees, and applicable policies. Prices and delivery estimates should be treated as time-sensitive and revalidated before checkout.

Cart and order creation

Cart operations require session binding. A cart should be associated with an authenticated customer or an explicitly authorized guest session. When an agent calls create_order, the orchestration layer should require confirmation of the final items, total amount, delivery address, payment method, and relevant terms.

Use idempotency keys for order creation. If the agent retries because of a timeout, the system must avoid duplicate orders or duplicate payment attempts.

Payment

WebMCP should not expose raw card numbers, UPI credentials, bank passwords, or payment secrets to a model. It should initiate a secure payment handoff or return a checkout session URL/token that is scoped, short-lived, and bound to the order and customer. The payment provider remains responsible for sensitive payment data and authentication flows.

Fulfilment and post-order support

Order tracking tools should return reliable states such as confirmed, packed, out for delivery, delivered, cancelled, or return initiated. Cancellation and return tools must check eligibility, time windows, seller policies, payment status, and fulfilment status before performing an action.

Designing Safe WebMCP Tools

AI agents can misinterpret ambiguous instructions, select the wrong product, or repeat an operation. Tool design should therefore follow the principle of least privilege.

Recommended controls include:

• Separate read tools from write tools.
• Require explicit customer confirmation before order placement.
• Display the final price, taxes, delivery fee, seller, and delivery address.
• Use scoped tokens instead of broad API credentials.
• Validate every tool argument server-side.
• Enforce rate limits and abuse detection.
• Add idempotency to payments, orders, cancellations, and returns.
• Log the user instruction, tool call, authorization decision, and result.
• Redact personal data and payment information from logs.
• Block tools from changing catalog, pricing, inventory, or seller settings unless separately authorized.

A good tool response should be structured and concise. It should identify whether an action succeeded, failed, or needs user input. Error messages should provide a safe next step rather than exposing stack traces, internal endpoints, or protocol credentials.

Identity, Consent, and Indian Compliance

An India-focused storefront must consider privacy, consumer protection, tax, payments, and platform obligations from the beginning. The Digital Personal Data Protection Act, 2023 and related rules require organizations to handle personal data responsibly, including notice, purpose limitation, security safeguards, and appropriate user rights processes as applicable.

For WebMCP and ONDC workflows, implement:

• Clear consent and disclosure for AI-assisted shopping.
• Purpose-specific access to name, phone number, address, and order data.
• Data minimization for agent context.
• Customer controls to revoke sessions and connected applications.
• Retention and deletion policies for conversations and tool logs.
• Human support escalation for disputes and sensitive requests.
• Accurate seller, product, price, refund, and delivery disclosures.

The storefront should also review GST treatment, invoicing, consumer grievance requirements, return and refund rules, and payment-security obligations. ONDC participation may involve additional operational requirements and certification or onboarding steps. Confirm current specifications and participant obligations with ONDC documentation and your integration provider because protocols and ecosystem practices can evolve.

Technical Implementation Plan

A phased rollout reduces risk.

Phase 1: Audit the commerce stack

Document the current catalog, inventory, checkout, order, payment, logistics, and support APIs. Identify which systems are authoritative for price, stock, customer identity, and order status. Resolve duplicate or inconsistent data before adding agent access.

Phase 2: Build the ONDC integration boundary

Implement or select the seller-side adapter. Define mappings for product IDs, seller IDs, locations, fulfilment terms, taxes, order states, and cancellation or return codes. Add contract tests using representative discovery and transaction payloads.

Phase 3: Create read-only WebMCP tools

Start with catalog search, product details, serviceability, and order tracking. Test whether agents can complete discovery without hallucinating attributes or confusing sellers and variants.

Phase 4: Add controlled transactional tools

Introduce cart, quote, checkout, and order tools only after authentication, confirmation, idempotency, and payment handoff controls are proven. Begin with a limited category, geography, or customer cohort.

Phase 5: Monitor and optimize

Track tool success rate, protocol error rate, search-to-cart conversion, cart abandonment, duplicate-order incidents, payment failures, cancellation rate, delivery SLA, support escalations, and customer complaints. Review failed conversations to improve schemas and tool descriptions, not merely prompts.

Common Integration Mistakes

Treating WebMCP as a replacement for ONDC integration

WebMCP is an interaction and tool-access layer. It does not make a storefront an ONDC participant automatically. The business still needs an approved network integration and correct seller-side operations.

Exposing website scraping instead of business tools

Screen scraping is fragile and can produce incorrect prices, unavailable products, or broken checkout flows. Stable, versioned APIs and explicit tools are more reliable.

Allowing autonomous checkout without confirmation

A natural-language request may be ambiguous. The system should confirm the exact product variant, quantity, seller, total amount, delivery address, and payment action before creating an order.

Ignoring asynchronous events

ONDC and fulfilment workflows can involve callbacks and delayed status updates. Build event handling, retries, dead-letter queues, reconciliation jobs, and customer notifications.

Returning unverified information to agents

Never let a model infer stock, delivery time, refund eligibility, or seller policy from incomplete data. Return structured values with timestamps and source identifiers.

Benefits for New Indian E-Commerce Startups

When implemented correctly, WebMCP and ONDC can give startups several advantages:

• A single storefront can serve human shoppers and AI-assisted buying journeys.
• ONDC connectivity can expand reach beyond a proprietary marketplace audience.
• Structured tools make catalog and order operations easier to automate.
• A shared commerce API reduces duplicated logic across web, mobile, and agent channels.
• Conversational discovery can improve product comparison for complex catalogs.
• Smaller teams can automate routine tracking, support, and reordering workflows.

These benefits depend on operational quality. Accurate inventory, dependable fulfilment, transparent policies, and responsive support matter more than adding an agent interface quickly.

WebMCP and ONDC Integration Checklist

Before launch, verify that you have:

• A clear ONDC participant and integration strategy.
• A canonical product, seller, price, inventory, and order data model.
• Versioned APIs between WebMCP, orchestration, commerce, and ONDC layers.
• Authentication, authorization, consent, and customer-session controls.
• Confirmation and idempotency for all financial or irreversible actions.
• Secure payment redirection or tokenized payment flows.
• Support for asynchronous callbacks, retries, and reconciliation.
• Privacy, consumer-protection, GST, refund, and grievance processes.
• Monitoring for protocol, payment, fulfilment, and agent errors.
• A human escalation path for exceptions and disputes.

Frequently Asked Questions

Can WebMCP connect directly to ONDC APIs?

It can technically be placed near an ONDC integration, but direct model access to network endpoints is not recommended. Use a secure orchestration layer and ONDC adapter that validates permissions, protocol messages, identity, and transaction state.

Do I need to rebuild my existing e-commerce website?

Usually not. If your storefront has reliable catalog, cart, checkout, payment, and order APIs, WebMCP tools can call those services while an ONDC adapter handles network-specific mapping.

Is WebMCP the same as an ONDC buyer or seller application?

No. ONDC defines network participation and commerce protocols. WebMCP exposes selected web capabilities to compatible AI clients. A business still needs the appropriate ONDC integration and operational setup.

What should be automated first?

Begin with read-only product discovery, serviceability, and order tracking. Add cart and checkout only after authentication, confirmation, payment security, idempotency, and monitoring are in place.

How can founders reduce AI-related order errors?

Use strict schemas, server-side validation, current quote checks, explicit confirmation screens, scoped permissions, idempotency keys, and audit logs. Do not rely on prompts alone to enforce transactional safety.

Apply for AI Grants India

Building an AI-native storefront or ONDC integration in India? Apply to AI Grants India for support, visibility, and opportunities designed for Indian AI founders.