AI shopping agents are moving from answering questions to completing research workflows: finding a product, comparing sellers, calculating the delivered cost and identifying the best purchase option. A WebMCP (Web Model Context Protocol) can provide the structured tools and browser capabilities an agent needs to perform that work across Indian e-commerce platforms—without forcing every model to understand a different website layout.
The hard part is not simply scraping product pages. A useful price-discovery system must resolve product identity, distinguish new from refurbished inventory, normalize Indian taxes and delivery charges, handle pincode-specific availability, preserve source evidence and operate within platform terms. This guide explains how to build that system with a WebMCP-oriented architecture.
What a WebMCP should do for price discovery
A WebMCP layer exposes website or commerce capabilities to AI agents through predictable, machine-readable tools. For price discovery, it should allow an agent to:
- Search for a product using natural-language requirements.
- Retrieve structured offers from multiple Indian marketplaces.
- Compare price, seller, condition, delivery, returns and warranty.
- Check availability for a user’s pincode or region.
- Open the source listing when verification is required.
- Explain why one offer is ranked above another.
The protocol layer should not make subjective purchase decisions invisibly. It should return normalized facts, confidence scores and citations so the agent can present a transparent comparison.
A practical contract might expose tools such as search_catalog, get_product_offers, check_delivery, estimate_landed_cost and get_offer_evidence. Each tool should define strict inputs, typed outputs, failure states and freshness metadata.
Scope the first version around a narrow shopping workflow
Do not begin by supporting every category and every marketplace. Select one high-value workflow, for example:
1. User provides a product query, budget and delivery pincode.
2. Agent identifies candidate products across supported sources.
3. System maps equivalent products using brand, model number, storage, colour and variant attributes.
4. Connectors retrieve current offers and delivery estimates.
5. Ranking computes the lowest reliable landed cost rather than the lowest headline price.
6. Agent returns a comparison with links and timestamps.
Electronics are often a good starting point because model numbers and specifications create stronger identity signals. Fashion is substantially harder because size, colour, catalogue duplication and return conditions create more ambiguity.
Define explicit exclusions for the MVP: no automatic checkout, no login handling, no CAPTCHA bypass, no hidden API reverse engineering and no claims that an offer is available unless the source confirms it.
Reference architecture for a WebMCP price agent
A robust implementation normally has six layers.
1. Agent orchestration layer
The agent interprets the user’s request and decides which tools to call. Use structured tool calls rather than asking the model to generate URLs or scrape instructions. The orchestrator should enforce budgets such as maximum marketplaces, request count, latency and retry attempts.
For example, the agent may first call parse_shopping_intent, then search_catalog in parallel, followed by resolve_product_identity and get_product_offers only for the strongest matches.
2. WebMCP tool server
The tool server presents stable capabilities to the agent. It should validate JSON input, authenticate requests, apply rate limits and return typed responses. Keep the protocol-facing schema independent from any one marketplace’s HTML or internal API.
A simplified tool definition could look like this:
{
"name": "search_catalog",
"description": "Find products matching a structured shopping request",
"inputSchema": {
"type": "object",
"required": ["query", "country"],
"properties": {
"query": {"type": "string"},
"brand": {"type": "string"},
"budget_inr": {"type": "number"},
"pincode": {"type": "string"},
"country": {"const": "IN"}
}
}
}The response should include stable identifiers, not only display text:
{
"products": [
{
"canonical_id": "asin-or-platform-id",
"title": "Example product",
"brand": "Example",
"model_number": "EX-100",
"variant": {"storage_gb": 128, "colour": "Black"},
"source": "marketplace",
"source_url": "https://example.com/item",
"observed_at": "2026-09-03T10:15:00Z"
}
]
}3. Marketplace connectors
Create one adapter per source. A connector should translate a normalized request into an approved source query and map the response into your internal offer schema. Keep parsing, retries and platform-specific error handling inside the adapter.
Potential sources may include Amazon India, Flipkart, Croma, Reliance Digital, Tata Neu, Myntra or category-specific retailers. Availability of official APIs, affiliate feeds and commercial data access varies. Use only permitted access methods and document the commercial basis for every connector.
4. Product identity and entity resolution
This is the core data problem. Two listings may describe the same product with different titles; conversely, similar titles may refer to different configurations. Build identity resolution in stages:
- Extract brand, manufacturer part number, model number, EAN/GTIN where available, capacity, RAM, storage, colour and generation.
- Normalize casing, punctuation, units and common Indian abbreviations.
- Give exact model or barcode matches the highest weight.
- Compare structured attributes before using title similarity.
- Treat missing attributes as unknown, not equal.
- Send low-confidence matches to an agent or human review path.
A simple score can combine exact identifiers, attribute agreement and semantic similarity:
identity_score = 0.45(identifier_match) + 0.35(attribute_match) + 0.20(title_similarity)
The weights should be category-specific and evaluated against labelled pairs. Never merge offers merely because the brand and product family match.
5. Normalization and ranking service
Indian price comparisons require more than an INR field. Normalize:
- Item price and seller discount.
- Platform or convenience fees.
- Delivery charges.
- Cash-on-delivery charges, if applicable.
- GST inclusion or exclusion.
- Coupon eligibility and payment-method restrictions.
- Exchange, subscription or bank-offer dependencies.
- Delivery date and pincode-specific availability.
- Return window, warranty and seller rating.
Use a clear landed-cost model:
landed_cost = item_price + delivery_fee + mandatory_fee - unconditional_discount
Keep conditional offers separate. For example, a bank discount should not reduce the default price unless the user meets the stated payment condition. Show both headline_price and estimated_landed_cost, with a list of assumptions.
6. Evidence and observability layer
Every offer should carry source evidence: URL, retrieval timestamp, extracted fields, source type and parser version. Store a content hash or structured snapshot where legally and operationally appropriate. This lets you detect stale results and investigate incorrect comparisons.
Track tool latency, error rate, empty-result rate, price-change frequency, parser failures, identity-resolution confidence and citation coverage. Logs should exclude payment data, unnecessary personal information and authentication secrets.
Designing the offer schema
A normalized offer object might include:
{
"canonical_product_id": "phone-abc-128-black",
"marketplace": "example_marketplace",
"seller": {
"name": "Example Seller",
"rating": 4.6
},
"price": {
"currency": "INR",
"item": 29999,
"delivery": 0,
"mandatory_fees": 0,
"landed_cost": 29999,
"conditional_discounts": []
},
"fulfilment": {
"pincode": "560001",
"availability": "in_stock",
"delivery_by": "2026-09-06"
},
"condition": "new",
"returns": {"days": 7, "restocking_fee": null},
"warranty": "manufacturer",
"source_url": "https://example.com/offer",
"observed_at": "2026-09-03T10:15:00Z",
"confidence": 0.94
}Use enums for fields such as condition and availability. Avoid putting free-form natural-language claims into fields that ranking logic depends on. Preserve raw source text separately for explanations and audits.
Handling major Indian marketplace differences
Indian platforms differ in catalogue structure, fulfilment, seller models and delivery calculation. Design connectors around these differences rather than assuming a universal product page.
- Amazon India: distinguish product-level information from seller-level offers; capture fulfilment and seller identity separately.
- Flipkart: preserve variant and seller context, as price and delivery can vary by selected configuration and pincode.
- Croma and Reliance Digital: account for store inventory, regional delivery and retailer warranty language.
- Tata Neu and other aggregators: identify whether the displayed offer is supplied by a partner retailer and avoid double-counting loyalty benefits.
- Myntra and fashion platforms: treat size and colour as mandatory identity attributes; a product-level lowest price can be misleading.
Do not hard-code assumptions that a listing is nationally available. Delivery, stock and fees may change based on pincode, account state, time and fulfilment location.
Compliance, permissions and user trust
A WebMCP price-discovery product should be designed for compliance from day one. Review each platform’s terms, robots directives, API agreement, affiliate requirements and restrictions on automated access. Prefer official APIs, licensed feeds, affiliate programmes or explicit commercial partnerships.
Important controls include:
- Do not bypass CAPTCHA, authentication barriers, access controls or technical restrictions.
- Do not create fake accounts or simulate user actions without authorization.
- Respect rate limits and cache results where permitted.
- Clearly disclose affiliate relationships and sponsored placements.
- Provide source links and retrieval timestamps.
- Avoid storing names, addresses, phone numbers or payment details unless strictly necessary and consented.
- Apply India’s Digital Personal Data Protection Act obligations where personal data is processed, including purpose limitation, security safeguards and appropriate notices.
For autonomous actions, separate read-only discovery from transaction execution. Price comparison can usually remain read-only; checkout should require explicit user confirmation and a separate security design.
Agent safety and prompt-injection defenses
Marketplace pages can contain seller text, reviews or embedded content that attempts to influence an agent. Treat all retrieved page content as untrusted data. The connector should extract permitted fields and label them as source content; it should never allow a listing to redefine tool instructions.
Use these safeguards:
- Keep system and tool instructions outside retrieved content.
- Restrict tool outputs to a schema and maximum length.
- Strip scripts, hidden text and irrelevant markup.
- Validate URLs against approved domains.
- Require confirmation before opening external links or taking actions.
- Detect conflicting prices and downgrade confidence rather than guessing.
The agent should say when no exact match was found, when a price is conditional or when delivery could not be verified.
Evaluation: measure accuracy, not just tool calls
Build a benchmark of real Indian shopping queries covering brands, model numbers, Hindi-English phrasing, misspellings, budgets, pincodes and ambiguous variants. Label:
- Search recall: did the system find the relevant product?
- Identity precision: were equivalent products correctly grouped?
- Price accuracy: does normalized cost match the source?
- Availability accuracy: was pincode-specific stock correct?
- Citation completeness: can each important claim be verified?
- Freshness: how old are returned observations?
- Safety: did the agent avoid unauthorized actions?
Test adversarially with near-identical models, fake discounts, unavailable pincodes, contradictory seller claims and pages containing prompt-injection text. Include regression tests for every connector because small layout changes can silently corrupt price fields.
Performance and production operations
Parallelize independent marketplace searches, then limit deep offer retrieval to likely matches. Cache catalog metadata longer than volatile price and inventory fields. Use circuit breakers when a source is failing, and return partial results with an explicit coverage message instead of fabricating completeness.
A practical freshness policy might be:
- Search results: cache for minutes, depending on source permission.
- Price and stock: revalidate before showing a final recommendation.
- Delivery estimate: verify using the user’s pincode.
- Product specifications: cache longer but refresh when source data changes.
Set budgets for tokens, connector requests and total latency. A smaller, reliable result set is more useful than dozens of stale offers.
Recommended implementation roadmap
Phase 1: Foundation
Choose one category, two permitted sources and a read-only use case. Define schemas, source evidence, pincode handling and a labelled identity dataset.
Phase 2: Connector quality
Implement adapters with contract tests, rate limiting, retries and parser monitoring. Compare extracted values against manually verified pages or licensed API responses.
Phase 3: Agent integration
Expose tools through your WebMCP server, add tool-selection instructions, enforce schemas and build citation-aware response templates.
Phase 4: Ranking and personalization
Add landed-cost ranking, delivery preferences, warranty weighting and budget constraints. Keep sponsored or affiliate ranking rules clearly separated from relevance ranking.
Phase 5: Scale and governance
Expand categories and marketplaces only after measuring identity accuracy and source stability. Introduce human review for low-confidence matches, formal incident response and periodic compliance audits.
Common mistakes to avoid
- Comparing titles instead of product identities.
- Treating an exchange price or bank offer as the universal price.
- Ignoring delivery pincode and seller-level stock.
- Returning a single “best” result without showing assumptions.
- Scraping first and checking permissions later.
- Allowing page text to influence agent instructions.
- Failing silently when a connector breaks.
- Storing excessive user or browsing data.
- Building checkout automation before read-only accuracy is proven.
FAQ
What is a WebMCP in an AI shopping workflow?
It is a structured tool interface that lets an AI agent access approved web or commerce capabilities, such as search, offer retrieval and delivery checks, through predictable inputs and outputs.
Can I scrape Amazon India or Flipkart for price comparison?
Access depends on each platform’s terms, technical controls and commercial permissions. Prefer official APIs, licensed feeds, affiliate programmes or written partnerships, and never bypass access controls.
How do I compare prices fairly in India?
Normalize item price, mandatory fees, delivery, unconditional discounts, seller identity, condition and pincode-specific availability. Keep conditional bank, coupon, exchange and loyalty benefits clearly labelled.
Should the agent automatically purchase the cheapest item?
No. Start with read-only discovery and require explicit user confirmation for any transaction. The cheapest listing may have different warranty, seller, delivery or return conditions.
What is the hardest technical problem?
Product identity resolution is usually the most difficult. Correctly matching variants across inconsistent catalogues is essential before any price ranking is trustworthy.
Apply for AI Grants India
Building a compliant WebMCP or AI agent for Indian commerce? Apply to AI Grants India for support, visibility and potential grant opportunities for ambitious Indian AI founders.