WebMCP · Beta proposal

WebMCP — beta: your website, an entry point for assistants

On your domain, make your products and services accessible to compatible assistants. Your work OS defines the public information and authorized requests.

On this page
  1. Your domain, your services
  2. Three workflows to consider
  3. The same public scope as your MCP access
  4. Unauthenticated does not mean uncontrolled
  5. What exists today and what the beta prepares
  6. Compatibility and setup
  7. Today, the beta proposal and the next validation

Your domain, your services

A visitor is looking for a service, comparing products or asking for an appointment. The WebMCP proposal makes these workflows accessible from a page under your company’s identity, in a compatible browser and assistant.

The aim is not to create another mobile app. Your website becomes an entry point to your work OS services. The domain, selected functions and their connection are defined when scoping the beta.

Three workflows to consider

Browse a catalogue: find published products or services, their descriptions and public conditions. Understand an offer: identify a service relevant to a request using validated information. Request an appointment: prepare a request with the information required by the selected workflow.

These examples describe the intended scope, not three business tools already delivered on every domain. An appointment request guarantees neither availability nor a confirmed booking. Responses must reflect the actual result returned by the service.

The same public scope as your MCP access

The target is to offer the same public capabilities as unauthenticated MCP access: the same published catalogue, rules and authorized services. The WebMCP page and MCP connection are two entry points to your work OS functions.

WebMCP exposes tools in a compatible web page; MCP lets a client discover and call server tools. Both surfaces can share business functions without every browser call necessarily passing through the MCP server. Parity must be verified function by function.

Unauthenticated does not mean uncontrolled

An unidentified visitor can access only information and services explicitly made public. A customer file, private document or personal information requires the identification process and permissions defined for that operation.

Permissions are checked on the server. The page or assistant does not independently decide which company or data to access. A consequential action must follow its approval process; a reading tool must not submit a request without the visitor’s knowledge.

What exists today and what the beta prepares

The AlefOS public website already includes a WebMCP discovery integration: explain AlefOS, scope a need, search documentation and suggest a useful page. It registers its tools when the compatible browser API is available. These functions concern the website’s public information.

The current tools are alefos_explain, alefos_scope_application, alefos_search_docs and alefos_open_page. They are not yet a customer product catalogue or an appointment tool connected to that customer’s OS. Deployment for individual companies and equivalence with public MCP capabilities remain the scope to build and validate in the beta.

Compatibility and setup

WebMCP is still evolving. Availability depends on the browser, its version and the assistant; support is not promised across all ChatGPT, Claude or other assistants. Without WebMCP support, the website and its links remain usable normally.

Setup must specify the domain, published information, enabled tools and identification workflows. Results, access denials and errors must also be verified. The beta describes a product direction and scope to assess, with no universal compatibility guarantee or announced availability date.

Today, the beta proposal and the next validation

Today, AlefOS public discovery can explain the product, scope a need, search documentation and suggest a page. The beta proposal concerns company-domain access to selected public services, such as a published catalogue or an appointment request.

Before using a company workflow, validate the tools, public scope, identity requirements and actual result for that environment. A discovery tool is not a booking tool; an appointment request is not a confirmed event.

Continue exploring

A capability of your company’s AI OS. AlefOS provides the shared foundation; your deployment defines the enabled tools and access. Understand your AI OS ↗

Choose your next step.