Allow explicitly scoped MCP thread discovery across projects and connected environments

[prrcarvalho]

Problem

The current MCP thread tools do not let an agent discover conversations outside the calling project and environment. A user who wants an agent to find an earlier implementation conversation and read a related daily-work thread may have to switch environments and bring the relevant context back manually. For example, an agent on a laptop could search an authorized desktop environment through its authenticated T3 connection.

This is a gap in the current MCP selectors, not a claim that T3 has no authenticated APIs: environment APIs already expose project, shell, and thread state, and MCP can read a thread explicitly attached by the user. Those capabilities do not provide a general cross-environment MCP discovery selector.

Proposal

Add read-only MCP list, search, and read operations over an explicitly authorized scope. Preserve today's default: the calling project in the calling environment. The user could then select all projects in one authorized environment, a subset of its projects, or a set of authorized environments and projects. The server may fan out across the selected scope, so users do not need to make one call per project. It must never search every connected environment by default or infer agent access from environments visible in the UI.

Require an explicit environment and project scope, or a reference to a user-created grant, for broader queries. Return aggregated results with environment, project, and thread identity on every item. List and search should support pagination and report whether results are complete; a bounded search must not appear exhaustive. Reading a thread should support paginated history and recovery of truncated items. Define behavior for active, snoozed, settled, and archived threads where the underlying API supports those states. The API should declare whether deleted or otherwise unrecoverable threads are excluded; a lookup may return a privacy-preserving not-found response rather than reveal deletion.

If a selected environment is disconnected, unauthorized, or unavailable, return a clear error for that scope and indicate partial results instead of silently implying completeness. Grants should be least-privilege, user-controlled, and revocable. A grant for one environment must not automatically authorize another.

Separate action permissions

Keep discovery and reading separate from launch and write operations. A later extension could allow launching a thread in a selected environment under a separate grant and T3's normal workspace and approval controls. A read grant should never authorize messaging existing threads, launching work, arbitrary remote shell access, or unrestricted execution.

Related work

Discussion #13888 proposes user-granted cross-project thread messaging and identifies other environments as later work. This proposal focuses on read-only discovery across projects and authenticated environments. Issue #15125 reports a same-environment follow-up bug for threads launched into another project; it does not provide general discovery across environments.

Suggested rollout

First define grants, revocation, completeness, and provenance, then deliver list/search/read within one environment. Extend the same contract to other explicitly authorized environments next. Consider launch/write only as a separately authorized phase. The environment APIs and T3 Connect transport provide useful foundations, but the cross-environment MCP selector and its authorization are still proposed capabilities.

Would this scoped, read-only discovery capability fit the orchestration direction? What authorization and revocation controls should it expose?

Sources

• Environment HTTP API contracts
• Orchestration RPC methods and inputs
• T3 Connect internals