Completing a government process can involve finding the responsible department, interpreting requirements, collecting documents, and working out why an application cannot proceed. When several authorities are involved, the person also coordinates the handoffs: carrying information between websites, repeating details, and tracking separate decisions.

WebMCP could reduce that effort by giving AI assistants a structured way to interact with government websites alongside the user.

From navigating pages to completing tasks

With WebMCP, a website exposes selected functions as tools an assistant can call. A department could provide tools for retrieving requirements, finding appointments, checking application fields, or returning case status. The website specifies what each function does and what information it needs, reducing the assistant’s reliance on interpreting layouts and clicking through pages. WebMCP documentation.

The assistant could help prepare an application while keeping the information visible for review. The user could correct details, approve consequential actions, or continue manually.

WebMCP handles browser-based interaction. MCP more broadly connects AI applications to external tools and systems. Neither automatically connects government databases or grants permission to share personal information. WebMCP remains an emerging specification.

Helping people use everyday services

Consider these hypothetical applications:

  • Social support: An assistant helps someone find relevant schemes, retrieve their requirements, and prepare an application. The department’s validation tools identify missing information before submission; the authority still determines entitlement.
  • Transport and healthcare administration: An assistant retrieves renewal or appointment requirements, finds available slots, and helps book or reschedule. Users can manage the process with less navigation and telephone coordination.
  • Municipal services: A resident describes a broken streetlight and provides its location. The assistant prepares a structured report, retrieves confirmation, and helps follow its status.

The benefit depends on the website providing accurate requirements, useful functions, and meaningful responses. An assistant needs to distinguish an application received from an application approved.

Conversational or voice assistance could also offer another way through complex interfaces. Its usefulness should be tested with the people concerned, while accessible websites and human support remain available.

Coordinating processes across departments

The larger opportunity appears when one department needs information or a decision from another.

Suppose a housing application requires an official income statement. An assistant could check the housing department’s evidence requirements, help obtain the matching statement from the tax portal, and prepare it for submission with the user’s approval. This could reduce back-and-forth over missing or outdated evidence. The assistant would need to preserve the official document and account for differences in the departments’ definitions of income.

Applying the idea to EasyGov

EasyGov already brings many Swiss government services into one portal. Its 2026 evaluation, however, identifies recurring difficulties with finding processes and messages in the Cockpit and Inbox. Some users also describe corrections that require repeating entire sequences of steps.

Before choosing a workflow for the pilot, I would observe users returning to pending applications and review related support requests. I would distinguish difficulty finding an item from difficulty understanding or completing its next step, then use the frequency and effort involved to decide where assistance is worth testing. An initial pilot could give a browser assistant access, through WebMCP, to the signed-in user’s open items and their statuses. The assistant could locate the relevant message, explain the requested action, and open the appropriate step, with the original information available for review.

Correction support could extend this approach. If previous answers are available and the portal exposes suitable form actions, the assistant could reuse answers that remain valid and apply the requested changes. WebMCP supports populating forms for user review before submission. This could reduce repetitive work even where the process still requires starting again. Whether the submission updates an existing case or creates a new one would depend on the service’s implementation.

I would compare the assisted experience with the current portal and targeted improvements to navigation and forms. The measures would be time to complete the task correctly, errors, and help required, alongside implementation and maintenance costs. A clearer inbox might address the navigation problem sufficiently, while assistance with repeated form entry could offer additional value. The priority would follow the observed benefit for each task.

What government teams could gain

Better-prepared applications could reduce missing-document requests and correction work. Clearer status information could reduce routine enquiries, leaving staff more time for cases requiring judgment or personal support.

Departments could introduce selected WebMCP functions incrementally, reusing suitable website logic rather than replacing an entire service. Complex interfaces may still need refactoring, and exposed functions need maintenance as requirements change. WebMCP project documentation.

The benefits should be assessed through completion, accuracy, user effort, staff workload, and operating cost. Easier access may increase legitimate demand, so success would not necessarily mean lower total spending.

WebMCP cannot resolve unclear policy, create appointment capacity, or accelerate an internal decision simply by making its website easier to use. Those problems require changes to the service itself.

How it could be abused, and what can reduce the risk

Hoarding appointments or flooding departments with submissions. Automated access could consume scarce bookings or generate duplicate cases. Appropriate reservation limits, fair queues, duplicate detection, and monitoring can protect capacity. These controls must apply to the underlying service, whichever interface is used. OWASP guidance on automated abuse.

Accessing private records. Every request must be checked against the person’s permission to access that record and perform that action. A case number is not authorization, and tools should return only the information needed. OWASP access-control guidance.

Manipulating an assistant. Malicious instructions embedded in documents or comments could attempt to redirect the assistant or disclose information. Separating untrusted content, restricting destinations, and limiting available actions reduce exposure. Departments and assistant providers share responsibility; model instructions alone cannot guarantee protection. Agent-security guidance.

Making unapproved changes or skipping checks. Consequential actions need clear review and authorization tied to the exact transaction. The server must enforce prerequisites even when an assistant calls a function directly. A tool description or confirmation hint cannot replace those controls. Transaction-authorization guidance.

Departments also need protected audit records, clear receipts, and a way to dispute unauthorized actions. An affected function should be suspendable without removing access to the service.