How to Build a WebMCP for Medicine Search

AI agents can help people locate affordable generic medicines—but only if they can access trustworthy, structured and current availability data. A WebMCP (Web Model Context Protocol) integration can expose Jan Aushadhi search capabilities as controlled tools that agents call on behalf of users, while preserving source links, location context and safety boundaries.

This guide explains how to build a WebMCP for agents to search for generic medicine availability on the Jan Aushadhi portal. It focuses on practical architecture, portal integration, agent-tool design, India-specific healthcare safeguards and production reliability. It does not replace a prescription, pharmacist consultation or official stock confirmation.

What a WebMCP should do

A WebMCP is a browser-facing or web-application integration that makes selected website capabilities available to an AI agent through structured, permissioned tools. For a Jan Aushadhi use case, the core workflow is:

1. The user provides a medicine name, strength, dosage form and location.
2. The agent normalises the request without changing the clinical intent.
3. A WebMCP tool searches the official Jan Aushadhi portal or an authorised data interface.
4. The tool returns matching generic products and nearby Kendra results.
5. The agent presents availability as time-sensitive information, with the official source and a recommendation to confirm by phone or in person.

The system should answer “where might this medicine be available?”, not “what medicine should I take?” Avoid diagnosis, substitution recommendations or dosage changes unless the product is explicitly designed and governed for those functions.

Define the search contract before writing code

Start with a narrow tool contract. A useful first version can support medicine and location search without exposing unrestricted browser automation.

Suggested input schema

{
  "medicine_query": "metformin 500 mg tablet",
  "location": {
    "pincode": "110001",
    "city": "New Delhi",
    "state": "Delhi"
  },
  "radius_km": 10,
  "language": "en"
}

Use JSON Schema or an equivalent validator to enforce:

A non-empty medicine query with a reasonable maximum length.
Valid six-digit Indian PIN codes when a PIN is supplied.
A bounded radius, such as 1–50 km.
An allow-list of supported languages.
No unnecessary personal data, medical history or identity details.

Suggested output schema

{
  "query": {
    "original": "metformin 500 mg tablet",
    "normalised": "metformin 500 mg tablet"
  },
  "results": [
    {
      "medicine_name": "...",
      "strength": "...",
      "dosage_form": "...",
      "kendra_name": "...",
      "address": "...",
      "phone": "...",
      "distance_km": 3.2,
      "availability_status": "reported_or_portal_result",
      "checked_at": "2026-09-03T10:30:00Z",
      "source_url": "https://..."
    }
  ],
  "warnings": [
    "Stock can change; confirm with the Kendra before travelling."
  ]
}

Do not return “in stock” unless the official source explicitly provides live stock data. If the portal only provides store or catalogue information, use a precise status such as location_found, catalogue_match, or availability_unconfirmed.

Understand the Jan Aushadhi portal integration surface

Before selecting an implementation method, inspect the official portal’s terms, robots policy, user interface and available public interfaces. Do not assume that a browser page has a permitted or stable API.

There are three common integration paths:

1. Official API or data feed

This is the preferred option. Request documented access from the relevant programme or portal operator, obtain credentials, understand rate limits and confirm whether commercial or AI-agent use is permitted. An API usually provides better consistency, authentication, observability and change management than scraping.

2. Official deep links and user-assisted search

If no API is available, your WebMCP can generate a validated search URL or open the official portal with the user’s query prefilled. The agent can explain how to complete the search, rather than silently extracting data. This is often the safest fallback when automation permission is unclear.

3. Server-side retrieval with explicit permission

If the portal permits automated access, use a controlled backend connector. Follow terms of service, robots directives, rate limits and copyright requirements. Never bypass CAPTCHA, authentication barriers, access controls or technical restrictions. Cache only what is allowed and display the retrieval timestamp.

A production system should isolate the portal adapter from the agent layer. If the portal changes its HTML or endpoint, update one adapter rather than rewriting the entire agent integration.

Reference architecture for a production WebMCP

A robust architecture can contain these components:

Agent client: interprets the user’s request and decides whether to call a tool.
WebMCP tool endpoint: publishes the search tool and validates input and output.
Query normaliser: parses medicine name, strength, form, language and location.
Jan Aushadhi adapter: calls the authorised API, deep link or permitted retrieval method.
Medicine matching layer: ranks exact and near matches without making clinical substitutions.
Geospatial service: converts PIN code or address into a search area, using minimal location data.
Cache: stores short-lived responses where permitted, with freshness metadata.
Audit and monitoring layer: records tool calls, errors, latency and source timestamps without storing sensitive health data unnecessarily.

A simple request path is:

User → Agent → WebMCP validation → Normaliser → Jan Aushadhi adapter
     ← Structured results ← Freshness and safety checks

Keep credentials and portal requests on the server side. The browser should never receive upstream API keys, internal endpoints or unrestricted scraping controls.

Build the medicine query normaliser

Users may enter brand names, spelling variants, abbreviations or incomplete descriptions. Normalisation improves search quality, but it must not silently alter the request.

Useful fields include:

Active ingredient or user-entered medicine name.
Strength, such as 500 mg or 10 ml.
Dosage form, such as tablet, capsule, syrup or cream.
Release type, such as extended-release where explicitly supplied.
Pack size, if relevant to the portal listing.
Language and transliteration.

Use a controlled vocabulary or medicine reference dataset only to improve matching and display. Do not infer a therapeutic equivalent merely because two products appear similar. When the input is ambiguous, ask a clarifying question: “Do you mean metformin 500 mg immediate-release tablet, or another strength/form?”

A safe matching policy is:

1. Exact ingredient, strength and form.
2. Exact ingredient and strength, form unknown.
3. Ingredient-only results clearly labelled as broader matches.
4. No automatic substitution across active ingredients, strengths or release types.

Design WebMCP tools with least privilege

Expose one focused tool rather than a general-purpose “browse any website” capability. For example:

{
  "name": "search_janaushadhi_medicine_availability",
  "description": "Find official Jan Aushadhi catalogue or Kendra results for a medicine and Indian location. Does not prescribe, substitute, or guarantee live stock.",
  "inputSchema": {
    "type": "object",
    "required": ["medicine_query", "location"],
    "properties": {
      "medicine_query": {"type": "string", "maxLength": 160},
      "location": {"type": "object"},
      "radius_km": {"type": "number", "minimum": 1, "maximum": 50}
    }
  }
}

Add controls for:

Request timeouts and retry limits.
Per-user and per-IP rate limits.
Circuit breakers when the official portal is unavailable.
Response-size limits to prevent prompt flooding.
Source URL validation against approved Jan Aushadhi domains.
Structured error codes, such as PORTAL_UNAVAILABLE, NO_MATCH and LOCATION_REQUIRED.

The agent should not be able to modify portal records, submit orders or claim a reservation unless those actions are separately authorised, reviewed and explicitly supported by the official system.

Handling availability accurately

Availability is the most important reliability problem. A directory entry does not necessarily mean that a product is physically in stock. Your result model should distinguish at least four states:

Kendra found: a nearby Jan Aushadhi store matches the location search.
Catalogue match: the medicine appears in an official catalogue or search result.
Availability reported: the official interface reports a stock status, with a timestamp.
Unconfirmed: the system cannot verify current stock.

Always show checked_at in the user’s local time or clearly label it as UTC. Include a “confirm before travel” warning and, where available, the Kendra’s official phone number. Do not invent phone numbers, opening hours, prices or stock levels.

If multiple results are returned, rank by:

1. Exact medicine match.
2. Availability confidence.
3. Distance from the supplied location.
4. Freshness of the result.
5. Completeness of address and contact details.

India-specific privacy, safety and compliance considerations

Medicine searches can reveal health interests, even when no patient name is provided. Apply data minimisation and privacy-by-design principles:

Avoid collecting Aadhaar, prescriptions, patient IDs or full addresses unless essential.
Prefer PIN code, city or approximate location over precise GPS coordinates.
Encrypt data in transit and at rest.
Define retention periods for search logs and delete raw queries when they are no longer needed.
Redact medicine queries from analytics where feasible, or aggregate them.
Publish a privacy notice explaining tool calls, third-party services and retention.
Provide a way to report incorrect listings or unsafe responses.

For India deployments, obtain legal review for applicable requirements under the Digital Personal Data Protection framework, contractual portal terms and sector-specific healthcare obligations. If your product provides clinical recommendations, it may trigger substantially different medical-device, professional-practice and safety requirements than a directory search tool.

Include a clear disclaimer: the tool provides information about official listings or reported availability; it does not diagnose conditions, prescribe treatment or guarantee stock. For urgent symptoms, direct users to a qualified clinician or emergency service rather than continuing a search workflow.

Testing strategy for the agent and connector

Test the system at three levels.

Contract tests

Verify that invalid PIN codes, empty queries, oversized input, unsupported languages and excessive radius values are rejected. Confirm that every successful result includes a source and timestamp.

Integration tests

Use a sandbox, approved test endpoint or recorded fixtures where available. Test portal timeouts, changed field names, empty responses, duplicate Kendras, malformed addresses and rate-limit responses. Do not run aggressive automated tests against the live portal.

Agent evaluation

Create test prompts covering:

Brand-name queries that require clarification.
Missing strength or dosage form.
Hindi and other Indian-language transliteration.
A location with no nearby results.
Requests to recommend a substitute.
Prompt injection embedded in a page result.
Claims that a medicine is definitely in stock.

The agent should preserve uncertainty, refuse unsafe substitution and treat retrieved page content as untrusted data—not as instructions. Measure exact-match accuracy, false availability claims, source citation rate, latency and tool-call failure rate.

Deployment and observability

Deploy the WebMCP endpoint behind HTTPS, authentication where appropriate and a web application firewall. Use environment-managed secrets, dependency scanning and regular access reviews. Separate development, staging and production credentials.

Track operational metrics such as:

Search success rate.
Portal response latency and timeout rate.
No-result rate by query type.
Freshness of cached responses.
Exact-match and user-correction rates.
Number of unsupported clinical requests.
Errors by portal adapter version.

Set alerts for sudden changes in result volume, HTML structure, response schema or source-domain redirects. A human review queue is useful for recurring false matches and reports of incorrect store information.

A practical launch plan

A low-risk roadmap is:

1. Discovery: confirm official access options, terms, data fields and permitted automation.
2. Prototype: implement one read-only search tool with mocked responses.
3. Pilot connector: integrate an approved API or user-assisted official search flow.
4. Safety review: test ambiguity, substitution requests, privacy and availability language.
5. Limited beta: restrict geography, rate and user volume; monitor errors manually.
6. Production hardening: add caching, circuit breakers, audit controls and multilingual UX.
7. Continuous maintenance: review portal changes, data quality and user feedback.

Start with a transparent “find a nearby Kendra” experience. Expand only after you can demonstrate reliable source attribution and safe handling of uncertainty.

FAQ

Can an AI agent guarantee that a generic medicine is in stock?

No. Unless an authorised official system provides current stock data, the agent should report only a catalogue or location result and advise the user to confirm with the Kendra.

Is scraping the Jan Aushadhi portal allowed?

It depends on the portal’s terms, robots policy and technical controls. Prefer an official API or permission-based integration, and never bypass CAPTCHA, authentication or access restrictions.

Can the WebMCP recommend a substitute medicine?

A search tool should not automatically recommend therapeutic substitutes. Ingredient, strength and dosage-form decisions should be made by a qualified healthcare professional.

What is the best first tool to build?

Build a read-only, narrowly scoped search tool that accepts medicine details and a PIN code, returns official source links and timestamps, and clearly separates catalogue matches from confirmed availability.

Apply for AI Grants India

Building a trustworthy healthcare or public-benefit AI product in India? Apply to AI Grants India for support, visibility and grant opportunities to move your agent-enabled solution from prototype to responsible deployment.