Air quality monitoring in Delhi NCR is a strong use case for agent-enabled web applications. Residents, schools, hospitals, employers and city teams need timely answers about AQI, PM2.5, PM10, ozone and recommended actions—but raw sensor feeds are difficult for an AI agent to interpret safely. A WebMCP can provide a structured interface that lets agents discover reliable air-quality tools, query current conditions, compare locations and explain results with timestamps and data-quality context.
This article explains the process for building a WebMCP for agents to track real-time air quality indices in Delhi NCR. It focuses on practical architecture, data sources, tool design, validation, security, observability and deployment considerations for India.
What Is a WebMCP?
WebMCP refers to a web-accessible Model Context Protocol interface that exposes tools, resources or prompts to AI agents in a predictable format. Instead of asking an agent to scrape a dashboard, a WebMCP describes operations such as:
- Get the latest AQI for Delhi or a selected NCR city
- Retrieve pollutant readings from nearby monitoring stations
- Compare AQI across Delhi, Noida, Gurugram, Ghaziabad and Faridabad
- Check whether a reading is current, delayed or unavailable
- Explain the health implications of a pollutant concentration
- Return historical data for a defined time window
The important design principle is that the WebMCP should expose trustworthy, machine-readable capabilities—not merely a webpage. The agent should receive structured values, units, timestamps, source identifiers, uncertainty and location metadata alongside a human-readable explanation.
Why Delhi NCR Requires a Careful Design
Delhi NCR is not a single uniform air-quality zone. Conditions can vary significantly between monitoring stations because of traffic, construction, industrial activity, weather, crop-residue burning, wind direction and local emissions. A city-level AQI may therefore hide important neighbourhood-level differences.
A robust system should distinguish between:
- Delhi city and individual Delhi monitoring stations
- Noida and Greater Noida in Uttar Pradesh
- Gurugram and Faridabad in Haryana
- Ghaziabad and other NCR locations
- Station-level observations and aggregated city-level indices
- Current observations and forecasts
India’s National Air Quality Index commonly uses pollutant sub-indices and categories such as Good, Satisfactory, Moderately Polluted, Poor, Very Poor and Severe. Your WebMCP must document which AQI standard it uses, because international AQI scales are not interchangeable with India’s system.
Step 1: Define the Agent Use Cases
Start by documenting what agents must do. Avoid building a generic data proxy before deciding how the information will be used.
Typical use cases include:
1. Current-condition lookup: “What is the AQI near Connaught Place right now?”
2. Cross-city comparison: “Is air quality better in Gurugram than Noida?”
3. Health guidance: “Should an asthma patient avoid outdoor exercise today?”
4. Threshold alerts: “Notify me when PM2.5 exceeds a defined threshold.”
5. Travel planning: “Find the least polluted route or time window for outdoor activity.”
6. Historical analysis: “How has AQI changed in Delhi over the last 24 hours?”
7. Operational monitoring: “Show stations with stale or missing readings.”
For each use case, specify the required freshness, geographic precision, acceptable fallback behaviour and whether the output is informational or safety-sensitive. Health-related responses need stronger disclaimers and conservative handling of missing data.
Step 2: Select and Evaluate Data Sources
The data layer determines the credibility of the WebMCP. Potential sources may include official government feeds, published datasets, approved APIs, calibrated private sensor networks and weather providers.
When evaluating a source, check:
- Licensing and permitted commercial use
- API stability and rate limits
- Pollutants provided
- Station coordinates and identifiers
- Update frequency and publication delay
- Whether values are raw concentrations or calculated AQI
- Historical availability
- Missing-value conventions
- Calibration and quality-control documentation
- Attribution requirements
For India-focused deployments, prioritise authoritative public data where available and clearly identify the source in every response. Do not silently combine readings from incompatible AQI methodologies. If multiple feeds are used, store their provenance separately and document the aggregation rule.
Step 3: Design the Data Model
Use a canonical internal model before exposing tools to agents. A useful observation record may include:
{
"location": {
"name": "Anand Vihar",
"city": "Delhi",
"country": "IN",
"latitude": 28.6469,
"longitude": 77.3160,
"station_id": "example-station"
},
"aqi": {
"value": 248,
"category": "Poor",
"standard": "India_NAQI"
},
"pollutants": {
"pm25": {"value": 142.4, "unit": "µg/m³"},
"pm10": {"value": 238.1, "unit": "µg/m³"},
"no2": {"value": 48.2, "unit": "µg/m³"}
},
"observed_at": "2026-09-03T08:30:00+05:30",
"retrieved_at": "2026-09-03T08:34:10+05:30",
"freshness_seconds": 250,
"quality": {
"status": "valid",
"flags": []
},
"source": {
"provider": "authoritative-feed",
"station_url": "https://example.org/station"
}
}Use ISO 8601 timestamps with the Asia/Kolkata offset or UTC plus an explicit timezone conversion policy. Store both observation time and retrieval time. These are different: a feed may be successfully fetched even when its underlying observation is old.
Step 4: Build an Ingestion and Normalisation Pipeline
Do not make the agent call an unreliable upstream API directly. Place a backend between data providers and the WebMCP. The backend should:
1. Fetch data on a schedule or through a streaming connection.
2. Validate schema, types, ranges and timestamps.
3. Convert units into a canonical representation.
4. Map station identifiers to a stable location registry.
5. Calculate or verify AQI using a documented India-specific method.
6. Mark stale, incomplete or anomalous records.
7. Cache recent results for resilience and low latency.
8. Store raw payloads for audit and troubleshooting.
Set explicit freshness rules. For example, a reading might be considered current up to 15 minutes, delayed between 15 and 60 minutes, and stale after 60 minutes. The thresholds should reflect the source’s normal update interval rather than an arbitrary number.
Avoid filling gaps with fabricated values. If interpolation is used for charts, label interpolated points and never present them as live observations to an agent.
Step 5: Define WebMCP Tools for Agents
Keep tools narrow, predictable and easy to validate. Example tool names include:
get_current_aqiget_station_observationsearch_air_quality_locationscompare_ncr_locationsget_aqi_historyget_pollutant_breakdownget_data_quality_status
A current-AQI tool could accept:
{
"location": "Delhi",
"station_id": null,
"include_pollutants": true,
"max_age_minutes": 30
}Its response should contain a typed result rather than an unstructured paragraph. Include the AQI value, category, standard, pollutant values, station or aggregation scope, observation timestamp, freshness, source and quality flags.
Tool descriptions should tell the model when not to use a tool. For example, a station lookup should require a known station identifier or a resolved location, while a health-oriented answer should not imply diagnosis or emergency treatment.
Step 6: Handle Location Resolution in Delhi NCR
Location ambiguity is a major failure mode. “Delhi,” “New Delhi,” “NCR,” “near airport” and local neighbourhood names may refer to different scopes.
Implement a location-resolution layer that supports:
- Canonical city and district names
- Station names and stable station IDs
- Latitude and longitude searches
- Radius-based nearest-station queries
- Administrative boundaries
- User-specified NCR cities
- Explicit clarification when a request is ambiguous
A nearest-station result should include distance and station timestamp. Do not claim that a single station represents an entire city without stating the aggregation method. For city-level summaries, document whether you use a designated reference station, a mean, median, maximum, population-weighted value or official published city index.
Step 7: Calculate and Explain AQI Correctly
AQI is not simply the average of pollutant concentrations. It is generally derived from pollutant-specific sub-indices, breakpoints, averaging periods and a rule for selecting the overall index. Your implementation must match the selected Indian standard and preserve the pollutant responsible for the maximum sub-index.
The response should distinguish:
- AQI value
- AQI category
- Dominant pollutant
- Individual concentration and unit
- Averaging period
- Observation time
- Health interpretation
Use cautious language such as “air quality is classified as…” rather than making unsupported medical claims. If the underlying source provides only pollutant concentrations and not an official AQI, label your computed value as calculated and publish the formula and version used.
Step 8: Add Safety and Responsible-Agent Controls
Air-quality information can influence health decisions, so safety controls are essential. The WebMCP should:
- Clearly identify stale or missing data
- Avoid presenting forecasts as observations
- Avoid diagnosis or personalised medical treatment
- Recommend official health guidance for vulnerable individuals
- Escalate emergency symptoms to local medical services
- Prevent prompt injection through untrusted station metadata
- Treat external text as data, not executable instructions
- Apply output limits and schema validation
For example, if a station is offline, return “No current verified reading” instead of substituting an old number without warning. If the user asks whether a child with asthma should exercise outdoors, provide general risk context and advise consulting a qualified clinician for individual decisions.
Step 9: Secure the WebMCP
A production WebMCP should be treated like an API platform. Recommended controls include:
- HTTPS everywhere
- Authentication for private or rate-limited tools
- Per-user and per-agent rate limits
- Request-size and timeout limits
- Strict JSON Schema validation
- Allowlisted upstream domains
- Secrets stored in a managed secret vault
- Audit logs for tool calls
- Redaction of personal data
- CORS and origin policies appropriate to the client
- Dependency and container vulnerability scanning
If alert subscriptions are supported, verify ownership of email addresses, phone numbers or messaging accounts. Minimise stored location history because frequent location queries can reveal routines and sensitive information.
Step 10: Test with Realistic Agent Queries
Traditional unit tests are not enough. Test the complete path from user language to tool selection and final response.
Create evaluation cases for:
- Ambiguous locations
- Hindi-English mixed queries
- “Right now” when data is delayed
- Station outages
- Contradictory upstream values
- Unknown pollutant names
- Requests for historical periods with gaps
- AQI category boundary values
- Attempts to obtain unsupported medical advice
- Prompt injection in source fields
Measure tool-selection accuracy, response latency, schema validity, freshness disclosure and citation or attribution correctness. Include regression tests whenever a provider changes its payload format.
Step 11: Deploy for Reliability and Observability
A practical production architecture may contain:
- Data-provider connectors
- A normalisation and quality-control service
- PostgreSQL with geospatial support or another spatial database
- Redis or equivalent cache
- A time-series store for historical observations
- The WebMCP gateway
- Authentication and rate limiting
- Monitoring, logs and alerting
Track operational metrics such as ingestion success rate, upstream latency, stale-record percentage, tool error rate, p95 response time, cache hit rate and station coverage. Set alerts for widespread feed failure, unusual pollutant jumps and schema changes.
Use a short cache for current observations, but preserve source timestamps so caching never disguises age. During upstream outages, return the latest verified value with a prominent age indicator and a quality status.
Common Mistakes to Avoid
- Scraping a visual dashboard instead of using a permitted data interface
- Mixing India’s AQI with US or other international scales
- Omitting units and averaging periods
- Treating a city as one station without explaining scope
- Returning a number without observation and retrieval timestamps
- Hiding stale data behind a “live” label
- Letting agents access raw upstream credentials
- Giving medical advice based on a single reading
- Failing to preserve provenance and attribution
- Overloading one tool with dozens of optional parameters
Suggested MVP Roadmap
A focused first release can be delivered in stages:
Phase 1: Verified current AQI
Support Delhi, Noida, Gurugram, Ghaziabad and Faridabad, with current AQI, dominant pollutant, station scope, timestamps and freshness flags.
Phase 2: Station and pollutant detail
Add nearest-station search, pollutant breakdowns, quality flags and explicit location resolution.
Phase 3: History and comparisons
Provide 24-hour and seven-day history, cross-city comparisons and documented aggregation methods.
Phase 4: Alerts and agent workflows
Add threshold alerts, scheduled summaries and integrations with approved agent clients, while strengthening consent, security and audit controls.
FAQ: Building a Delhi NCR Air-Quality WebMCP
What data should a Delhi NCR WebMCP return?
Return AQI, category, pollutant concentrations, units, station or geographic scope, observation time, retrieval time, freshness, data-quality flags and source attribution.
Should the WebMCP calculate AQI itself?
It can, but only with a documented implementation of the selected Indian standard. If the provider publishes an official AQI, preserve that value and distinguish it from any independently calculated result.
How often should air-quality data be refreshed?
Match the provider’s update cycle. Poll frequently enough to detect new observations, but use caching and rate limits. Always expose the actual observation age to the agent.
Can agents provide medical advice from AQI data?
They may provide general educational context, but should not diagnose or prescribe treatment. For symptoms or high-risk individuals, direct users to qualified healthcare and official guidance.
What makes the system agent-ready?
Stable tool names, strict schemas, clear descriptions, typed responses, location disambiguation, provenance, freshness metadata, safe failure behaviour and predictable error messages make a WebMCP useful to agents.
Apply for AI Grants India
If you are an Indian AI founder building a trustworthy WebMCP, climate-tech platform or agent infrastructure product, apply to AI Grants India for support and opportunities. Share your prototype, technical approach and expected impact across India.