Proposal: Add ClawHub page to the UI for easy skill/plugin installation

Summary

Today the Windows app shows you which OpenClaw skills you have installed, but there is no way in the UI to discover and install new skills/plugins from ClawHub. Ideally users should be able to explore and install things from ClawHub easily.

It would also be great if the app could check locally installed applications and highlight official ClawHub plugins/skills for those apps. That way if a user installs a new application, or an application publisher creates/updates official skills/plugins it's easy for users to connect their claw to that application.

As more desktop software adds MCP/CLI tools and skills to drive them users will want to easily connect their claw to them.

AI Research Summary

Current experience

The existing Skills page lists gateway-reported skills and lets users enable or disable them. It does not browse ClawHub or present relevant plugins.

Plugin installation guidance appears only in some feature-specific recovery flows. The Local MCP Server setting under Permissions is a separate feature that exposes Windows-node capabilities to local MCP clients; it does not discover MCP integrations offered by installed applications.

For example, a user may have a known desktop application installed that offers an MCP server, while an official ClawHub plugin knows how to connect to it. The Windows app does not connect those facts or help the user review and enable the integration.

Desired behavior

The Windows app should provide a ClawHub experience covering skills and plugins, including a view for plugins that provide MCP capabilities.

When that page is opened, OpenClaw should be able to scan installed applications locally and prominently show relevant official integrations. Matching should use stable application and publisher identities rather than display-name similarity.

Selecting a recommendation should let the user review what was matched, who published the ClawHub package, what capabilities it provides, and any setup or restart requirements before installation. Skill and plugin installation should use the Gateway's trusted lifecycle and policy checks. An MCP integration should not be reported as ready until its connection and exposed tools can be verified.

The current installed-skill enable/disable controls should remain available as part of the ClawHub experience.

Trust and privacy expectations

• An installed app is a relevance signal, not permission to install or enable anything automatically.
• Installed-app matching should require exact package/publisher or signed application identities. A matching display name, process, executable name, or open port is not sufficient by itself.
• Installed application inventory should remain on the Windows machine. ClawHub catalog metadata can be downloaded and matched locally without uploading the user's app list, executable paths, or signer details.
• App-based recommendations should be limited to available packages from official publishers.
• Community packages may remain browsable when explicitly requested, with clear trust warnings.
• Trust, integrity, compatibility, moderation, and install-policy decisions should remain enforced by the Gateway.
• Warnings, required credentials, and restart requirements should require explicit user confirmation.
• OpenClaw should not scan arbitrary ports, launch detected apps, or import MCP configuration from other tools as part of discovery.

MCP scope

MCP should be presented as a capability supplied by a ClawHub plugin or bundle, not as a separate package type. The plugin owns the supported connection and configuration path for the application and exposes the resulting MCP tools to OpenClaw.

The initial scope can support only integrations whose official plugin already provides a working connection path for the active Gateway topology. A generic bridge for MCP servers that are reachable only from the Windows node can be considered separately.

Start by reviewing the existing Skills page and its gateway-reported enable/disable flow, then examine the Gateway's trusted lifecycle and policy checks. Define the ClawHub browsing, local installed-application matching, review and confirmation, and MCP verification boundaries before implementation. Done means the scope is split into an actionable design with explicit privacy, trust, and readiness requirements.