Feature request: optional WebMCP support for browser agents

[Gzmomo001]

Summary

Would the project be open to optional WebMCP support, allowing browser agents to interact with Stack sites through structured, site-defined tools?

WebMCP is an experimental browser API that lets a page expose existing JavaScript functionality or HTML forms as tools through document.modelContext. The specification is being developed in the WebMCP Community Group repository.

This issue is intended to discuss the desired scope and whether the integration belongs in Stack itself or in a separate Hugo Module/theme adapter before an implementation is proposed.

Motivation

Browser agents can currently navigate a Stack site by reading the DOM and simulating clicks. A small WebMCP integration could provide more reliable, structured access to capabilities that Stack already owns, especially its client-side search and article metadata.

Because Stack controls the search index format, taxonomy pages, article metadata, and client-side lifecycle, a theme-aware integration can be more stable than site-specific DOM selectors.

Possible initial scope

Start with a small set of read-only tools:

• search_site(query, limit): search the existing Stack content index and return structured results with title, URL, date, section, tags/categories, and excerpts.
• get_current_article(): return structured metadata for the current article, such as title, canonical URL, description, publication/update dates, authors, tags/categories, and headings.

Additional tools should only be added when they expose a meaningful theme capability and are more useful than ordinary page navigation.

Proposed constraints

• Disabled by default, for example:

  params:
    webmcp:
      enabled: false

• Progressive enhancement: register tools only when document.modelContext is available.

• No behavior or UI changes in browsers without WebMCP support.

• No external SDK, network service, analytics, or telemetry dependency.

• Bundle the WebMCP code only when explicitly enabled.

• Keep the first implementation read-only.

• Reuse Stack's existing search/index data where practical instead of creating a second independent search system.

• Keep tool definitions in a separate partial/module so the experimental API can evolve without affecting unrelated theme code.

Open questions

1. Would this feature be appropriate for Stack core, or would maintainers prefer an external Hugo Module that integrates through Stack's custom head/footer hooks?
2. Is an opt-in search_site tool a reasonable first proof of concept?
3. Should get_current_article be part of the theme integration, or should sites define it themselves?
4. Are there bundle-size or maintenance constraints that should shape the proposal?

If the direction fits the project, a focused proof of concept can be prepared after the scope is agreed.