Apply for AI Grants India

AI agents increasingly need to verify whether an Indian business is registered as a micro, small or medium enterprise (MSME). A WebMCP tool can expose a controlled, machine-readable verification capability to agents while keeping authentication, consent, validation and auditability inside your application boundary.

This guide explains how to create a WebMCP tool for agents to verify Udyam Registration details without treating an agent prompt as proof of identity or authorization. It focuses on a production-oriented design for Indian fintech, procurement, lending, compliance and B2B platforms.

What is WebMCP?

WebMCP is a pattern for making website capabilities available to AI agents through structured tools. Instead of asking an agent to scrape a page or interpret an unstructured document, you define an explicit operation with:

• A stable tool name
• A machine-readable input schema
• Clear authentication and authorization rules
• Typed outputs and error states
• Human-readable explanations and citations
• Rate limits, logging and abuse controls

For Udyam verification, the tool should not simply return a Boolean such as registered: true. It should provide a verifiable result, the source and retrieval time, the fields checked, and the limitations of the check.

Define the verification use case first

“Verify Udyam details” can mean several different things. Define the exact business decision before designing the tool. Common checks include:

• Confirming that a Udyam Registration Number has the expected format
• Checking whether the number exists in an authorized verification source
• Matching the registered enterprise name with a user-provided name
• Comparing the enterprise address or state with submitted information
• Checking the broad MSME classification returned by the source
• Confirming that the record was retrieved recently
• Producing evidence for an underwriting, onboarding or procurement workflow

Avoid claiming more than your source can establish. A successful lookup may show that a registration record was returned; it may not prove that the person using your application owns the enterprise, that the business is currently operating, or that every submitted document is authentic.

A useful verification policy separates three questions:

1. Record validity: Does the identifier correspond to a record in an authorized source?
2. Data match: Do the returned details match the information supplied by the applicant?
3. User authority: Is the requester authorized to obtain or use those details?

Use an authorized data source

The most important implementation decision is the verification source. Udyam data is sensitive business information, and an unofficial scraper or an undocumented endpoint creates legal, security and reliability risks.

Use one of these approaches, subject to current government terms and your organization’s permissions:

• An official Udyam verification or related government integration
• A consent-based data provider with documented authorization
• A regulated or enterprise verification partner that states its source and retention rules
• A user-supplied certificate or record combined with independent checks where permitted

Do not present a third-party lookup as an official government result. Store source metadata such as provider name, endpoint class, terms version and retrieval timestamp. If the source changes its response format, your adapter should fail safely instead of silently mapping incorrect fields.

Reference architecture for a WebMCP Udyam tool

A robust architecture has five layers:

1. Agent-facing WebMCP layer

This layer publishes the tool definition and accepts validated arguments. It should never contain provider-specific credentials or expose unrestricted database access.

2. Policy and authorization layer

Before a lookup, determine whether the requesting user, organization and workflow are permitted to perform it. Apply purpose limitation, consent requirements and tenant isolation here.

3. Verification service

The service normalizes the Udyam number, calls the authorized provider, maps the response into your internal schema and classifies the result.

4. Evidence and audit layer

Store a minimal audit event containing the request purpose, actor, tenant, source, timestamp, result classification and correlation ID. Avoid retaining unnecessary personal or confidential fields.

5. Agent response formatter

Return structured data to the agent, along with a concise explanation of what was checked and what was not checked. Do not return raw provider payloads by default.

A simplified request flow is:

Agent -> WebMCP tool -> authentication -> policy check
      -> identifier validation -> authorized verification adapter
      -> field matching -> audit event -> typed result

Design the tool contract

A tool contract should be narrow and predictable. A possible operation is verify_udyam_registration.

Input schema

{
  "type": "object",
  "additionalProperties": false,
  "required": ["udyam_registration_number", "purpose"],
  "properties": {
    "udyam_registration_number": {
      "type": "string",
      "description": "Udyam Registration Number supplied by the user"
    },
    "expected_enterprise_name": {
      "type": "string",
      "description": "Optional name to compare with the verified record"
    },
    "expected_state": {
      "type": "string",
      "description": "Optional Indian state or union territory to compare"
    },
    "purpose": {
      "type": "string",
      "enum": ["onboarding", "lending", "procurement", "grant_review", "other"]
    },
    "consent_reference": {
      "type": "string",
      "description": "Reference to the consent or authorization event"
    }
  }
}

Do not allow arbitrary URLs, SQL fragments, provider names or raw query parameters in the agent input. The server should choose the source and policy based on configuration.

Output schema

{
  "status": "verified",
  "udyam_registration_number": "UDYAM-XX-00-0000000",
  "enterprise_name": "Example Enterprise",
  "classification": "small",
  "state": "Karnataka",
  "source": {
    "type": "authorized_provider",
    "retrieved_at": "2026-09-03T10:15:00Z"
  },
  "matches": {
    "enterprise_name": true,
    "state": true
  },
  "limitations": [
    "This result confirms a returned registration record and field matches only."
  ],
  "correlation_id": "corr_123"
}

Use controlled statuses such as verified, not_found, mismatch, temporarily_unavailable, consent_required and manual_review. This is safer than forcing every provider response into true or false.

Validate and normalize the Udyam number

Perform basic validation before calling the provider. Udyam numbers follow a recognizable pattern, but your application should treat the pattern as a format check—not proof that the registration exists.

A normalization function should:

• Trim leading and trailing whitespace
• Convert letters to uppercase where appropriate
• Remove accidental visual separators only if your policy permits it
• Reject unexpected Unicode characters and control characters
• Preserve the original input separately for audit or user display
• Apply a maximum length

Example pseudocode:

def normalize_udyam(value: str) -> str:
    if not isinstance(value, str):
        raise ValueError("Registration number must be text")

    value = value.strip().upper()
    if len(value) > 32:
        raise ValueError("Registration number is too long")

    # Apply the exact format accepted by your authorized provider.
    if not matches_approved_format(value):
        raise ValueError("Invalid Udyam Registration Number format")

    return value

Keep format validation separate from existence verification. A syntactically valid identifier can still be nonexistent, inactive, unavailable or incorrectly entered.

Implement the provider adapter

Place provider-specific logic behind an adapter interface. This prevents the WebMCP layer from becoming coupled to one API response format.

class UdyamVerificationProvider:
    async def verify(self, registration_number: str) -> ProviderResult:
        raise NotImplementedError

class AuthorizedProvider(UdyamVerificationProvider):
    async def verify(self, registration_number: str) -> ProviderResult:
        response = await self.client.lookup(
            registration_number=registration_number,
            timeout=5
        )
        return map_provider_response(response)

Production requirements should include:

• Short connect and response timeouts
• Retries only for safe, transient failures
• Circuit breaking when the provider is unavailable
• Idempotency for repeated verification requests
• Response signature or TLS validation where offered
• Secret storage in a managed vault
• Provider-specific rate limits
• Versioned field mapping and contract tests

Never log access tokens, full provider payloads or sensitive identifiers unnecessarily. Redact identifiers in application logs and use a correlation ID to connect events across services.

Add field matching carefully

Matching an enterprise name is not the same as exact string comparison. Indian business names may differ because of punctuation, legal suffixes, spacing, transliteration or abbreviations. Create a conservative normalization function, then retain the original values for review.

Possible normalization steps include:

• Unicode normalization
• Case folding
• Whitespace collapsing
• Standardized punctuation removal
• Controlled handling of common legal suffixes

Do not automatically remove meaningful words or treat a fuzzy match as proof. A useful result can include both a match decision and a review reason:

{
  "field": "enterprise_name",
  "result": "manual_review",
  "similarity": 0.91,
  "reason": "Name differs by legal suffix and abbreviated spelling"
}

For lending or compliance decisions, define thresholds with your legal, risk and operations teams. Agent-generated explanations should not override those thresholds.

Authentication, consent and authorization

A WebMCP tool must not infer authorization from a natural-language request. Use application authentication such as an OAuth-based session, signed user session or service-to-service identity. Then check authorization against the tenant, role and workflow.

Recommended controls include:

• Require an authenticated principal
• Attach every request to a tenant and purpose
• Require consent or another lawful authorization basis where applicable
• Use short-lived access tokens
• Restrict the tool to approved workflows
• Prevent cross-tenant lookups
• Require step-up verification for high-risk actions
• Make consent records immutable and timestamped
• Provide a human-review path for ambiguous results

For India-facing products, align handling with the Digital Personal Data Protection Act, 2023 and applicable rules, sectoral regulations, contractual obligations and government portal terms. Obtain advice for your specific use case; a registration record may contain personal or business-linked information depending on the data returned.

Prompt-injection and agent security

Agents can be manipulated by webpages, users or documents. Treat all external content as untrusted. The verification tool should enforce policy server-side even if the agent is instructed to bypass it.

Use these protections:

• Validate all arguments against a strict schema
• Ignore tool instructions embedded in retrieved webpages
• Do not let the agent select arbitrary verification sources
• Separate data retrieval from decision authorization
• Require explicit confirmation before consequential actions
• Return provenance and limitations with every result
• Apply quotas per user, tenant and IP address
• Detect enumeration patterns such as sequential registration lookups

A tool should verify one requested record for an authorized purpose—not become a bulk discovery interface.

Error handling and result semantics

Design errors for both agents and humans. For example:

| Status | Meaning | Recommended action |
|---|---|---|
| verified | Record returned and required checks passed | Continue permitted workflow |
| not_found | Source returned no matching record | Ask user to recheck or route to review |
| mismatch | Record exists but supplied fields differ | Do not auto-approve |
| consent_required | Authorization is missing or expired | Obtain valid consent |
| temporarily_unavailable | Provider or network failure | Retry later, do not mark invalid |
| manual_review | Ambiguous match or policy exception | Send to trained reviewer |

A provider timeout must never be translated into not_found. That single distinction prevents many false negatives in onboarding and credit workflows.

Testing strategy

Test the tool at multiple levels.

Contract tests

Validate required fields, rejected properties, enums, maximum lengths and stable output types.

Provider tests

Use mocked responses for verified, not-found, mismatch, throttled, malformed and timeout cases. Add tests for provider schema changes.

Security tests

Attempt prompt injection, tenant escape, token replay, enumeration, oversized inputs, log leakage and unauthorized access. Verify that the tool cannot be called without the required purpose and authorization.

Evaluation tests for agents

Measure whether agents:

• Select the tool only when appropriate
• Ask for a missing Udyam number instead of guessing
• Explain temporarily_unavailable correctly
• Avoid claiming that a lookup proves ownership
• Escalate mismatches and ambiguous names
• Preserve the returned limitations

Operational tests

Run load tests within provider quotas and test circuit-breaker recovery. Monitor latency, error rates, provider availability, mismatch rates and manual-review volume.

Observability and auditability

Create structured audit events such as:

{
  "event": "udyam_verification",
  "actor_id": "user_or_service_id",
  "tenant_id": "tenant_456",
  "purpose": "onboarding",
  "registration_hash": "hmac_value",
  "provider": "authorized_provider",
  "status": "verified",
  "retrieved_at": "2026-09-03T10:15:00Z",
  "correlation_id": "corr_123"
}

Hash or tokenize identifiers where full values are not needed for operations. Define retention periods, access controls and deletion procedures before launch. Audit logs should answer who requested the check, why it was requested, which source was used, what result was returned and whether a human overrode the automated outcome.

Build a safe agent-facing explanation

The tool response should help the agent communicate accurately. A recommended explanation is:

> The authorized verification source returned a record for the supplied Udyam Registration Number. The enterprise name and state matched the submitted values. This confirms the lookup result and field comparison; it does not independently prove ownership, current operations or eligibility for a specific scheme.

Keep this explanation generated from typed result fields, not from an unrestricted language-model summary. For high-impact decisions, display the source, retrieval time and review policy to the human operator.

Production checklist

Before exposing the WebMCP tool to real agents, confirm that:

• The data source is authorized and contractually permitted
• Tool input and output schemas are versioned
• Format validation is separate from record verification
• Authentication, tenant isolation and consent checks are enforced server-side
• Timeouts cannot produce false not_found results
• Provider credentials are stored securely
• Logs redact sensitive values
• Enumeration and bulk access are rate-limited
• Prompt injection cannot bypass policy
• Results include source, timestamp and limitations
• Manual review exists for mismatches and ambiguity
• Retention and deletion rules are documented
• Monitoring and incident response are operational

FAQ

Can an AI agent verify a Udyam Registration Number by scraping the government website?

Do not rely on scraping unless it is explicitly permitted and technically appropriate. Prefer an authorized, documented verification integration or provider, and represent its result accurately.

Is a valid-looking Udyam number proof of registration?

No. Format validation only checks whether the input resembles an accepted identifier. Existence and current returned details require a verification lookup.

Should the tool return the complete Udyam record?

Usually not. Return only the minimum fields needed for the declared purpose, plus source, timestamp, match outcomes and limitations.

Can the tool automatically approve an MSME applicant?

The tool should provide evidence for an approved workflow, not make an unreviewed high-impact decision. Apply your organization’s risk, legal and sector-specific controls.

What should happen when the verification provider is down?

Return temporarily_unavailable, preserve the correlation ID, avoid marking the enterprise invalid and route the workflow to retry or manual review.

Apply for AI Grants India

Building an India-focused AI product for compliance, fintech, procurement or enterprise automation? Apply to AI Grants India for support, visibility and opportunities designed for Indian AI founders.