Tracking mandi prices across Karnataka in real time is a strong use case for a WebMCP: a web-connected Model Context Protocol layer that lets an AI assistant retrieve, compare, explain, and alert on market prices through controlled tools. The best approach is not to let an AI model browse arbitrary pages and guess the latest rate. Build a verified data pipeline first, then expose narrowly scoped WebMCP tools with timestamps, source attribution, confidence signals, and Karnataka-specific market context.
For an Indian agri-tech product, accuracy and freshness matter more than conversational polish. Farmers, traders, FPOs, and procurement teams need to know the commodity, variety, grade, market, unit, price type, reporting time, and whether a value is provisional or confirmed.
What is the best way to develop a WebMCP for Karnataka mandi prices?
The best architecture is a five-layer system:
1. Authoritative data connectors collect price and arrival records.
2. A normalization and validation pipeline converts inconsistent mandi data into a common schema.
3. A time-series and search database stores current and historical observations.
4. A WebMCP server exposes safe tools for querying the data.
5. A web or mobile interface presents results in Kannada, English, and other relevant languages.
The language model should never be the source of truth. It should interpret a structured result returned by your service. Every answer should carry the source, observation timestamp, data freshness, and any caveat about missing or delayed updates.
A practical request flow is:
User question
-> intent and entity extraction
-> WebMCP tool call
-> validated database query
-> freshness and confidence checks
-> structured response with citations
-> Kannada/English explanation and optional alertThis design reduces hallucinations, prevents unsafe queries, and makes it possible to replace a data provider without redesigning the assistant.
Define the Karnataka mandi price use case precisely
“Real time” has different meanings in agricultural markets. Many mandi systems publish arrivals and prices periodically rather than continuously. Before building, define a service-level target such as:
- Update latency: ingest a new record within 5–15 minutes of publication.
- Coverage: all supported APMCs in Karnataka, or a clearly documented subset.
- Historical depth: at least 12–24 months for trend analysis.
- Availability: for example, 99.5% for price lookups.
- Freshness policy: label observations older than a defined threshold as stale.
- Language support: English first, followed by Kannada-friendly display and voice workflows.
Start with high-demand commodities and markets instead of promising every crop on day one. A first release might cover major vegetables, cereals, pulses, spices, and key APMCs around Bengaluru, Mysuru, Hubballi-Dharwad, Belagavi, Shivamogga, and other important production and consumption zones.
Also distinguish price fields. A user may ask for the “mandi price,” but the system may contain:
- Minimum price
- Maximum price
- Modal price
- Wholesale or auction price
- Retail reference price
- Arrival quantity
- Unit, such as ₹/quintal or ₹/kg
The assistant must explain which field it is reporting rather than silently selecting one.
Use reliable and lawful data sources
Your source strategy should combine official and operational feeds. Potential sources include official agricultural market portals, state or national open-data interfaces, APMC publications, e-NAM-linked information where available, licensed commercial feeds, and direct partnerships with market committees or FPO networks.
Do not assume that a publicly visible webpage permits unrestricted automated extraction. Check terms of use, robots directives, API conditions, copyright, rate limits, and data licensing. Prefer documented APIs, downloadable datasets, or written agreements. If a source is unavailable, show “data not available” rather than filling the gap with an inferred price.
Use a source registry with fields such as:
- Source name and owner
- Endpoint or delivery method
- Licence and permitted uses
- Update schedule
- Time zone
- Known field definitions
- Historical reliability
- Contact or escalation path
For each observation, retain provenance. A useful record includes source_id, source_record_id, retrieved_at, published_at, and the original payload hash. This allows you to investigate disputes and detect silent changes in upstream data.
Design a canonical mandi price schema
Karnataka markets may use different spellings, local names, units, and commodity classifications. Normalize them before exposing data to an AI system.
A practical observation schema could contain:
{
"commodity_id": "tomato",
"commodity_name": "Tomato",
"variety": "Hybrid",
"grade": "FAQ",
"market_id": "KA_BENGALURU_YESHNWANTHPUR",
"market_name": "Yeshwanthpur APMC",
"district": "Bengaluru Urban",
"state": "Karnataka",
"price_min": 1800,
"price_max": 2400,
"price_modal": 2100,
"currency": "INR",
"unit": "quintal",
"arrivals_quantity": 86.5,
"arrival_unit": "tonne",
"observed_at": "2026-09-03T09:30:00+05:30",
"published_at": "2026-09-03T09:45:00+05:30",
"source_id": "official_feed_1",
"quality_status": "verified"
}Use stable IDs for commodities, markets, varieties, and grades. Maintain alias tables for terms such as “Bangalore,” “Bengaluru,” Kannada commodity names, transliterations, abbreviations, and spelling variants. A geospatial market table should store latitude, longitude, district, taluk, and service radius so the system can answer “nearest mandi” queries.
Store all timestamps in UTC internally and display them in Asia/Kolkata. Never compare timestamps as plain strings when sources use different formats. Preserve the source’s original time as well as your normalized timestamp.
Build ingestion for freshness and resilience
A production pipeline should support both scheduled polling and event-driven ingestion where providers offer webhooks or streaming updates. For ordinary public datasets, a scheduled worker is often sufficient:
1. Fetch the source using authentication and a strict timeout.
2. Save the raw response in object storage.
3. Parse and map fields into the canonical schema.
4. Deduplicate by source record ID or a deterministic content key.
5. Validate ranges, units, timestamps, and required entities.
6. Write accepted observations to the database.
7. Send rejected records to a review queue.
8. Publish freshness and ingestion metrics.
Add exponential backoff, circuit breakers, idempotency, and dead-letter queues. A temporary source failure should not erase the last known value. Instead, retain it with an explicit stale status.
Useful validation rules include:
- Price cannot be negative.
- Minimum price must not exceed maximum price.
- Modal price should normally fall within the minimum–maximum interval.
- Currency and unit must be recognized.
- Observation time cannot be far in the future.
- Market and commodity must exist in master data.
- Large changes require anomaly review rather than automatic deletion.
Anomaly detection should flag, not blindly correct, unusual movements. A 60% price change may indicate a genuine supply shock, a unit mismatch, or a parser failure. Compare against recent values, nearby markets, arrivals, and source-level patterns before marking a record as trusted.
Choose storage for current and historical queries
Use a relational database such as PostgreSQL for master data, permissions, provenance, and transactional integrity. Add a time-series extension or carefully indexed observation tables for historical queries. A typical index strategy includes:
(market_id, commodity_id, observed_at DESC)(commodity_id, district, observed_at DESC)(source_id, published_at DESC)
For large-scale analytics, replicate clean records to a warehouse such as ClickHouse, BigQuery, or an equivalent analytical system. Redis can cache popular current-price queries, but cache keys must include commodity, variety, market, unit, and freshness parameters. Never cache a price without its timestamp and source metadata.
Keep raw, normalized, and curated layers separate. This makes reprocessing possible when a provider changes its format or you improve your mapping rules.
Expose narrow, typed WebMCP tools
A WebMCP server should provide tools that are easy for an AI client to call and difficult to misuse. Avoid a generic SQL tool or unrestricted browser tool. Define explicit input schemas with enums, limits, and validation.
Recommended tools include:
get_current_mandi_price
Inputs:
- Commodity
- Market or district
- Variety and grade, if known
- Preferred price field
- Maximum acceptable age
Outputs:
- Current value and unit
- Minimum, maximum, and modal prices where available
- Observation and publication times
- Source and quality status
- Freshness in minutes
compare_mandi_prices
Compare one commodity across selected Karnataka markets. Return a ranked table, not only a prose answer. Include distance only when a reliable origin location is supplied.
get_price_history
Return daily or intraday observations for a bounded date range. Enforce maximum ranges and aggregation intervals to prevent expensive queries.
find_nearby_markets
Accept a location, district, or coordinates and return nearby supported APMCs with coverage and latest update time.
create_price_alert
Create a user-authorized alert for a commodity and market when modal price crosses a threshold or changes by a specified percentage. Require confirmation, authentication, and a delivery channel.
explain_price_change
Summarize movement using available historical prices and arrivals, but clearly separate observed facts from possible causes. The tool should return evidence; the model can turn it into plain language.
Tool responses should be JSON with a predictable shape. Include data_status values such as fresh, delayed, stale, partial, or unavailable. The model’s instructions should require it to cite these fields and avoid presenting stale values as live prices.
Add security, permissions, and observability
Treat WebMCP tools as an application interface, not a casual chatbot plugin. Apply authentication for personal alerts and administrative functions. Use read-only credentials for price lookup. Validate every input server-side and apply rate limits per user, IP, and tool.
Protect against prompt injection from scraped content. Upstream text should be treated as untrusted data and never allowed to alter tool policies. Do not pass raw HTML into the model when structured extraction is possible. Log tool name, normalized inputs, response status, latency, source, and request ID, while minimizing personally identifiable information.
Monitor:
- Source fetch success rate
- Ingestion delay
- Percentage of stale records
- Parsing and validation failures
- Tool error rate and latency
- Cache hit ratio
- Unanswered commodity or market queries
- Corrections reported by users
Create a data-quality dashboard and an incident runbook. When a source fails, the assistant should say when the last successful update occurred and offer the latest verified observation—not invent a replacement.
Make the experience useful for Karnataka users
A technically correct API can still fail if the interface ignores real user workflows. Support Kannada names and transliteration, but keep canonical IDs behind the scenes. Display ₹ formatting, quintal-to-kilogram conversions, and a clear note when conversion is applied.
Useful answer formats include:
- “Tomato modal price at Yeshwanthpur APMC: ₹X/quintal, reported at [time].”
- A comparison table for selected markets
- A seven-day trend with minimum and maximum dates
- A “last updated” badge
- A “report incorrect data” action
- A route or distance estimate only from a verified mapping service
For low-connectivity environments, consider SMS, WhatsApp, IVR, or lightweight progressive web app delivery. Keep alerts concise and include crop, market, price, unit, threshold, and timestamp. Obtain consent and provide an easy unsubscribe mechanism.
Test accuracy before launch
Create a golden test set of real questions from farmers, traders, and FPO operators. Include ambiguous queries such as “today’s tomato rate near Bengaluru,” unit conversions, Kannada aliases, missing varieties, stale data, and conflicting sources.
Evaluate:
- Entity extraction accuracy
- Correct market and commodity selection
- Numerical exactness
- Unit and currency correctness
- Freshness disclosure
- Citation and provenance completeness
- Refusal behavior when data is unavailable
- Latency under peak load
Use contract tests for every source connector and WebMCP tool. Replay historical source files to ensure parser changes do not alter old records unexpectedly. Human reviewers should verify high-impact answers and sampled alerts before broad deployment.
Common mistakes to avoid
- Calling a language model “real time” without measuring source latency
- Scraping websites without checking permission or stability
- Mixing wholesale, modal, and retail prices
- Ignoring variety, grade, and unit
- Returning a stale cached result without disclosure
- Using free-form SQL or unrestricted browsing as a tool
- Treating anomalous values as errors automatically
- Supporting English-only commodity and market names
- Sending alerts without consent or audit logs
- Failing to retain raw source records for troubleshooting
Recommended implementation roadmap
Phase 1: Data foundation — select a small set of licensed sources, define the canonical schema, build market and commodity masters, and ingest a limited Karnataka pilot.
Phase 2: Verified lookup API — implement current-price, comparison, and history endpoints with freshness metadata, provenance, caching, and automated validation.
Phase 3: WebMCP integration — expose typed, read-only tools, add strict schemas, test model behavior, and implement clear unavailable-data responses.
Phase 4: User workflows — add Kannada-friendly search, nearby-market discovery, alerts, dashboards, and feedback reporting.
Phase 5: Scale and governance — expand APMCs and commodities, add source redundancy, improve anomaly detection, and publish quality metrics.
The core principle is simple: make the data trustworthy before making the assistant conversational. A WebMCP can make mandi intelligence easier to access, but its credibility depends on source governance, timestamp discipline, schema quality, and transparent uncertainty.
FAQ
Is a WebMCP the same as scraping mandi websites?
No. Scraping may be one ingestion method, but WebMCP is the tool interface that allows an AI client to request structured, controlled data. Use lawful, stable, and preferably documented sources.
Can mandi prices be truly real time?
Only if the source publishes continuously. Otherwise, describe the product as near real time and show the exact observation and retrieval timestamps.
Which price should the assistant report?
Usually the modal price is the most useful single market indicator, but the interface should show minimum and maximum values when available and explain the selected field.
Should I use a large language model to clean prices?
Use deterministic parsers and validation for numerical data. An LLM may help map aliases or classify text, but every result needs rule-based checks and source provenance.
How can founders handle missing Karnataka market data?
Return a transparent unavailable or stale status, show the last verified update, and offer nearby supported markets. Never infer a current price from a historical trend.
Apply for AI Grants India
If you are an Indian AI founder building a verified mandi intelligence platform, WebMCP infrastructure, or farmer-facing market tool, apply through AI Grants India. Share your technical approach, data partnerships, pilot users, and measurable impact plan.