How to Use WebMCP for Live DISCOM Data

Electricity consumption data is valuable for energy-management agents, rooftop-solar analysis, demand forecasting, bill assistance, and public-sector workflows. Yet Indian state DISCOM portals are not uniform: some expose APIs, others rely on authenticated dashboards, CAPTCHA, dynamic JavaScript, or downloadable statements. WebMCP can provide a structured bridge between an AI agent and these web capabilities, but it should be implemented as a controlled, consent-based data-access layer—not as unrestricted browser automation.

This guide explains how to use WebMCP to enable agents to fetch live electricity consumption data from state DISCOM portals, with an India-aware architecture covering authentication, tool design, data normalization, security, compliance, reliability, and deployment.

What WebMCP Means in This Use Case

WebMCP is best understood as a model-context interface for web capabilities. Instead of asking an agent to guess how a portal works, you expose narrowly defined tools that describe:

What action is available
Which inputs are required
What data the action returns
What permissions or user confirmation are needed
What errors can occur

For a DISCOM integration, the agent should not receive a generic “browse this website” capability. It should receive typed operations such as:

list_linked_meters
get_consumption_summary
get_daily_consumption
get_monthly_consumption
get_latest_bill
get_meter_reading_status

The WebMCP layer then maps these operations to an approved connector for a specific DISCOM portal. This separation makes the system easier to secure, test, audit, and replace when a portal changes.

Why State DISCOM Portals Are Difficult to Integrate

Indian DISCOMs use different technology stacks, data models, and customer journeys. A production-grade integration must account for variation in:

Consumer number, account ID, CA number, K number, service connection number, or installation ID
State-specific login and OTP flows
Multiple portals for bills, prepaid meters, net metering, and rooftop solar
Separate urban and rural systems
HTML pages, JavaScript applications, mobile APIs, or downloadable PDFs
Billing-cycle consumption instead of daily interval data
Smart-meter data available through a separate platform
Regional-language labels and inconsistent date formats
Temporary downtime, maintenance pages, rate limits, and bot protection

“Live” also needs a precise definition. It may mean the latest smart-meter interval, the latest meter reading uploaded by a field worker, the current billing-period total, or the latest statement available in the portal. Your WebMCP schema should expose the actual freshness timestamp and source status rather than implying real-time accuracy.

Recommended Architecture

A robust design uses five layers:

1. AI agent — Interprets the user’s request and selects an approved WebMCP tool.
2. WebMCP tool server — Validates arguments, applies policy, requests consent, and returns structured data.
3. DISCOM connector — Handles a particular portal’s API, browser session, or document workflow.
4. Credential and consent service — Stores tokens or session references securely and records authorization.
5. Normalization and observability layer — Converts portal-specific responses into a common energy schema and records freshness, errors, and provenance.

A typical request flow is:

User asks for consumption
        ↓
Agent selects get_consumption_summary
        ↓
WebMCP validates meter and date range
        ↓
Consent/policy check
        ↓
DISCOM connector retrieves approved data
        ↓
Normalizer validates units and timestamps
        ↓
Agent explains result with source and freshness

Keep credentials out of the model context. The agent should receive a reference to an authorized account or meter, not passwords, OTPs, cookies, or raw access tokens.

Define a Canonical Consumption Schema

Different portals may return kilowatt-hours, cumulative readings, billing totals, or interval records. Normalize them into a schema such as:

{
  "utility": "example_discom",
  "state": "Karnataka",
  "consumer_reference": "masked-or-internal-id",
  "meter_id": "masked-meter-id",
  "period_start": "2026-08-01T00:00:00+05:30",
  "period_end": "2026-08-31T23:59:59+05:30",
  "consumption_kwh": 284.6,
  "reading_type": "interval_aggregate",
  "granularity": "daily",
  "currency": "INR",
  "source_updated_at": "2026-09-01T08:15:00+05:30",
  "retrieved_at": "2026-09-03T10:30:00+05:30",
  "quality": "portal_confirmed",
  "provenance": {
    "connector_version": "discom-x-1.4.0",
    "source": "authenticated_portal"
  }
}

Important fields include:

Unit: Prefer kWh; distinguish kW demand from kWh energy.
Timezone: Use Asia/Kolkata and preserve the original portal timestamp.
Granularity: Identify interval, hourly, daily, monthly, or billing-cycle data.
Freshness: Return both source update time and retrieval time.
Quality: Indicate whether the value is estimated, provisional, corrected, or confirmed.
Provenance: Record the connector and source without exposing secrets.

Never silently convert a cumulative meter reading into consumption without checking rollover, reset, multiplication factor, and meter replacement events.

Design WebMCP Tools for Least Privilege

A good tool has a narrow purpose and explicit input constraints. For example:

{
  "name": "get_consumption_summary",
  "description": "Retrieve authorized electricity consumption for a linked meter.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "meter_ref": {"type": "string"},
      "start_date": {"type": "string", "format": "date"},
      "end_date": {"type": "string", "format": "date"},
      "granularity": {
        "type": "string",
        "enum": ["day", "month", "billing_cycle"]
      }
    },
    "required": ["meter_ref", "start_date", "end_date", "granularity"],
    "additionalProperties": false
  }
}

Apply limits such as:

Maximum date range, for example 12 months
Only meters linked to the authenticated user
Read-only access for consumption tools
No arbitrary URL input from the model
No password reset, account modification, or bill-payment actions in the same tool
Explicit confirmation for sensitive exports or sharing

Return structured errors, including AUTH_REQUIRED, CONSENT_REQUIRED, NO_DATA, PORTAL_UNAVAILABLE, RATE_LIMITED, and DATA_STALE. This lets the agent communicate accurately instead of inventing a result.

Authentication and Consent in India

Authentication design is the most sensitive part of the integration. Consumer numbers alone are not sufficient authorization. Prefer an account-linking flow in which the user signs in directly to the approved DISCOM portal or completes an authorized OAuth-like connection where available.

For portals that use OTP:

Send the OTP only through the portal’s legitimate channel.
Never ask the model to read, retain, or repeat the OTP unnecessarily.
Keep OTP handling in a secure user interface or backend session.
Store a short-lived session reference rather than the OTP itself.
Explain exactly which data the user is authorizing and for how long.

For Indian deployments, assess obligations under the Digital Personal Data Protection Act, 2023, applicable rules, contractual requirements, and the DISCOM’s own terms. Consumption linked to a household or business account can be personal or sensitive in context. Establish a lawful purpose, notice, retention period, deletion process, access controls, and grievance route. If a startup processes data on behalf of a utility or enterprise, document controller–processor responsibilities contractually.

Choose the Right Retrieval Method

Use the most official and stable source available:

1. Official API

An API is preferable when the DISCOM or its technology provider offers documented access. Verify scopes, quotas, pagination, timestamps, and whether the API returns estimated or finalized values.

2. Authorized data export

Some portals permit CSV, PDF, or statement downloads. Use this method when it is explicitly allowed, then parse and validate the document. PDFs should be treated as semi-structured evidence, not automatically trusted data.

3. Browser session through a controlled connector

If no API exists, a browser automation connector may operate an authenticated session. Restrict it to approved domains, stable selectors, and read-only workflows. Do not bypass CAPTCHA, bot protections, access controls, or technical restrictions. If a portal prohibits automation, seek permission or use an alternative official channel.

4. Utility or smart-meter platform integration

For interval data, the smart-meter operator, AMI platform, or utility-approved partner may be more reliable than the public billing portal. Confirm that the integration is authorized and that meter data is mapped to the correct consumer account.

Handling “Live” Data Correctly

Every answer should state how current the data is. A useful agent response might say:

> The meter reports 9.4 kWh for 2 September 2026. The source last updated the record at 06:00 IST, and it was retrieved at 10:12 IST. The value is provisional.

Implement freshness rules in the WebMCP server:

Reject or flag records older than the user’s requested threshold.
Distinguish “no new data” from “connector failed.”
Return the source timestamp even when retrieval succeeds.
Mark billing-cycle totals as different from interval measurements.
Avoid extrapolating a monthly total from partial data unless the user asks for an estimate.

For anomaly detection, compare current values with historical baselines only after accounting for billing cycles, meter changes, holidays, seasonal load, and missing intervals.

Security Controls You Should Implement

A live-data agent creates risks beyond ordinary API integration. Recommended controls include:

Domain allowlists for every connector
Server-side schema validation and output filtering
Encrypted secrets management using a vault or cloud KMS
Short-lived access tokens and session expiry
Tenant isolation for households, facilities, and enterprise customers
Masking of consumer numbers and meter identifiers in logs
Rate limits per user, account, connector, and IP
Replay protection and request identifiers
Audit logs for consent, tool calls, data access, and exports
Human review for bulk retrieval or third-party sharing
Prompt-injection defenses for portal content and downloaded documents

Treat portal text as untrusted input. A malicious or compromised page must not be able to instruct the agent to reveal credentials, invoke unrelated tools, or change its system policy.

Reliability, Testing, and Monitoring

Before production, build a connector test matrix covering:

Successful login and expired session
OTP timeout and incorrect verification
Missing meter or invalid consumer reference
Empty date range and maximum-range enforcement
Portal maintenance and HTTP errors
JavaScript layout changes
Duplicate readings and corrected bills
Unit conversion and timezone boundaries
Meter replacement and cumulative counter rollover
Regional-language labels and PDF format changes

Monitor:

Retrieval success rate by DISCOM
Median and percentile latency
Data freshness lag
Authentication failure rate
Schema-validation failures
Portal change detection
Number of records marked estimated or stale
Unauthorized-access attempts

Use synthetic test accounts where possible. Do not test against real consumers without documented permission and appropriate safeguards.

Example Agent Interaction

A user might ask: “Show my electricity consumption for the last seven days and tell me whether yesterday was unusually high.”

The agent should:

1. Identify the linked meter without exposing its full identifier.
2. Ask for authorization if no valid consent exists.
3. Call get_consumption_summary with a bounded date range.
4. Check freshness, completeness, and quality flags.
5. Calculate an anomaly against a defined baseline, such as the prior 28 comparable days.
6. Report units, timestamps, missing data, and uncertainty.

It should not claim that a spike is a fault. It can say that usage is above baseline and recommend checking appliances, occupancy, meter status, or contacting the DISCOM.

Common Mistakes to Avoid

Exposing a generic browser tool instead of typed DISCOM operations
Storing portal passwords in prompts, chat history, or application logs
Scraping without checking authorization or portal terms
Calling data “real-time” when it is only monthly billing data
Returning a number without units, timezone, or source timestamp
Treating an unavailable portal as zero consumption
Mixing data from multiple meters under one consumer account
Ignoring estimated readings and meter replacement events
Allowing the agent to accept arbitrary URLs or upload credentials
Building one brittle scraper for every state instead of versioned connectors

Implementation Roadmap for an Indian AI Startup

A practical phased approach is:

Phase 1: Narrow pilot

Choose one DISCOM, one read-only use case, and one data granularity. Implement consent, a single connector, canonical schema, and audit logs.

Phase 2: Quality and safety

Add freshness checks, retries with backoff, structured errors, secret rotation, synthetic tests, and a user-facing account unlink and deletion flow.

Phase 3: Multi-DISCOM abstraction

Create an adapter interface such as authenticate, list_meters, fetch_consumption, and get_source_status. Keep state-specific logic inside each connector while preserving a shared output schema.

Phase 4: Enterprise readiness

Add tenancy, role-based access, data-residency decisions, service-level monitoring, security assessment, incident response, and contracts with utilities or authorized partners.

Phase 5: Intelligent energy workflows

Only after retrieval is dependable should you add forecasting, tariff optimization, solar sizing, demand-response recommendations, or automated alerts. Every recommendation should retain the underlying data provenance.

FAQ

Can WebMCP fetch data from every Indian DISCOM portal?

No. Availability depends on the portal’s APIs, authentication, terms, technical design, and permission for automated access. Build and validate connectors individually.

Is browser automation acceptable for DISCOM portals?

Only when authorized and technically permitted. Do not bypass CAPTCHA, bot controls, authentication, or other access restrictions. Prefer official APIs or approved data-sharing channels.

What is the difference between live and billing data?

Live data may refer to recent smart-meter intervals, while billing data may cover a finalized or estimated billing cycle. Always return the source update time and data quality.

Should the AI agent receive the user’s password or OTP?

No. Handle authentication in a secure account-linking flow and give the agent only an authorized, scoped reference to the linked meter or account.

What should founders build first?

Start with one read-only, consent-based workflow for one DISCOM. Prove data freshness, correctness, security, and reliability before expanding coverage or adding autonomous actions.

Apply for AI Grants India

Building a secure WebMCP-powered energy or utility agent in India? Apply through AI Grants India for support, visibility, and potential grant opportunities for your AI startup.