Expose configured remote MCP servers through the external Mattermost MCP endpoint

[pilprod]

Summary

Allow administrators to expose selected configured remote MCP servers through the existing external Mattermost MCP endpoint, turning Mattermost Agents into a user-aware multi-server MCP gateway/portal.

Today Mattermost Agents can:

• connect to multiple remote MCP servers for use by Mattermost agents;
• expose an external Streamable HTTP MCP endpoint protected by Mattermost OAuth;
• expose built-in Mattermost tools and tools registered by other Mattermost plugins;
• preserve Mattermost user identity and per-tool policies for externally exposed plugin tools.

However, regular remote servers in MCPConfig.Servers cannot currently be re-exported through the external endpoint. ExposeExternal and the proxy implementation are available only for plugin-registered MCP servers.

Use case

An organization operates several MCP servers, for example infrastructure, source control, observability, messaging, or internal business systems. The servers are already configured and governed in Mattermost Agents.

External clients such as Claude, Codex, ChatGPT, IDEs, and automation tools should be able to connect to one endpoint:

External MCP client
        |
        | Mattermost OAuth / PKCE
        v
https://mattermost.example/plugins/mattermost-ai/mcp-server/mcp
        |
        | Mattermost user identity, tool policy, namespaced routing
        v
Remote MCP server A / B / C

This would let Mattermost serve as the identity and governance boundary for MCP without requiring every user to configure every remote endpoint separately or requiring a separate third-party MCP portal product.

Proposed behavior

Opt-in external exposure

Add an administrator-controlled setting such as Expose externally to each configured remote MCP server. It should be disabled by default.

Only enabled servers and enabled tools should be included in the external endpoint's tools/list response.

Deterministic namespacing

Remote tools should be namespaced by server identity to avoid collisions, for example:

<server_name>__<tool_name>

Names must remain stable across restarts and configuration reloads. Collisions and invalid names should produce an explicit administrator-visible error rather than silently dropping an unrelated tool.

User-scoped execution

The external Mattermost OAuth token already resolves to a Mattermost user. Remote tool calls should run in that user's context:

• reuse that user's existing remote-server OAuth connection when the upstream requires per-user OAuth;
• use administrator-configured server-side credentials only when the remote server is explicitly configured for shared credentials;
• never return upstream OAuth tokens, static headers, or secrets to the external MCP client;
• keep remote MCP sessions isolated per Mattermost user and bound by the existing idle timeout.

If the Mattermost user has not connected an OAuth-backed remote server, the gateway should omit its tools or return a structured authorization-required result containing a safe Mattermost connection URL.

Preserve Mattermost governance

External access should honor the same controls used inside Agents:

• server enabled/disabled state;
• per-tool enabled state;
• tool approval policy;
• agent or administrator restrictions where applicable;
• user permissions and account deactivation;
• audit attribution to the authenticated Mattermost user.

Capability refresh

Changes to a remote server's tool catalog should propagate to the external endpoint without requiring users to recreate their external MCP connection. Reconnect/synchronization failures should be visible in the System Console.

OAuth interoperability consideration

Mattermost already provides Authorization Server Metadata, DCR, PKCE S256, and RFC 8707 resource handling, which makes the external endpoint suitable for general MCP clients.

One remaining interoperability/security consideration is session renewal for public DCR clients. Mattermost public OAuth applications currently receive an access token but no refresh token, with lifetime tied to SessionLengthSSOInHours. For a long-running MCP gateway, it would be useful to define a safe renewal model for public clients, such as rotated refresh tokens with replay grace, or another documented approach that avoids both frequent interactive reauthorization and long-lived bearer credentials.

This may belong in Mattermost Server rather than Agents and does not need to block the initial remote-server aggregation feature.

Security requirements

• External exposure must be opt-in per server.
• Dynamic client registration should support an exact redirect URI allowlist.
• Upstream credentials must remain server-side.
• Authorization and tool execution must use the same authenticated Mattermost user.
• Revoking the Mattermost OAuth application, disconnecting an upstream provider, disabling the user, or disabling the remote server must prevent new calls within a bounded interval.
• Server-side request protections and hostname allowlists must continue to apply to upstream connections.
• Concurrent external clients must not share upstream MCP sessions or OAuth state across Mattermost users.

Suggested acceptance criteria

1. Configure two remote MCP servers in Mattermost Agents and opt both into external exposure.
2. Connect an external client through the existing Mattermost OAuth/DCR flow.
3. tools/list returns namespaced tools from both servers plus existing Mattermost tools.
4. A tool call is routed to the correct server and attributed to the authenticated Mattermost user.
5. Shared and per-user upstream credential modes both work without exposing credentials to the client.
6. Disabling a tool or server removes it from the external catalog.
7. Users without an upstream OAuth grant receive a clear authorization-required result and cannot use another user's grant.
8. Tool-name collisions, remote failures, and capability refresh failures are visible and deterministic.
9. Multiple users and concurrent client sessions remain isolated.
10. Claude, Codex, or another general remote MCP client remains connected across normal token/session renewal.

Why this fits Mattermost

Mattermost already owns the user identity, remote MCP configuration, tool policies, OAuth connection state, and an external MCP endpoint. Extending the endpoint to selected remote servers would combine those existing pieces into a vendor-neutral, self-hosted MCP gateway with per-user governance.