feat(mcp): add a Discover flow for standard remote MCP connections

[Yevanchen]

Area

Web app / API / MCP control plane

Context

An internal review of AgentSky triggered this request. Its visible product loop combines messaging channels, installable Skills, and SaaS connectors. The implementation may be thin, but the product signal is useful: a Builder can immediately understand how an Agent acquires capabilities and where it can be reached.

Mosoo already has stronger underlying boundaries, but they are not equally discoverable:

• Skills have a Discover → Install → attach to Agent flow backed by skills.sh.
• Remote MCP requires the App Owner to already know an HTTPS server URL and its authentication details.
• Channel code exists but is not a verified or reachable end-to-end feature; that is a separate product problem and is not part of this issue.

References:

• Skills product note
• MCP Connections product note
• Channels product note

Problem

A Builder who wants to give an Agent access to Gmail, Notion, Slack, or another service currently has to discover an MCP implementation elsewhere, decide whether to trust it, find the correct URL, understand its auth requirements, and manually recreate that information in Mosoo.

This makes the existing MCP capability legible only to people who already understand the MCP ecosystem. It also leaves Mosoo without the equivalent of the Skills Discover surface.

Skills and MCP must not share the same installation semantics:

• Installing a Skill copies package bytes into an App-owned snapshot.
• Connecting an MCP server creates a live App-owned connection to an external runtime.

The reusable product pattern is discovery and state, not artifact ownership.

A second constraint is non-negotiable: ACP Runtime and the Mosoo Agent Driver execute standard MCP only. A connector marketplace must not add Composio, Pipedream, or another vendor's Action SDK to the Driver.

Proposal

Add a Discover flow to MCP Connections, next to the current installed/manual connections.

Keep the first version deliberately narrow:

1. Select one upstream catalog after a compatibility spike; do not build a multi-provider abstraction first.
2. Show capability-first entries such as Gmail when Mosoo has selected a concrete, trusted MCP implementation. Keep the implementation provider and source visible.
3. A single Connect action should:
   • create or reuse an App-owned remote MCP connection;
   • prefill its endpoint and supported auth method;
   • immediately start the existing OAuth or bearer flow;
   • after authorization, perform a standard MCP initialize + tools/list check;
   • make the connection available for Agent attachment.
4. Preserve source/provenance metadata, but treat the installed object as a live connection—not a copied package or an endorsement that the upstream is always safe.
5. Keep the execution plane unchanged: Runtime receives a standard remote MCP endpoint through Mosoo's existing credential proxy. Provider-specific SDKs, Action schemas, and execution APIs stay out of ACP Runtime and Agent Driver.

The click-path goal is:

Discover Gmail → Connect → provider consent → return as Ready

OAuth account selection and provider consent cannot be removed, but Mosoo should not add an intermediate “install a connector hub” step.

Research

The products reviewed are not interchangeable; they own different parts of the supply chain.

Option	Official usage	Fit with the current Mosoo boundary
Official MCP Registry	Metadata registry for downstream marketplaces and remote MCP servers	Most protocol-native, but server-centric rather than a normalized “Gmail capability” catalog; quality and auth vary by server
OpenConnector	Open-source provider/action catalog exposed through a standard Streamable HTTP /mcp endpoint; runtime accepts Bearer auth	Closest current technical fit and the first candidate to smoke-test; its MCP surface is a small set of discovery/execution meta-tools rather than direct Gmail tools
Composio Sessions via MCP	Creates a hosted standard MCP endpoint scoped to selected toolkits/tools	Protocol-compatible, but the returned endpoint requires session.mcp.headers (currently an x-api-key path), which Mosoo's current OAuth/Bearer-only connection model cannot express without control-plane/proxy adaptation
Pipedream Developer MCP	Standard Streamable HTTP MCP over a hosted endpoint with managed app connections	Protocol-compatible, but the developer endpoint requires a short-lived developer token plus project/environment/user/app parameters; the consumer /v2 OAuth endpoint adds Pipedream sign-in and app selection instead of a direct Gmail flow
Executor	One MCP gateway in front of user-supplied MCP, OpenAPI, and GraphQL integrations	Useful as an aggregation gateway, but it does not supply a Gmail connector marketplace and overlaps Mosoo's existing MCP proxy/Agent binding layer

Technically, managed connector platforms and the MCP ecosystem are complementary because they can expose standard MCP. Strategically, they compete over catalog ownership, OAuth credentials, execution traffic, policy, logs, and billing. This issue should preserve Mosoo's standard MCP boundary so the upstream source can be revisited later.

Acceptance criteria

• A documented compatibility spike selects one upstream catalog for V1 using protocol, auth, user flow, provenance, operating cost, and failure behavior as criteria.
• MCP Connections has searchable Discover and Installed states without removing manual URL entry.
• At least one OAuth-backed capability such as Gmail completes the full Builder flow from catalog card to an App-owned ready connection.
• From the card, one Mosoo action starts the shortest available provider authorization path.
• “Ready” requires a successful standard MCP initialize and tools/list; an active stored credential alone is not presented as proof that tools work.
• The connected server attaches to an Agent and completes one tools/call through the existing Mosoo MCP proxy and Agent Driver.
• The Runtime and Agent Driver contain no provider-specific connector SDK or Action execution path.
• The UI shows implementation provider, source/provenance, requested auth/scopes when known, and actionable failure/reconnect state.
• Existing manually configured MCP connections continue to work unchanged.

Non-goals

• End User-scoped MCP credentials or per-End-User authorization
• Enabling or validating Channels
• Changes to the Skills marketplace
• Local-process / stdio MCP servers
• Building a Mosoo-native catalog of SaaS Action implementations
• Aggregating multiple connector providers in V1
• Pipedream workflows, triggers, or a general workflow builder
• Treating catalog inclusion as a security or availability guarantee

Compatibility and migration

This should be additive. Existing App-owned MCP servers, credentials, Agent bindings, and manual setup remain valid. Catalog installation should resolve into the same existing remote MCP connection and Runtime contract. Any provider-specific provisioning needed to obtain the endpoint belongs in the control plane and must terminate at a standard MCP URL plus an authentication form Mosoo can safely proxy.

Contribution

I can provide product feedback.

Checklist

• I searched existing issues before opening this request.
• I described the problem before the proposed solution.
• I kept this request focused on one improvement.