Tailscale MCP rejected in owner-created webhook routine, but works in direct chat (0.78.1)

Start with the Tailscale plugin README and setup skill, then compare their wording about owner-scheduled routines with the routine documentation on webhook triggers. Trace how execution origin is checked for webhook routines and how that affects private MCP tool loading and calls. Done means establishing whether webhook routines are supported and, if so, resolving the rejection; if not, documenting the distinction and an actionable explanation.

Summary

On Grok Bot 0.78.1 stable, a custom private MCP connector works from the owner's direct chat, but the same connector is rejected when used by an owner-created webhook routine.

The webhook returns HTTP 200 and the routine starts. The failure occurs afterward, when the routine tries to load or call the private MCP tools. Please clarify whether owner-created webhook routines are supported for Tailscale MCP access, and investigate the execution-origin check if they are.

Environment

• Grok Bot: 0.78.1, stable; macOS / darwin
• Build: 2026-10-28T02:34:00.517Z
• Reproduced: 2026-10-30
• Official Tailscale plugin connected to a personal tailnet
• Custom remote HTTP/Streamable HTTP MCP at a private HTTPS <server>.<tailnet>.ts.net/mcp address
• Connector authentication: static Bearer header, already configured and working in direct chat
• Tailscale Funnel disabled; the MCP server is not publicly exposed

Steps to reproduce

1. Connect the official Tailscale plugin and register a private MCP connector with valid authentication.
2. From the owner's direct Grok Bot chat, verify tools/list, ping, and an ordinary mailbox operation. These succeed in our setup.
3. In that same owner's Bot, create a webhook routine that uses the existing connector to reserve one test request, read it, and save one echo result. Do not change the connector URL or credentials.
4. POST a small JSON notification containing only test identifiers to the routine's generated webhook URL, authenticated with its sender key.
5. Observe HTTP 200 and the routine starting, then inspect its MCP access result.

Three controlled deliveries reproduced the failure. The first two used the Authorization header. A further comparison also included X-Automation-Key with the same sender key, as shown in the repository's make-bot-ui example. It still failed. Values and identifiers are omitted here.

Actual behavior

Depending on the run:

• The connector is reported as error / zero tools while loading the routine's tools; or
• Tools are visible, but calling the server-side reservation tool fails.

The routine reported this error:

Tool execution error. Tailnet servers work only in your own conversations with Grok Bot.
Someone else, an agent, or an automation started this request.
To use this server, send the request yourself in a Grok Bot chat or a Slack direct message to Grok Bot.

The tools-loading failure also appeared with the prefix failed_to_load: and the same explanatory text.

Our server's reservation/audit, result, and read-receipt records confirm no successful processing of the test requests. This is not a claim that all network traffic was captured. Webhook acceptance and routine wakeup succeeded; task completion did not.

Expected behavior / documentation question

The Tailscale plugin README and setup skill describe access for "routines the owner schedules". The routine documentation includes webhook triggers.

Does this permission include webhook routines created by the owner, or only time-scheduled routines? The time-scheduled case was not tested.

If webhook routines are supported, the observed origin rejection appears inconsistent with that support. If intentionally excluded, please document the distinction and provide an actionable explanation.

Impact and scope

This blocks a private mailbox workflow: another agent posts a request, the server wakes Grok Bot by webhook, and Grok Bot must fetch the request and write its result over the existing private connector.

Including the task body directly in the webhook could avoid fetching its text, but would still leave server-side reservation and result delivery unresolved; this has not been implemented as a workaround.

This report does not establish a root cause or request bypassing origin restrictions. Test runs were cancelled, and webhook sending is paused. Authentication and network exposure were not relaxed.

Separate from #1108: that issue concerns OAuth sign-in before tools become available. Here a static-Bearer connector already works from direct chat; the failure depends on the execution being webhook-triggered.

Real hostnames, tailnet/device/account identifiers, internal message/task/run IDs, credentials, webhook/callback URLs, conversation links, raw logs, and screenshots are intentionally excluded.