How to Develop a WebMCP for Agents to Monitor Land Records

India’s land-record systems are increasingly digitised, but they are not uniform. Each state may use a different Bhulekh portal, URL structure, CAPTCHA policy, search workflow, language, document format, and update schedule. For an AI agent, checking these portals manually is slow and difficult to audit. A WebMCP—an agent-facing web capability layer—can turn fragmented public land-record workflows into structured, permissioned, and observable tools.

The right goal is not unrestricted scraping. It is a compliant monitoring system that helps authorised users check records, detect changes, retrieve official documents, and preserve evidence without bypassing access controls. This article explains how to develop a WebMCP for agents to monitor land records on Bhulekh portals of different Indian states.

What Is a WebMCP for Land-Record Monitoring?

A WebMCP can be understood as a controlled interface between an AI agent and web-based services. It exposes narrowly defined tools—such as selecting a state, searching a parcel, retrieving a mutation status, or comparing an official record—with structured inputs and outputs.

For Bhulekh monitoring, the WebMCP should sit between the agent and state portals:

User or workflow: provides a lawful monitoring objective and authorised identifiers.
AI agent: decides which approved tool to call and explains results.
WebMCP gateway: validates requests, applies rate limits, manages sessions, and records audit logs.
State adapters: translate a common land-record task into a state portal’s specific workflow.
Evidence store: saves timestamps, source URLs, downloaded documents, hashes, and extraction confidence.

This separation is important. The AI model should not receive unrestricted browser control or direct credentials. It should call deterministic tools with strict schemas and clear error states.

Define the Monitoring Use Case First

Before writing code, specify what “monitoring” means. Common legitimate use cases include:

Checking whether a mutation application has changed status.
Comparing a parcel’s publicly available record between two dates.
Monitoring an authorised portfolio of properties for ownership or encumbrance-related updates.
Retrieving official Record of Rights, Jamabandi, Khatauni, 7/12 extract, or equivalent documents.
Alerting a legal, compliance, lending, or property-management team when a record differs.
Verifying that a human operator’s search returned the expected district, tehsil, village, and parcel identifiers.

Avoid vague prompts such as “find everything about this land.” Require a defined state, district, tehsil, village, survey number, account number, or application reference, depending on the portal.

Your product requirements should also answer:

Who is authorised to monitor the record?
Is the information public, user-provided, or access-controlled?
How often may the portal be checked?
What constitutes a meaningful change?
How long should documents and personal data be retained?
What must happen when the portal displays a CAPTCHA or requires manual authentication?

Build a State-Adapter Architecture

A single scraper for all Indian states will be fragile. Use a common interface with separate adapters for each portal. The adapter handles state-specific navigation while the rest of the platform operates on normalised data.

A useful interface might include:

search_land_record(input) -> SearchResult
get_record(document_ref) -> OfficialDocument
get_application_status(application_ref) -> StatusResult
extract_record(document) -> NormalisedRecord
compare_records(previous, current) -> ChangeSet

A request could contain:

{
  "state": "Rajasthan",
  "district": "Jaipur",
  "tehsil": "Sanganer",
  "village": "Example Village",
  "identifier_type": "khasra",
  "identifier": "123/4",
  "purpose": "authorised portfolio monitoring"
}

The response should be predictable even when a portal fails:

{
  "status": "success",
  "source": {
    "portal": "official-state-portal",
    "retrieved_at": "2026-09-03T10:30:00Z",
    "url": "https://example.gov.in/"
  },
  "record": {
    "state": "Rajasthan",
    "district": "Jaipur",
    "village": "Example Village",
    "survey_number": "123/4"
  },
  "evidence": {
    "document_hash": "sha256:...",
    "extraction_confidence": 0.96
  }
}

Use versioned adapters. Government portals change HTML, APIs, certificates, and workflows without notice. An adapter registry should record supported portal version, last successful test, known limitations, and escalation contact.

Discover Official Sources Without Assuming Uniformity

Bhulekh is commonly used as a broad label, but state systems may have different official names and domains. Some records are exposed through land-record portals, registration departments, revenue systems, e-District services, or state digital service platforms.

For every state, create a source profile containing:

Official portal domain and ownership information.
Supported record types and languages.
Required hierarchy: district, sub-division, tehsil, village, ward, or mandal.
Accepted identifiers, including survey, khasra, khata, patta, dag, plot, or account numbers.
Whether public search is available without login.
CAPTCHA, OTP, digital-signature, or payment requirements.
Download formats such as PDF, XML, image, or HTML.
Terms of use, robots directives, rate restrictions, and published APIs.
Expected maintenance windows and error patterns.

Do not rely on search-engine results or unofficial mirrors when an official source is available. Store the exact source URL and retrieval timestamp so users can distinguish a current official result from a cached or secondary copy.

Design Safe WebMCP Tools

Expose tools that are narrow enough to validate and monitor. For example:

`list_supported_portals`

Returns supported states, record types, languages, authentication requirements, and adapter health.

`validate_land_query`

Checks that the requested state hierarchy and identifier format are complete before opening a session.

`search_public_record`

Performs an authorised search using permitted portal interaction. It should return structured metadata and a reference to evidence rather than making unsupported legal conclusions.

`retrieve_official_document`

Downloads a document only when the user is authorised and the portal permits retrieval. Preserve the original file unchanged.

`extract_land_fields`

Uses deterministic parsing, OCR, and validation rules to extract fields such as owner names, survey numbers, area, land type, mutation dates, and issuing authority.

`compare_record_versions`

Compares two documents or structured snapshots and classifies changes, including changed owner text, area, status, dates, and document identifiers.

`create_monitoring_schedule`

Creates a low-frequency check for a user-authorised record, subject to portal rules, quota, and retention policy.

`pause_or_escalate`

Stops automation when a CAPTCHA, OTP, access denial, suspected mismatch, or unusual portal response occurs.

Never expose a generic tool such as browse_any_url to the agent. Domain allowlists, path restrictions, and method restrictions reduce prompt-injection and SSRF risk.

Handle CAPTCHA and Human-in-the-Loop Workflows Correctly

CAPTCHAs and OTPs are access controls, not technical inconveniences to defeat. Your WebMCP must not attempt to bypass, solve, outsource, or systematically evade them. Instead, return a clear state such as human_action_required.

A compliant workflow can:

1. Pause the automated job.
2. Show the authorised operator the official portal interaction.
3. Allow the operator to complete the permitted step manually.
4. Resume only within the same approved session, if the portal permits it.
5. Record that human intervention occurred without storing unnecessary OTP or CAPTCHA data.

If a portal prohibits automated monitoring altogether, offer a user-assisted workflow: the operator uploads an official document or confirms a result, and the system performs extraction, validation, comparison, and alerting offline.

Extract Indian Land Records Reliably

Land documents often combine English with regional scripts and may be generated as scanned PDFs. A robust extraction pipeline should use multiple stages:

1. File identification: verify MIME type, extension, size, and document origin.
2. Text extraction: use PDF text layers where available.
3. OCR fallback: render scanned pages at suitable resolution and run language-specific OCR.
4. Layout analysis: identify tables, headings, seals, footnotes, and page numbers.
5. Field mapping: map state-specific labels to a canonical schema.
6. Validation: check dates, numeric fields, hierarchy, identifier formats, and page consistency.
7. Human review: route low-confidence or legally material fields for verification.

A canonical schema might include:

State, district, sub-district, tehsil, village, ward, or mandal.
Survey, khasra, khata, patta, dag, plot, or parcel identifier.
Area and unit, normalised while preserving the original value.
Recorded owner or rights-holder names, including original script.
Tenure, land classification, usage, and ownership share where available.
Mutation or transaction reference and status.
Record date, issue date, retrieval timestamp, and issuing authority.
Source URL, document filename, page number, OCR engine, and confidence score.

Do not silently “correct” names or translate them into a single spelling. Store original text, transliteration if used, and the transformation method. Similar-looking names are not proof of identity.

Use Evidence-Based Change Detection

Monitoring should compare evidence, not merely model summaries. Store immutable snapshots with a content hash such as SHA-256, source metadata, and retrieval time. Then classify differences using deterministic rules.

Useful change categories include:

Administrative: district, village, or portal label changed.
Identifier: survey or account number differs.
Rights-holder: owner or recorded rights-holder text changed.
Area: numeric value or unit changed.
Status: mutation, application, or document status changed.
Date: issue, registration, or update date changed.
Document integrity: pages, signature blocks, QR codes, or reference numbers differ.

A simple alert should state old value, new value, source document, retrieval times, confidence, and required review. Avoid claiming that a change is legally valid, fraudulent, or proof of title. Land records can contain errors, pending mutations, or administrative updates; legal interpretation belongs to qualified professionals and authorities.

Security, Privacy, and Compliance in India

Land records may contain personal names, addresses, transaction references, and other sensitive information. Design for data minimisation and accountability from the beginning.

Key controls include:

Collect only fields required for the monitoring objective.
Obtain a documented lawful basis and user authorisation.
Encrypt data in transit and at rest.
Keep portal credentials, session tokens, and downloaded documents in separate protected stores.
Use role-based access and short-lived credentials.
Redact personal information from logs and agent prompts where possible.
Define deletion and retention schedules.
Maintain access, export, correction, and incident-response procedures.
Review obligations under India’s Digital Personal Data Protection Act, 2023, applicable rules, contracts, and sector-specific requirements.
Respect official portal terms, published APIs, access limits, and notices.

Also secure the agent layer. Treat portal content as untrusted input because a page, PDF, or OCR result could contain prompt-injection text. The agent should never follow instructions embedded in a land document, change its own policy, disclose secrets, or call an unapproved tool.

Observability and Reliability Engineering

Government portals can be slow, intermittently unavailable, or redesigned. Build operational controls rather than allowing the agent to retry aggressively.

Track:

Adapter success and failure rates by state.
HTTP status and portal error categories.
CAPTCHA and human-intervention frequency.
Extraction confidence and field-level validation failures.
Median and maximum response time.
Document hash collisions or unexpected content changes.
Alert delivery success.
Number of requests per portal, user, and time window.

Use exponential backoff, circuit breakers, caching where permitted, and a strict request budget. Do not run concurrent requests merely to reduce latency. A failed job should produce an actionable status such as portal_unavailable, invalid_hierarchy, record_not_found, manual_action_required, or adapter_outdated.

Create synthetic tests with approved fixtures and a small set of known public examples. Test regional scripts, scanned documents, missing fields, duplicate names, unit conversions, and portal redesigns. Every adapter change should pass regression tests before deployment.

Recommended Technical Stack

A practical implementation can use:

API gateway: FastAPI, Node.js, or another typed service framework.
Schemas: JSON Schema, OpenAPI, or typed models for every WebMCP tool.
Browser automation: Playwright or equivalent, limited to approved domains and workflows.
Queues: Redis, RabbitMQ, or a managed task queue for scheduled checks.
Storage: PostgreSQL for metadata and object storage for original documents.
Search: OpenSearch or PostgreSQL full-text search, with access controls.
OCR: A multilingual OCR pipeline selected for the scripts used by each state.
Comparison: deterministic normalisation plus field-level diffing; use an LLM only for explanation, not authoritative extraction.
Monitoring: metrics, structured logs, traces, and alerting.
Secrets: a managed secrets vault with rotation and audit logs.

Keep the agent-facing contract stable even when an adapter changes. This prevents prompt logic and downstream applications from depending on fragile portal HTML.

Deployment Roadmap

A phased rollout reduces both technical and compliance risk:

Phase 1: Offline document intelligence

Accept user-provided official PDFs or images. Implement OCR, schema mapping, confidence scoring, comparison, and alerts without automated portal access.

Phase 2: One-state public workflow

Select one portal with a clear permitted public search flow. Build an adapter, rate limits, evidence capture, and human escalation.

Phase 3: Multi-state adapter registry

Add states one at a time using capability metadata, contract tests, regional-language extraction, and independent compliance review.

Phase 4: Scheduled monitoring

Introduce low-frequency schedules, change thresholds, notification channels, and automatic pause conditions.

Phase 5: Enterprise controls

Add tenant isolation, approval workflows, retention policies, legal review, billing quotas, and detailed audit exports.

Common Failure Modes to Avoid

Treating all Bhulekh portals as identical.
Using an LLM to guess missing survey numbers or owner names.
Bypassing CAPTCHA, OTP, rate limits, or access restrictions.
Storing only the latest extracted values without original evidence.
Ignoring regional scripts and scan quality.
Alerting on OCR noise as if it were a legal change.
Claiming that a record proves ownership or title.
Allowing an agent to browse arbitrary websites.
Retrying a failing government portal at high concurrency.
Failing to notify users when an adapter becomes unsupported.

FAQ

Can a WebMCP monitor every Indian state from one connector?

No. Use a common tool contract with separate, versioned state adapters. Portal workflows, identifiers, languages, authentication, and documents vary significantly.

Should the agent solve CAPTCHAs?

No. CAPTCHAs are access controls. Pause the workflow for authorised human action or use a document-upload workflow when permitted.

Can OCR determine legal ownership?

No. OCR can extract text from an official document, but it cannot establish title, resolve disputes, or replace verification by competent authorities and legal professionals.

How often should records be checked?

Use the lowest frequency that meets the business need and complies with portal policies. Event-driven checks, manual confirmation, or monthly monitoring may be more appropriate than frequent polling.

What is the most important engineering principle?

Preserve provenance. Every extracted field and alert should be traceable to an official source, document version, page, retrieval time, and confidence score.

Apply for AI Grants India

Building a compliant WebMCP for India’s land-record ecosystem requires product, AI, security, and public-sector technology expertise. Apply to AI Grants India to explore support for your Indian AI venture.