0tokens

Apply for AI Grants India

Financial support for innovators building the future of AI in India.

Apply now

Chat · how to build a webmcp for agents to track fuel price changes across major indian cities daily

How to Build a WebMCP for Agents to Track Fuel Price Changes Across Major Indian Cities Daily

  1. aigi

    Fuel prices in India change frequently enough to justify automated monitoring, but the data is fragmented across oil marketing company websites, city-level pages, APIs, and news reports. If an AI agent must answer whether petrol or diesel prices changed today in Delhi, Mumbai, Bengaluru, Chennai, Hyderabad, Kolkata, Pune, or another city, it needs more than a web scraper. It needs a structured, auditable interface for discovery, retrieval, comparison, and alerts.

    This guide explains how to build a WebMCP for agents to track fuel price changes across major Indian cities daily. The design focuses on tool schemas, source validation, Indian fuel-price conventions, change detection, scheduling, security, and operational reliability.

    What Is a WebMCP for Fuel-Price Agents?

    A WebMCP is a web-accessible Model Context Protocol interface that exposes trusted tools and resources to AI agents. Instead of asking an agent to browse arbitrary pages, you publish well-defined capabilities such as:

    • Fetch today’s petrol and diesel prices for one or more Indian cities.
    • Compare today’s price with yesterday’s price.
    • Retrieve a historical time series.
    • Detect cities with a price change.
    • Return the source, retrieval time, confidence, and data-quality status.

    The MCP layer should sit between data collection systems and agents. A typical architecture is:

    1. Collectors retrieve data from approved sources.
    2. Normalizers convert city names, fuel types, currencies, and units into canonical values.
    3. Validators check freshness, plausibility, and source agreement.
    4. Storage retains current and historical observations.
    5. WebMCP tools expose safe query operations.
    6. Agents and notification services consume the tools.

    This separation prevents an agent from directly scraping websites during every conversation. It also makes answers reproducible: the system can state which source supplied a value and when it was collected.

    Define the Daily Fuel-Price Scope in India

    Before writing code, define exactly what “fuel price change” means. For a useful first version, track:

    • Petrol price per litre.
    • Diesel price per litre.
    • Major Indian cities and union-territory capitals.
    • India Standard Time, using Asia/Kolkata.
    • Observation date and retrieval timestamp.
    • Source URL or source identifier.
    • Whether the value is official, secondary, estimated, or unavailable.

    A practical starter city set may include Delhi, Mumbai, Kolkata, Chennai, Bengaluru, Hyderabad, Ahmedabad, Pune, Jaipur, Lucknow, Chandigarh, Patna, Bhopal, Bhubaneswar, Guwahati, Kochi, Thiruvananthapuram, and Srinagar. Store the city and state separately because similarly named locations can exist in multiple states.

    Do not assume that every source publishes the same concept. Some pages show a retail selling price, some show a current indicative value, and some show a timestamped update. Your schema must preserve the source semantics rather than silently treating all values as equivalent.

    Design the Data Model First

    A normalized observation should contain enough information for an agent to answer both “what is today’s price?” and “why do you believe it?” For example:

    {
  "city_id": "in-ka-bengaluru",
  "city_name": "Bengaluru",
  "state": "Karnataka",
  "fuel_type": "petrol",
  "price_inr_per_litre": 101.94,
  "observed_for_date": "2026-09-03",
  "retrieved_at": "2026-09-03T06:15:22+05:30",
  "timezone": "Asia/Kolkata",
  "source": {
    "id": "approved-source-1",
    "url": "https://example.gov.in/fuel-prices",
    "type": "official"
  },
  "status": "verified",
  "confidence": 0.98
}

    Use a relational table or document collection with a uniqueness constraint on:

    (city_id, fuel_type, observed_for_date, source_id)

    Recommended additional fields include:

    • currency: always INR for this use case.
    • unit: litre.
    • raw_value: the originally parsed string.
    • parser_version: useful when extraction rules change.
    • content_hash: detects unchanged source content.
    • validation_errors: structured failure details.
    • created_at and updated_at.

    For comparison, calculate changes explicitly rather than asking the agent to do arithmetic from prose:

    {
  "current_price": 94.77,
  "previous_price": 94.77,
  "change_inr": 0.0,
  "change_percent": 0.0,
  "direction": "unchanged",
  "comparison_date": "2026-09-02"
}

    Round only for display. Preserve decimal precision in storage, and use decimal arithmetic instead of binary floating-point arithmetic for prices.

    Build a Reliable Collection Pipeline

    The collection job should run daily in Indian Standard Time, preferably with a controlled window rather than assuming that midnight means a new price. A scheduler such as Celery Beat, GitHub Actions, Cloud Scheduler, Kubernetes CronJob, or a managed workflow service can trigger the process.

    A robust pipeline has these stages:

    1. Fetch

    Request each approved source with timeouts, retry limits, exponential backoff, and a descriptive user agent. Respect robots.txt, terms of service, authentication requirements, and rate limits. Cache responses when permitted.

    2. Parse

    Prefer structured data such as JSON-LD, embedded JSON, stable APIs, or documented feeds. Use HTML selectors only when necessary. Avoid brittle selectors based solely on visual CSS classes. Capture the raw response or a redacted evidence snapshot for auditability.

    3. Normalize

    Map variations such as Bangalore and Bengaluru to one canonical city ID. Normalize fuel labels including petrol, motor spirit, diesel, and local-language equivalents. Reject values containing tax explanations or multiple prices unless the parser can identify the retail price unambiguously.

    4. Validate

    Apply checks for:

    • Valid city and fuel type.
    • Positive INR-per-litre value.
    • Expected decimal precision.
    • Fresh observation date.
    • No implausible jump without an explanation.
    • Source page matching the requested city.
    • Agreement between duplicate sources when available.

    5. Persist

    Write immutable observations and separately maintain a current-price view. Never overwrite historical values without retaining the prior record. Idempotency is essential: rerunning the same collection job should not create duplicate daily observations.

    Create MCP Tools That Agents Can Use Safely

    Keep tools narrow, deterministic, and explicit. Avoid one large tool such as browse_fuel_websites, because it encourages uncontrolled browsing and makes results difficult to validate.

    A useful tool set includes:

    get_fuel_prices

    Returns current or date-specific prices for selected cities and fuel types.

    Suggested input:

    {
  "cities": ["Delhi", "Mumbai", "Bengaluru"],
  "fuel_types": ["petrol", "diesel"],
  "date": "2026-09-03",
  "include_sources": true
}

    Validate city IDs server-side. Do not accept arbitrary URLs or SQL-like filters from the agent.

    compare_fuel_prices

    Compares two dates or compares today with the previous available observation. Return absolute and percentage changes, while clearly representing missing data.

    {
  "cities": ["Delhi", "Mumbai"],
  "fuel_type": "petrol",
  "from_date": "2026-09-02",
  "to_date": "2026-09-03"
}

    list_changed_cities

    Returns only cities where the price changed above a configurable threshold. The default threshold should be zero for exact price changes, with an optional minimum such as ₹0.01.

    get_fuel_price_history

    Returns a bounded time series. Enforce a maximum range, such as 365 days, to prevent expensive requests.

    get_data_quality_status

    Reports stale sources, missing cities, source conflicts, parser failures, and the last successful collection run. Agents need this tool to avoid presenting incomplete data as comprehensive.

    Example WebMCP Tool Contract

    A tool response should be machine-readable and concise:

    {
  "as_of": "2026-09-03T06:20:00+05:30",
  "timezone": "Asia/Kolkata",
  "results": [
    {
      "city_id": "in-dl-delhi",
      "city_name": "Delhi",
      "fuel_type": "petrol",
      "price_inr_per_litre": 94.77,
      "previous_price_inr_per_litre": 94.77,
      "change_inr": 0.0,
      "direction": "unchanged",
      "status": "verified",
      "source_id": "approved-source-1",
      "retrieved_at": "2026-09-03T06:15:22+05:30"
    }
  ],
  "warnings": []
}

    Include a schema version, such as fuel-price.v1, so clients can evolve safely. Distinguish these states:

    • verified: passed freshness and validation checks.
    • stale: last known value is older than the freshness policy.
    • conflict: approved sources disagree.
    • unavailable: no reliable value exists.
    • invalid: a source returned data that failed validation.

    An agent should never infer that unavailable means zero, unchanged, or unavailable nationwide.

    Handle Daily Scheduling and Freshness Correctly

    “Daily” does not necessarily mean one request at 00:00. Define a collection policy such as:

    • Start collection at 06:00 IST.
    • Retry failed sources at 06:30 and 07:00 IST.
    • Mark data stale after a fixed number of hours.
    • Store the source’s publication or effective date separately from retrieval time.
    • Freeze the daily comparison only after the collection window closes.

    If a source updates at a different time, retain multiple intraday observations but designate one canonical daily observation. This prevents a late update from being confused with a collection failure.

    Use monitoring metrics including collection success rate, source latency, parse failure rate, stale-city count, duplicate rate, and source disagreement rate. Alert operators when a whole source suddenly returns the same price for every city or when a parser extracts a page-wide number instead of a city-specific value.

    Source Strategy and Legal Considerations

    For India-specific fuel data, prioritize authoritative or contractually permitted sources. Oil marketing company systems, government-linked datasets, licensed providers, and documented APIs are preferable to copying content from arbitrary aggregators.

    Before production deployment:

    • Review terms of service and licensing.
    • Confirm whether automated access is allowed.
    • Respect robots.txt where applicable.
    • Avoid bypassing CAPTCHAs, authentication, or technical controls.
    • Attribute sources in agent responses when required.
    • Store only the evidence needed for verification.

    If no official API is available, use a licensed data provider or obtain permission for a narrowly scoped collector. A technically successful scraper can still be unsuitable for a public product if the data rights are unclear.

    Security, Rate Limits, and Abuse Prevention

    A public WebMCP endpoint is an API and must be secured like one. Apply:

    • Authentication for write operations and administrative tools.
    • Read-only permissions for ordinary agent clients.
    • Per-client rate limits.
    • Maximum city count and date range.
    • Input validation against allowlists.
    • Response-size limits.
    • Structured logging with secrets removed.
    • Circuit breakers for failing upstream sources.

    Never expose a tool that accepts arbitrary source URLs, shell commands, database queries, or unrestricted browser instructions. The agent should query your curated dataset, not turn your MCP server into an SSRF proxy or scraping relay.

    Agent Instructions for Accurate Answers

    Tool quality is only half the system. Give consuming agents clear instructions:

    • Always include the “as of” timestamp and timezone.
    • Say “no change recorded” only when both comparison observations are valid.
    • Mention missing or stale cities explicitly.
    • Show prices in ₹ per litre.
    • Do not claim nationwide trends from a partial city list.
    • Cite source identifiers or links where appropriate.
    • Ask a clarification question when the user names an ambiguous city.
    • Separate petrol from diesel and never substitute one for the other.

    For example, an agent answer should say: “As of 6:20 AM IST on 3 September, petrol in Delhi was ₹X per litre, unchanged from the previous available observation. Source data was retrieved at 6:15 AM IST.” That is substantially more useful than a bare number.

    Testing the WebMCP Before Launch

    Test at three levels. Unit tests should cover city aliasing, decimal parsing, date handling, percentage calculations, and fuel-type normalization. Integration tests should use recorded fixtures for source pages, including changed layouts, missing values, duplicate labels, and non-English text. End-to-end tests should verify that an agent can request prices, interpret warnings, and cite freshness correctly.

    Important edge cases include:

    • A source updates one city but not another.
    • The previous day’s record is missing.
    • A price is returned with a comma decimal separator.
    • A page displays separate regular and premium fuels.
    • A city name has changed or has multiple spellings.
    • A source returns HTTP 200 with an error page.
    • Two sources disagree by a small amount.
    • The daily job runs twice after a timeout.

    Use contract tests for the MCP schema so clients are notified before a breaking field change reaches production.

    A Practical MVP Roadmap

    Build the first version in stages:

    1. Select 10–20 cities and petrol/diesel only.
    2. Implement one permitted, dependable source.
    3. Store immutable daily observations in PostgreSQL or another durable database.
    4. Add validation, freshness states, and comparison calculations.
    5. Expose read-only MCP tools with JSON schemas.
    6. Add a second source for cross-checking, not merely more coverage.
    7. Add dashboards and alerts for stale or conflicting data.
    8. Expand city coverage after measuring parser reliability.

    This approach is better than launching with every Indian city and an unreliable scraper. Accuracy, provenance, and clear failure states matter more than raw coverage when agents are making user-visible claims.

    FAQ: WebMCP Fuel Price Tracking in India

    Can an AI agent scrape fuel prices directly every morning?

    It can, but a centralized WebMCP is safer and more reliable. It provides controlled access, caching, validation, provenance, and consistent schemas instead of exposing the agent to arbitrary web pages.

    How often should the collector run?

    Run an initial collection during your chosen IST window and use retries or scheduled refreshes for late source updates. Store retrieval time and effective date separately.

    Should I track premium petrol and CNG too?

    Add them only after petrol and diesel are stable. They require distinct fuel-type identifiers, unit rules, and source validation because availability and naming vary by city.

    What should happen when a city’s data is missing?

    Return an explicit unavailable or stale status, include the last valid observation if appropriate, and make the limitation visible to the agent and end user.

    Is a WebMCP the same as a public API?

    Not exactly. A WebMCP is designed for model and agent tool use, but it still needs API-grade authentication, validation, rate limits, monitoring, and versioning.

    Apply for AI Grants India

    Building an India-focused agent infrastructure product, data pipeline, or WebMCP can benefit from the right grant and ecosystem support. Apply through AI Grants India to explore funding opportunities for your Indian AI startup.

AIGI may be inaccurate. Replies seeded from the guide above.