MCP and automation

An MCP client can discover Weblink devices, inspect diagnostics, and operate a local or remote desktop after authorization. Windows desktop provides an HTTP MCP service; browsers supporting WebMCP can expose tools to a browser-local client.

Understand the two switches

Desktop Settings → Automation has two independent switches, both off by default:

Switch	What it enables
Enable MCP	Starts the MCP API for clients with a local token; does not automatically permit local OS operations
Enable automation	Allows authorized tools to operate this computer; does not start the MCP API

To use this computer only as an entry point to other devices, enable MCP alone. Discovery, local diagnostics, and forwarding do not require local automation. Local OS tools such as screenshots, input, and commands require the automation switch.

Connect a desktop MCP client

1. Open Settings → Automation on Windows desktop and enable MCP.
2. Under “Local MCP tokens”, create a named token for the client and choose its expiry.
3. Copy the connection configuration or full token from the creation result into your MCP client. The full token is shown only once.
4. Ask the client to list devices and confirm the local and connected devices appear.
5. Enable automation as well if you want to operate this computer.

A server entry for the default address looks like this; the enclosing configuration format varies by MCP client:

{
  "url": "http://127.0.0.1:32100/mcp",
  "headers": {
    "Authorization": "Bearer <YOUR_MCP_TOKEN>"
  }
}

The direct token form generated by the interface is also supported. Prefer copying the complete generated configuration to avoid missing headers or incorrect addresses.

Example device-list call:

{
  "name": "devices.list",
  "arguments": { "target": "local" }
}

Every tool needs an explicit target: use local for this computer or an ID returned by the device list for a remote device. A display name is not a device ID.

Operate a remote device

1. Connect both Weblink devices to the same room and complete pairing.
2. Enable automation on the destination Windows desktop. Diagnostics alone do not require this switch, and the destination can also be a browser.
3. List devices in the MCP client and use the destination ID as the tool's target.
4. The destination applies its device permissions or displays an approval request.

The destination does not need to expose its own HTTP MCP service. Your entry point forwards over the existing device connection, while the destination independently authorizes operations.

For input, first discover a shareable monitor source and acquire control before calling input tools. Use the tool list returned to the client for available operations and parameters; window sharing does not replace a controllable monitor.

Configure permissions

On the destination, configure automation permissions in member details or Settings → Clients and rooms:

Permission group	Operations
Reading and diagnostics	Device and stream state, screenshots, and reading desktop UI content
Sharing and control	Screen sharing, stream configuration, mouse/keyboard input, and UI actions
Terminal and commands	Shell execution, output, and command-job management

Each group supports Ask, Always allow, and Deny, defaulting to Ask. “Allow for this session” applies only to the current connection. Saved Always allow or Deny policies persist for that device and permission group.

A local MCP token authorizes the connecting client. It does not pair a remote device or bypass destination permissions. With local automation enabled, a valid token permits local OS tools without a separate remote-device approval prompt for every local call.

Manage tokens and listener settings

Create a separate token for each client to identify recent usage and revoke access independently. Edit its name or expiry, or revoke it; token management remains available while MCP is off.

Expiry or revocation invalidates related calls. Extending an expired token permits new calls without restoring previous tasks.

“MCP server” settings change the listening host and port, defaulting to 127.0.0.1:32100. Saved changes apply the next time MCP is enabled. Turn it off and on as prompted, then update the client URL.

LAN clients need a reachable listening interface and firewall port. Use a concrete IP from the connection-address list, not 0.0.0.0 or :: as a destination. The service provides HTTP without arbitrary hostname aliases or built-in TLS. The default loopback address is local-only.

Use WebMCP in a browser

In a browser supporting WebMCP, enable MCP in automation settings and use a browser-local client.

Browsers do not start an HTTP MCP listener or issue local tokens. They can inspect local diagnostics or use a local WebMCP client to operate an authorized connected desktop. The browser itself does not execute OS input or Shell commands.

Stop and revoke access

• Disable automation to stop local OS automation, input, and command jobs. Diagnostics and MCP forwarding remain available.
• Disable MCP to stop the HTTP entry point or browser tool registration. This does not disable automation already enabled on a destination.
• Revoke a token to cancel that client's authorization and related tasks.
• Deny remote-device permissions to block that device or permission group.

To stop host input immediately, use the host emergency-stop shortcut.

Choose your next step

• Control which connected devices may access this computer: review device permissions.
• Install a client that can run local OS automation: follow desktop installation.
• Resolve MCP connection, authentication, or tool-call failures: check the MCP and automation FAQ.