Pune’s smart-city systems generate valuable data from traffic counters, air-quality monitors, flood sensors, parking systems, waste-management devices, and public infrastructure. The challenge is making that data safely usable by AI agents without exposing raw operational systems or allowing uncontrolled actions.
A WebMCP tool can provide the missing control layer. It exposes a small, typed set of capabilities that an AI agent can discover and call through a web-compatible interface. Instead of giving an agent unrestricted database access, you define exactly which sensor operations are permitted, what inputs are accepted, how results are filtered, and which actions require human approval.
This guide explains how to build a WebMCP tool for agents to manage smart city sensor data in Pune, with an architecture suitable for pilots and production deployments.
What a WebMCP tool should do
A WebMCP tool is an agent-facing interface that converts natural-language intent into validated operations. For Pune’s urban infrastructure, those operations might include:
- Finding sensors by ward, location, type, or operational status
- Reading recent observations from air-quality, traffic, water-level, or parking sensors
- Comparing measurements across time windows or geographical zones
- Detecting stale, offline, or anomalous devices
- Creating maintenance tickets
- Updating approved sensor metadata
- Scheduling diagnostics or calibration checks
- Producing ward-level summaries for authorised users
The tool should not expose every backend endpoint. Its purpose is to provide a constrained capability surface with clear schemas, authentication, audit logs, rate limits, and policy enforcement.
For example, an agent may ask, “Show air-quality sensors in Aundh with no readings in the last six hours.” The WebMCP layer should translate that request into a structured query, validate the ward and time range, retrieve only permitted fields, and return a concise result with timestamps and data-quality indicators.
Pune-specific requirements and data sources
A Pune deployment must account for a mixed infrastructure environment. Data may come from municipal systems, public dashboards, IoT gateways, third-party vendors, research institutions, and private operators. These sources often differ in naming conventions, protocols, update frequency, and data quality.
Before designing the tool, create a source inventory covering:
- Sensor identifier and ownership
- Device type and measurement units
- GPS coordinates or geospatial reference
- Pune ward, zone, or administrative boundary
- Data collection frequency
- Transport protocol, such as MQTT, HTTPS, LoRaWAN, or vendor API
- Retention period and historical availability
- Public, restricted, or operationally sensitive classification
- Data steward and escalation contact
Avoid assuming that a sensor’s GPS point is sufficient for governance. A device may be located near a hospital, school, traffic junction, water facility, or security-sensitive site. Location precision may need to be reduced for some users, while maintenance teams require exact coordinates.
India-specific considerations include compliance with the Digital Personal Data Protection Act, 2023 where personal data is processed, contractual restrictions imposed by data providers, and government or municipal cybersecurity requirements. Most environmental and aggregate infrastructure readings are not inherently personal data, but camera feeds, vehicle identifiers, mobile-device data, and fine-grained movement patterns can become sensitive quickly.
Reference architecture
A practical architecture separates the agent interface from operational systems:
AI agent
|
WebMCP capability gateway
|
Authentication + policy engine + audit logger
|
Domain services
|-- Sensor catalogue service
|-- Observation query service
|-- Data-quality service
|-- Maintenance workflow service
|
Adapters and event pipelines
|-- MQTT/LoRaWAN gateways
|-- Vendor APIs
|-- Time-series database
|-- GIS and ward-boundary servicesThe WebMCP gateway should be stateless where possible. It validates tool calls, applies user and agent permissions, and delegates work to domain services. Do not allow the agent layer to connect directly to an MQTT broker, production database, or device-management console.
A typical storage design uses a relational database such as PostgreSQL with PostGIS for metadata and spatial queries, plus a time-series system such as TimescaleDB or an equivalent managed service for observations. Object storage can hold raw files, calibration certificates, and archived exports.
For Pune-scale pilots, begin with a narrow set of sensor classes and a read-only capability. Add write operations only after identity, approval, rollback, and monitoring controls are proven.
Define the tool contract first
The most important implementation task is defining a strict tool contract. Each capability should specify its name, description, input schema, output schema, permissions, and side effects.
Example capabilities include:
{
"name": "search_sensors",
"description": "Find authorised sensors by ward, type, status, or location.",
"inputSchema": {
"type": "object",
"properties": {
"sensorType": {"type": "string"},
"ward": {"type": "string"},
"status": {"enum": ["online", "stale", "offline", "unknown"]},
"limit": {"type": "integer", "minimum": 1, "maximum": 100}
},
"additionalProperties": false
}
}Use controlled vocabularies rather than accepting arbitrary strings. Pune wards, sensor types, units, and status values should come from a versioned catalogue. Reject unknown fields and impose maximum limits on result size, time range, and spatial radius.
For observations, distinguish between the requested period and the actual available period. A response should include:
- Sensor ID and human-readable label
- Measurement value and unit
- Observation timestamp in UTC
- Local display time in Asia/Kolkata when useful
- Source and ingestion timestamp
- Quality flag
- Missing-data or calibration status
- Approximate location, subject to authorisation
Never let an agent infer that a missing reading equals zero. Explicitly represent null, stale, invalid, and unavailable values.
Example operations for a first release
A focused version-one tool could expose these read capabilities:
search_sensors
Filters sensors by type, ward, status, and bounding box. Return metadata only, with pagination and field-level access control.
get_latest_observations
Returns the latest valid observation for selected sensors. Include freshness and quality flags so the agent can distinguish real conditions from delayed ingestion.
query_observations
Supports bounded time-series queries. Enforce a maximum range, such as 31 days for interactive calls, and provide aggregation options such as five-minute, hourly, or daily averages.
summarise_ward_conditions
Produces an aggregate summary for a permitted ward. The service, not the language model, should calculate averages, percentiles, thresholds, and missingness.
create_maintenance_ticket
Creates a ticket only after validating that the sensor is offline or stale according to a defined rule. Require an idempotency key to prevent duplicate tickets.
Avoid building a generic execute_sql, call_device_api, or run_command tool. These patterns create excessive privilege and make prompt injection or model error far more dangerous.
Build the data and API layer
Start by normalising sensor metadata. A simplified model might contain:
sensors
- id
- external_id
- type
- owner
- ward_code
- latitude
- longitude
- status
- sensitivity_class
- last_seen_at
observations
- sensor_id
- observed_at
- ingested_at
- metric
- value
- unit
- quality_code
- sourceUse UTC for storage and ISO 8601 timestamps at API boundaries. Convert to Asia/Kolkata only for display or explicitly requested reporting. Index sensor_id, observed_at, and add spatial indexes for location queries.
The API layer should provide deterministic business logic. For example, define “stale” centrally as no valid observation for a sensor-specific threshold. An air-quality station reporting every minute and a flood sensor reporting every fifteen minutes should not share an arbitrary freshness rule.
Use pagination, cursor-based retrieval for long result sets, and server-side aggregation. Cache immutable metadata and short-lived latest readings where appropriate, but disclose cache age in responses.
Agent safety and prompt-injection resistance
Smart-city data may contain free-text fields from vendor systems, maintenance notes, or device labels. Treat all external content as untrusted data. A malicious string in a sensor description must never become an instruction to the agent.
Implement these controls:
- Keep tool descriptions short, precise, and non-executable
- Validate every argument against a server-side schema
- Separate data returned by tools from system instructions
- Restrict tools by user, agent, tenant, and environment
- Require confirmation for external side effects
- Use allowlists for domains, wards, sensor types, and actions
- Apply per-user and per-agent rate limits
- Log the original request, validated arguments, result status, and actor
- Redact tokens, personal data, and sensitive coordinates from logs
For write operations, use a two-step pattern. First, the agent calls a preview operation that explains the proposed change. Then an authorised user or workflow approves the action using a short-lived approval token. The execution endpoint must revalidate permissions and current state rather than trusting the preview.
Identity, access control, and governance
Use an identity provider supporting OAuth 2.0 or OpenID Connect. Map identities to roles such as analyst, field engineer, municipal operator, vendor administrator, or public-information user.
Apply least privilege at multiple levels:
- Capability-level: can the actor call the operation?
- Dataset-level: which sensor classes or owners are visible?
- Geography-level: which Pune wards or zones are allowed?
- Field-level: are exact coordinates, device identifiers, or vendor details visible?
- Action-level: can the actor create tickets or change metadata?
Maintain an audit record for every call, including actor identity, agent identity, tool name, validated inputs, authorisation decision, latency, response classification, and side effect. Define retention and access rules for audit data, and test that logs cannot be modified by ordinary service accounts.
Connecting real-time streams and historical data
A robust ingestion pipeline separates device transport from agent queries. MQTT or gateway events should pass through validation, deduplication, unit conversion, timestamp checks, and quality scoring before entering the time-series store.
Useful quality checks include:
- Out-of-order and future timestamps
- Impossible physical values
- Sudden step changes
- Duplicate messages
- Long gaps in reporting
- Calibration expiry
- Device clock drift
- Conflicts between gateway and vendor timestamps
Store the original payload separately when legally and operationally appropriate, but expose only the normalised observation to agents. This prevents every agent call from having to understand vendor-specific formats.
For live conditions, the WebMCP service can query a latest-value cache fed by the stream processor. For reports and trends, it should query the historical store with bounded aggregation. Do not make an LLM calculate thousands of raw readings in its context window.
Testing strategy
Test the tool as a security-sensitive API, not merely as a chatbot feature. Your test suite should include:
- Schema tests for missing, extra, malformed, and extreme inputs
- Authorisation tests across roles and wards
- Time-zone and daylight-saving edge cases, even though India does not change clocks
- Stale, null, duplicate, and out-of-order observations
- SQL-injection and command-injection attempts
- Prompt-injection payloads in sensor names and notes
- Rate-limit and pagination tests
- Idempotency tests for ticket creation
- Failure handling when gateways or vendor APIs are unavailable
- Contract tests between the gateway and domain services
- Load tests for concurrent ward summaries
Create synthetic Pune-like fixtures before using production data. Include sensor records from different wards, missing GPS points, mixed units, delayed messages, and permissions that intentionally overlap or conflict.
Deployment and observability
Containerise the gateway and domain services, and deploy separate development, staging, and production environments. Keep production credentials out of prompts, source code, notebooks, and CI logs. Use a managed secrets vault and rotate credentials regularly.
Monitor:
- Tool-call volume by capability and actor
- Validation and authorisation failures
- p50, p95, and p99 latency
- Upstream error rates
- Sensor freshness and ingestion lag
- Duplicate maintenance tickets
- Token and context consumption where agents are involved
- Unusual access patterns, such as bulk ward enumeration
Set alerts for operational failures and security anomalies. A daily data-quality report can identify sensors that are technically online but producing unusable data.
A practical Pune implementation roadmap
Phase 1: Read-only pilot
Select one or two sensor categories, such as air quality and flood monitoring. Build the catalogue, latest-observation query, bounded time-series query, and ward summary. Use synthetic or approved data and establish audit logging.
Phase 2: Operational workflows
Add stale-device detection and maintenance-ticket creation. Introduce approval workflows, idempotency, escalation rules, and integration with the organisation’s service-management platform.
Phase 3: Multi-source federation
Connect additional vendors and gateways through adapters. Standardise units, quality codes, and ownership metadata. Add data-lineage fields so users can identify the source and ingestion path.
Phase 4: Production governance
Complete threat modelling, penetration testing, disaster recovery, backup validation, access reviews, and documented data-sharing agreements. Establish a named data steward and an incident-response process.
Common mistakes to avoid
- Giving the agent direct database or device access
- Returning raw, unbounded time-series data
- Treating missing readings as zero
- Mixing UTC and India Standard Time without labelling
- Exposing exact coordinates to every role
- Allowing write actions without confirmation and audit trails
- Letting vendor-specific payloads leak into the agent contract
- Using natural-language policy instead of enforceable server-side rules
- Ignoring data provenance and quality flags
- Building for every sensor type before proving one workflow
FAQ
What is WebMCP in a smart-city context?
WebMCP is an agent-facing capability layer that lets AI systems discover and call controlled web tools. In a smart-city context, it can provide safe access to sensor search, observations, analytics, and approved operational workflows.
Should the tool expose raw sensor data?
Usually not. Return validated, normalised, quality-annotated results with bounded time ranges and role-based field filtering. Keep raw payloads in controlled backend storage.
Can an agent change sensor settings?
It can, but this should not be part of the initial release. Device-control actions require stronger authorisation, explicit human approval, rollback procedures, and additional safety testing.
Which Pune data should be used for a pilot?
Choose a narrow, well-governed dataset with clear ownership, such as approved air-quality, traffic, or water-level observations. Confirm licensing, retention, privacy, and operational contacts before connecting production feeds.
How do AI founders make this commercially useful?
Package the tool around a measurable workflow: faster incident detection, reduced manual reporting, improved maintenance triage, or better public-service forecasting. Demonstrate accuracy, auditability, and integration readiness rather than only a conversational interface.
Apply for AI Grants India
If you are an Indian AI founder building trustworthy tools for urban infrastructure, apply through AI Grants India for support, visibility, and funding opportunities. Share your WebMCP prototype, data-governance plan, and measurable Pune smart-city impact.