Feature request: deep-link to specific Cowork scheduled task + propagate task identity to MCP tool calls

Summary

Two related capabilities that would unlock observability and external integration for Cowork scheduled tasks:

1. Deep link to a specific scheduled task, e.g. claude://cowork/scheduled/{taskId} — opens Claude Desktop, navigates Cowork to the Scheduled tab, and selects/scrolls-to the named task.
2. Propagate the originating scheduled task identity to MCP tool calls — when an MCP tool is invoked during a scheduled task run, the tool should be able to determine (a) that it's running inside a scheduled task, and (b) which one (a stable task ID, ideally the task name as well).

Use case

We're Chronity Connect — an MCP server providing AI compliance tooling for RICS-regulated UK surveying firms. We run on Cloudflare Workers and our MCP tools are invoked from Cowork by surveyors at customer firms.

We're shipping a notify_me MCP tool that emails users when their scheduled tasks finish (a common request: "run my morning brief at 7am and email me when done"). Today there is no way for the resulting email to:

• Link back to the scheduled task that triggered it
• Reliably identify which scheduled task triggered it without explicitly asking Claude to pass the name as a tool parameter (which works but is fragile and round-trips through the model)

This becomes a more general problem for any MCP server that wants to:

• Provide observability dashboards for customer scheduled-task runs
• Audit / log compliance-relevant work performed by scheduled tasks
• Allow users to navigate from external surfaces (email, Slack, etc.) back to the source task in Cowork

Proposed shape

1. URL scheme addition: claude://cowork/scheduled/{taskId} — opens Cowork to the Scheduled tab focused on the task, where {taskId} is a stable opaque ID surfaced to the user (visible in the task UI, copyable to clipboard).

1. MCP request context propagation: when Claude invokes an MCP tool during a scheduled task run, include a structured context field in the request _meta block per the MCP spec, along these lines:

``json
{
"scheduledTask": {
"id": "task_abc123",
"name": "Morning brief",
"scheduleExpression": "0 7 * * *"
}
}
``

Workarounds today

We can ask Claude to pass the task name as a tool parameter — works but model-mediated and Claude has to know to do it. We can mirror task output into our own portal and link there from email. Neither closes the loop with Cowork.

Why this matters beyond us

Any MCP server building integrations with Cowork — observability, compliance, audit, productivity, notifications — will hit this same wall. Solving it once at the platform level unlocks an ecosystem of Cowork-aware MCP integrations.

Happy to share more detail on the Chronity Connect implementation if useful.