Building a WebMCP to automate the verification of company details on the MCA21 portal requires more than connecting an AI assistant to a browser. MCA21 is a government-facing system with changing workflows, identity and access controls, rate limits, session requirements, and legally relevant company records. A reliable implementation should combine WebMCP tool design, deterministic browser automation, structured data extraction, human review, and strong compliance controls.
This guide explains how to design such a system for Indian AI teams, compliance platforms, lenders, marketplaces, legal-tech products, and internal due-diligence workflows. The objective is not to bypass MCA21 protections or automate CAPTCHA and authentication controls. Instead, the goal is to create a controlled assistant that can locate permitted public information, guide a browser session, capture evidence, and produce an auditable verification result.
What Is a WebMCP?
A WebMCP is a browser-connected Model Context Protocol integration that allows an AI model to interact with approved web tools. In practice, it exposes narrowly defined actions—such as opening an MCA21 page, entering a company identification number, reading a result table, or saving a screenshot—to an AI agent.
A WebMCP should not give the model unrestricted access to the browser. Each operation should be represented as a typed tool with:
- A clear purpose and scope
- Strict input validation
- Explicit permission requirements
- Predictable output schemas
- Timeouts and retry limits
- Audit logging
- Human approval for sensitive actions
For MCA21 verification, the model should act as an orchestrator and explanation layer. The browser automation service should perform deterministic actions, while a validation service checks whether extracted values are complete, plausible, and consistent.
Define the MCA21 Verification Use Case First
Before writing code, specify exactly what “verification” means. Company verification can include different checks, and each may require separate evidence and permissions.
Typical fields include:
- Corporate Identification Number (CIN)
- Legal company name
- Company status, such as active or inactive
- Company category and subcategory
- Class of company
- Date of incorporation
- Registered office state or address, where lawfully available
- Authorised and paid-up capital
- Registrar of Companies jurisdiction
- Last filed balance sheet date
- Last filed annual return date
- Directors or signatories, where permitted and necessary
Create a verification policy that distinguishes between:
1. Identity match: Does the submitted CIN correspond to the legal name?
2. Status check: Is the company shown as active or in another status?
3. Freshness check: When was the record retrieved and when were relevant filings last updated?
4. Evidence check: Can the result be supported by a page capture, document reference, or official output?
5. Exception check: Are there name mismatches, missing fields, inconsistent dates, or portal errors?
Do not claim that a single MCA21 lookup proves beneficial ownership, solvency, regulatory compliance, or current operational activity. Your product language should accurately describe what the source record establishes.
Recommended WebMCP Architecture
A production-grade system should separate the AI layer from browser control and data processing. A practical architecture has six components.
1. User and policy layer
Collect the applicant’s company name, CIN, purpose of verification, and consent or authorization where required. Apply tenant-specific rules, such as whether the customer may request only public master data or also filing documents.
2. WebMCP server
The WebMCP server publishes safe, typed tools to the model. It should not expose arbitrary JavaScript execution, unrestricted navigation, credential access, or file-system operations.
3. Browser worker
A Playwright- or Selenium-based worker opens the approved MCA21 domain and performs deterministic actions. Keep the worker isolated in a container or sandbox. Use a visible browser mode during development to understand the workflow, and avoid stealth techniques intended to evade portal controls.
4. Extraction and normalization service
Convert page content into a stable internal schema. Normalize whitespace, dates, capitalization, currency values, and missing-value indicators without changing the underlying source meaning.
5. Validation and evidence service
Validate the CIN format, compare submitted and returned names, calculate confidence, store source timestamps, and attach permitted evidence such as screenshots or exported records.
6. Audit and review layer
Record who initiated the check, which tool calls occurred, what source was visited, which values were extracted, what exceptions arose, and who approved the final result.
A simplified flow is:
User request
-> Policy checks
-> WebMCP tool call
-> Browser worker
-> MCA21 result
-> Structured extraction
-> Validation and evidence
-> Human review or final reportDesign the WebMCP Tools as Narrow Contracts
Avoid a single tool such as control_browser that accepts arbitrary commands. Prefer small tools with typed parameters and bounded behaviour.
Example tool set:
mca21_open_public_search()
mca21_search_company(cin: string)
mca21_read_company_profile()
mca21_capture_evidence(format: "png" | "pdf")
mca21_close_session()The mca21_search_company tool should validate that the CIN follows the expected structure before opening the page. It should reject suspicious URLs, unsupported domains, and unreasonably long inputs.
A structured response might look like:
{
"source": "MCA21",
"retrieved_at": "2026-09-03T10:30:00Z",
"cin": "U12345MH2020PTC123456",
"legal_name": "Example Technologies Private Limited",
"company_status": "Active",
"date_of_incorporation": "2020-06-18",
"registered_state": "Maharashtra",
"evidence_id": "ev_01J...",
"warnings": []
}Every field should have a defined type and provenance. If a value is not displayed, return null with a reason such as not_available, not_authorized, or parse_error. Never silently convert an unavailable field into an empty string.
Build Safe Browser Automation for MCA21
Government portals can change their HTML, labels, menus, and session behaviour. Use resilient selectors and verify each state transition.
Recommended practices include:
- Restrict navigation to an allowlisted MCA21 domain and approved paths.
- Wait for visible page states rather than fixed sleeps alone.
- Use accessible labels, role selectors, and stable attributes where available.
- Capture the page title and URL after navigation.
- Detect portal maintenance pages, errors, and expired sessions.
- Set reasonable page, network, and total-job timeouts.
- Stop when CAPTCHA, OTP, login, or manual verification is required.
- Never attempt to solve or bypass CAPTCHA automatically.
- Avoid high-frequency polling and parallel requests against the portal.
- Preserve the browser’s normal user-agent and respect published terms and policies.
For example, the worker can implement a state machine:
START
-> OPEN_ALLOWED_PAGE
-> WAIT_FOR_SEARCH_FORM
-> ENTER_CIN
-> SUBMIT
-> WAIT_FOR_RESULT_OR_CHALLENGE
-> READ_RESULT
-> CAPTURE_EVIDENCE
-> RETURN_STRUCTURED_DATAIf the state becomes CHALLENGE_DETECTED, the job should pause and ask an authorized user to continue manually, or terminate with a clear reason. It should not guess whether a challenge is safe to ignore.
Handle MCA21 Data Extraction Carefully
Do not rely solely on an AI model to read raw HTML. Use deterministic extraction first, then use the model only to interpret ambiguous labels or explain results.
A robust extraction pipeline should:
1. Identify the expected result container.
2. Map labels to canonical field names.
3. Strip presentation-only elements.
4. Preserve the original displayed value.
5. Normalize a separate machine-readable value.
6. Record the selector or evidence location.
7. Mark missing and ambiguous fields explicitly.
For dates, store both the original text and an ISO representation. For addresses, preserve line breaks in the evidence copy while creating a normalized search form separately. For company names, compare using a cautious normalization function that handles case and whitespace but does not remove legally meaningful terms such as “Private,” “Limited,” or “LLP.”
A CIN validator can check length and character patterns, but format validation is not proof that a CIN exists. Treat the official portal response as the source-of-record result for the specific lookup.
Add Verification Rules and Confidence Levels
A useful report should show how the result was reached. Example rules include:
- Pass: Returned CIN exactly matches the requested CIN.
- Pass with warning: CIN matches, but the submitted legal name differs after normalization.
- Review required: Portal returned a result but one or more critical fields are missing.
- Fail: No matching company record was returned.
- Blocked: A CAPTCHA, login, OTP, outage, or access restriction prevented completion.
Use confidence carefully. A high extraction confidence means the system read the page reliably; it does not mean the company is financially sound or trustworthy. Separate these concepts in the user interface:
- Source retrieval confidence
- Field extraction confidence
- Identity matching result
- Business or compliance decision
The last category should require additional data sources and human or policy-based review.
Security, Privacy, and Indian Compliance Considerations
Company information may be public, but your workflow can still process personal data belonging to directors, employees, customers, or authorized representatives. Apply data minimisation and purpose limitation.
Key controls include:
- Collect only fields necessary for the stated verification purpose.
- Encrypt data in transit and at rest.
- Use tenant isolation for multi-customer deployments.
- Redact personal identifiers from logs where practical.
- Apply role-based access to evidence and reports.
- Set retention and deletion schedules.
- Maintain an incident response process.
- Review obligations under India’s Digital Personal Data Protection Act, 2023, where applicable.
- Confirm contractual, portal, and copyright permissions before storing or redistributing records.
Do not store MCA21 credentials in prompts, model memory, browser logs, or screenshots. If an authenticated workflow is legitimately required, use a secure secrets manager, short-lived sessions, and explicit user interaction. The automation must not defeat access controls.
Observability and Auditability
A production system needs more than application logs. Record structured events such as:
{
"job_id": "job_123",
"actor_id": "user_456",
"action": "mca21_search_company",
"input_hash": "sha256:...",
"source_url": "https://...",
"result": "success",
"retrieved_at": "2026-09-03T10:30:00Z",
"evidence_id": "ev_01J..."
}Keep secrets, raw personal data, and model prompts out of general-purpose logs. Monitor:
- Success and blocked-job rates
- Portal response times
- Selector failures
- Field-level extraction errors
- CAPTCHA or authentication encounters
- Duplicate requests
- Evidence storage failures
- Changes in page structure
Create alerts for sudden increases in failures rather than automatically increasing retries. Excessive retries can create load and may trigger further restrictions.
Testing Strategy
Test the WebMCP at four levels.
Unit tests
Test CIN validation, name normalization, date parsing, schema validation, redaction, and policy decisions with synthetic data.
Browser contract tests
Use a controlled local fixture or approved test environment that mimics the expected MCA21 result structure. Test successful results, no-match responses, partial records, validation errors, expired sessions, and challenge pages.
Integration tests
Run low-volume tests against the live portal only when permitted and necessary. Keep them scheduled, rate-limited, and monitored.
Human acceptance tests
Ask compliance or operations users to review whether the evidence is understandable, whether warnings are prominent, and whether a reviewer can reproduce the result from the audit trail.
Common Failure Modes to Avoid
- Unrestricted browser agent: The model can navigate to arbitrary pages or exfiltrate data.
- CAPTCHA bypass attempts: This creates legal, ethical, and operational risk.
- Scraping without policy review: Public accessibility does not automatically grant unlimited reuse rights.
- Silent retries: Repeated submissions can overload the portal and hide the real failure.
- Model-only extraction: Language models can hallucinate fields or confuse labels.
- No evidence capture: A result without provenance is difficult to defend in due diligence.
- Overstated conclusions: MCA21 master data does not establish every aspect of company legitimacy.
- Ignoring UI changes: Selectors and page flows can change, so monitor and version your adapters.
Suggested MVP Roadmap
Start with a narrow, reviewable product:
1. Accept a CIN and verification purpose.
2. Open only the approved public MCA21 workflow.
3. Require manual completion of any challenge or authentication step.
4. Extract a small set of fields: CIN, legal name, status, incorporation date, and retrieval timestamp.
5. Display source values alongside normalized values.
6. Capture permitted evidence.
7. Require human approval before issuing a report.
8. Add monitoring and failure taxonomy.
9. Expand to filing metadata only after permissions, storage, and accuracy controls are ready.
This approach makes it easier to prove reliability and avoid building an opaque “autonomous scraper” that fails when the portal changes.
FAQ: WebMCP and MCA21 Verification
Can a WebMCP automatically solve MCA21 CAPTCHA?
No. A compliant design should detect CAPTCHA or other challenges and pause for an authorized human or return a blocked status. It should never attempt to bypass security controls.
Is MCA21 data enough for complete company due diligence?
No. MCA21 can support specific corporate-record checks, but broader due diligence may require tax, litigation, sanctions, licensing, financial, beneficial ownership, and other authorized sources.
Should the AI model directly control Playwright?
Prefer a constrained browser worker behind typed WebMCP tools. The model can request approved actions, while the worker enforces domains, parameters, timeouts, authentication boundaries, and audit logging.
How often should company details be reverified?
It depends on risk and use case. Record the retrieval timestamp and define a freshness policy—for example, recheck before onboarding, lending, contracting, or other material decisions.
Can startups commercialize an MCA21 verification product?
Potentially, but they should review MCA21 terms, applicable laws, data protection obligations, contracts, and the rights to store or redistribute retrieved content. Obtain legal advice for the intended workflow and customer segment.
Apply for AI Grants India
Building a compliant WebMCP for MCA21 verification can become a valuable India-focused AI infrastructure product when it combines technical reliability, responsible automation, and clear user safeguards. Apply to AI Grants India for support, visibility, and opportunities relevant to Indian AI founders.